What is the best dedicated server hosting for PostgreSQL?

Why does PostgreSQL need ECC memory?

PostgreSQL does not guard against memory errors: its reliability chapter assumes you run industry-standard ECC RAM or better. Data checksums protect pages on disk. They are on by default in PostgreSQL 18. A bit flipped in RAM before a write still lands on disk with a valid checksum.

For a primary database, ECC is not a luxury; it is the hardware PostgreSQL was written to expect. The Lumenfer plans with ECC are:

• Lumen 6: AMD EPYC 4244P, 32 GB DDR5 ECC, $91.65.
• Lumen 24: AMD EPYC 9254, 256 GB DDR5 ECC, $356.25.
• Lumen 32: AMD EPYC 9354, 384 GB DDR5 ECC, $749.67.

The Ryzen plans list standard DDR5. They suit replicas you can rebuild, staging databases and reporting copies. Our page on whether you need ECC RAM on a rented server explains the difference.

How much RAM does a PostgreSQL server need?

Enough for shared_buffers plus a large kernel page cache, because PostgreSQL reads through both. The manual's starting point for a dedicated database server is 25% of RAM in shared_buffers. It adds that more than 40% is unlikely to work better, since PostgreSQL also relies on the operating system cache.

• shared_buffers. On a 256 GB machine, 25% is 64 GB. Larger values usually need a larger max_wal_size as well.
• effective_cache_size. A planner estimate, not an allocation. Set it to shared_buffers plus the kernel cache PostgreSQL will use. The default is 4 GB, far too low for a large server.
• work_mem. 4 MB by default, granted to each sort or hash step. A complex query runs several, and many sessions run at once. Total use can be many times the setting.
• maintenance_work_mem. 64 MB by default, used by VACUUM and index builds. Raise it on a large server.

When the whole database fits in RAM, the manual says lowering random_page_cost can be appropriate. With hundreds of gigabytes of DDR5, many databases reach that point.

Should I use huge pages and strict overcommit for PostgreSQL?

Yes, on a server that runs only PostgreSQL: the manual documents both for Linux. Huge pages reduce overhead for large shared_buffers. Strict overcommit lowers the chance that the kernel kills the postmaster when memory runs short.

PostgreSQL tells you how many huge pages it needs. Reserve them, then set huge_pages = on so the server refuses to start without them. The default, try, falls back silently.

These settings conflict with ClickHouse, whose documentation says not to disable overcommit. Keep the two databases on separate machines; see ClickHouse hardware on bare metal.

# strict overcommit; add the same line to /etc/sysctl.conf
sysctl -w vm.overcommit_memory=2

# how many huge pages does this cluster need? (server stopped)
postgres -D $PGDATA -C shared_memory_size_in_huge_pages
# reserve that number, e.g. 3170, then make it permanent in /etc/sysctl.conf
sysctl -w vm.nr_hugepages=3170

# postgresql.conf: refuse to start without huge pages
# huge_pages = on

Which storage layout suits PostgreSQL on a rented server?

Keep the NVMe mirror and make replication and off-site archives your second copy. Two-drive plans ship with the operating system on a software RAID 1 mirror; ask support before delivery if you prefer RAID 0 or two separate drives.

The manual says WAL on a separate disk is advantageous. On a two-drive server, that means breaking the mirror. One dead drive would then take down either the data or the WAL. On rented hardware without a console, we would keep RAID 1.

Write caches deserve a check. The manual warns that many SSDs have volatile write-back caches, and many do not honour flush commands by default. It suggests testing with diskchecker.pl. Ask support for the exact drive model, then look for power-loss protection in its datasheet. More on drive types in NVMe vs SATA SSD on rented servers.

How many CPU cores does PostgreSQL use?

One per busy connection, plus parallel workers for big queries. PostgreSQL starts a new server process for each connection. Short transactional queries run on one core each, so per-core speed sets their latency. Large scans and joins can split across parallel workers.

• Connections. max_connections is typically 100. PostgreSQL sizes some shared memory from it, so thousands of idle connections waste RAM. Put a connection pooler in front instead.
• Parallel query. Workers per query are capped by max_parallel_workers_per_gather. The totals are capped by max_worker_processes and max_parallel_workers, both 8 by default. On 24 or 32 cores, raise them for reporting queries.

The EPYC plans trade some per-core speed for more cores and ECC. Our guide to how many CPU cores a rented server needs covers the trade-off.

How do I back up PostgreSQL on a rented server?

Run continuous archiving to storage outside the server, and keep a streaming replica in another city. Backups are not included: keep copies of your data somewhere else. The manual lists three backup approaches: SQL dumps, file-system-level copies and continuous archiving. Only continuous archiving lets you restore to a point in time.

Amsterdam (Netherlands), Reykjavik (Iceland), Zurich (Switzerland) and Bucharest (Romania): all five plans in all four cities, one price everywhere. A primary in Amsterdam with a replica in Reykjavik or Zurich costs exactly two plans, nothing more.

Which Lumenfer plan should I choose for PostgreSQL?

Pick an ECC plan for the primary and size it so the hot data fits in memory. Replicas and test copies can run on the Ryzen plans. Every plan and term is on the Lumenfer pricing page.

In Lumenfer's check of 30 October 2026, 95 of 229 comparable plans at no-KYC crypto hosts listed DDR5 memory. Every Lumenfer plan does, on a 2022-or-newer CPU.

Is a rented server better than managed PostgreSQL?

It gives you a whole machine at a flat price, but you become the database administrator. Managed services run backups, failover and upgrades for you. On a rented server you choose the version, the extensions and every kernel setting, and you carry those jobs yourself.

Lumenfer manages the hardware only. Reboots, reinstalls and cancellations are requested in the dashboard and handled by the team; reinstalling wipes the drives. For the move itself, read whether to leave AWS for bare metal.