# What is the best dedicated server hosting for PostgreSQL?

> Best dedicated server hosting for PostgreSQL: ECC RAM, a large page cache, local NVMe. ECC plans from $91.65 per 30 days, crypto, no KYC.

- URL: https://lumenfer.com/dedicated-server-for-postgresql/
- Last updated: 2026-11-01
- Publisher: Lumenfer (https://lumenfer.com)

What PostgreSQL's own manual asks of the hardware, which settings to change on a machine you rent whole, and which plans fit a primary, a replica or a test database.

**Quick answer — What is the best dedicated server hosting for PostgreSQL?**

The best dedicated server hosting for PostgreSQL gives you ECC memory, enough RAM to cache your working set, and local NVMe drives you control. PostgreSQL's own manual assumes ECC RAM. **Lumenfer**'s Lumen 24 (AMD EPYC 9254, 256 GB DDR5 ECC) costs $356.25 per 30 days, paid in crypto with no KYC. ECC plans start at $91.65.

## PostgreSQL hardware facts from the official documentation

| Attribute | Value |
| --- | --- |
| Documentation read | PostgreSQL 18 (18.6), on 1 November 2026 |
| Memory errors | PostgreSQL does not protect against them; the manual assumes ECC RAM or better |
| Data checksums | On by default; WAL full-page images are always checksummed |
| shared_buffers | Start at 25% of RAM on a dedicated database server; above 40% rarely helps |
| work_mem | 4 MB by default, for each sort or hash operation, not for each query |
| Connections | One server process per connection; max_connections is typically 100 |
| Parallel workers | max_worker_processes and max_parallel_workers both default to 8 |
| Linux memory | Strict overcommit (vm.overcommit_memory=2) makes the OOM killer much less likely |
| ECC plans at Lumenfer | Lumen 6, Lumen 24 and Lumen 32 |
| Storage at Lumenfer | NVMe only. 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 |
| Backups | Backups are not included: keep copies of your data somewhere else |

## 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](https://lumenfer.com/ecc-ram-dedicated-server/ "Do I need ECC RAM on a rented dedicated 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](https://lumenfer.com/clickhouse-server-hardware/ "What hardware ClickHouse needs on bare metal").

*Linux settings from the PostgreSQL 18 manual, section 18.4*

```bash
# 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](https://lumenfer.com/nvme-vs-sata-ssd-dedicated-server/ "How much faster NVMe is than SATA SSD").

## 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](https://lumenfer.com/how-many-cores-dedicated-server/ "How many CPU cores you need on a rented dedicated server") 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](https://lumenfer.com/pricing/ "Lumenfer bare-metal plans and prices per 30 days").

**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.

### Lumenfer plans for PostgreSQL

| Plan | CPU | Cores | Memory | Disks | Per 30 days | Role |
| --- | --- | --- | --- | --- | --- | --- |
| Lumen 6 | AMD EPYC 4244P | 6 cores / 12 threads | 32 GB DDR5 ECC | 2 × 960 GB NVMe | $91.65 | Small production primary |
| Lumen 8 | AMD Ryzen 7 9700X | 8 cores / 16 threads | 64 GB DDR5 | 2 × 1 TB NVMe | $109.37 | Replica, staging, CI databases |
| Lumen 16 | AMD Ryzen 9 9950X | 16 cores / 32 threads | 128 GB DDR5 | 2 × 1.92 TB NVMe | $205.27 | Read replica, reporting copy |
| Lumen 24 | AMD EPYC 9254 | 24 cores / 48 threads | 256 GB DDR5 ECC | 2 × 1.92 TB NVMe | $356.25 | Production primary |
| Lumen 32 | AMD EPYC 9354 | 32 cores / 64 threads | 384 GB DDR5 ECC | 2 × 3.84 TB NVMe | $749.67 | Large primary, heavy reporting |

### What comparable 24-core and 32-core servers cost elsewhere

| Server | Specs | Price per month |
| --- | --- | --- |
| Lumenfer Lumen 24 | AMD EPYC 9254 (2022, 24 cores / 48 threads), 256 GB DDR5 ECC, 2 × 1.92 TB NVMe in RAID 1, 100 TB a month at 1 Gbit/s, 1 IPv4 and an IPv6 /64 | $356.25 |
| KoDDoS: EPYC-9354-768GB-3.84TB-NVMe-10Gbps-Hong-Kong | AMD EPYC 9354, 32 cores / 384 GB / 3.84TB NVMe | $475.00 |
| Median of 7 hosts | Comparable 24-core servers | $999.57 |
| Lumenfer Lumen 32 | AMD EPYC 9354 (2022, 32 cores / 64 threads), 384 GB DDR5 ECC, 2 × 3.84 TB NVMe in RAID 1, 150 TB a month at 1 Gbit/s, 1 IPv4 and an IPv6 /64 | $749.67 |
| MonoVM: EPYC 9354/384/2x3.84TB NVMe | EPYC 9354, 32 cores / 384 GB / 2x3840 GB | $999.57 |
| Median of 6 hosts | Comparable 32-core servers | $1476.45 |

*Prices checked on October 30, 2026.*

Crypto-paying hosts with no ID check at signup; 2022+ CPU, NVMe only, monthly billing. 1 EUR = 1.1172 USD (ECB, 30 October 2026). MonoVM accepts crypto through several processors, including Cryptomus/Heleket, a processor the UK designated for sanctions on 8 October 2026.

## 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](https://lumenfer.com/aws-to-bare-metal/ "Should I move from AWS to bare metal servers?").

## Rent a PostgreSQL server

Whole machines with root access, billed per 30 days, 3 months, 6 months or 12 months from a crypto balance.

| Plan | Quantity | 30 days | 3 months | 6 months | 1 year |
| --- | --- | --- | --- | --- | --- |
| Lumen 6 | 6 cores · 32 GB DDR5 | $91.65 | $247.45 (−10%) | $439.92 (−20%) | $769.86 (−30%) |
| Lumen 24 | 24 cores · 256 GB DDR5 | $356.25 | $961.87 (−10%) | $1,710 (−20%) | $2,992.50 (−30%) |
| Lumen 32 | 32 cores · 384 GB DDR5 | $749.67 | $2,024.10 (−10%) | $3,598.41 (−20%) | $6,297.22 (−30%) |

In every plan: 2022+ CPU · DDR5 · NVMe only · RAID 1 · Dedicated IPv4 · No KYC

**Before you pay**

- Minimum top-up $25. Top up once in crypto, then buy any plan from your balance.
- Credit on your balance does not expire and renews any of your servers. When a top-up is only made to reach the minimum, the unspent part comes back on request within 30 days of payment, in USDT or USDC. The rest of a balance is not paid out unless the law requires it.
- Credited once your payment is checked on the blockchain. Typical network confirmation time: BTC ≈ 20 min · USDT TRC-20 ≈ 1 min · USDT ERC-20 ≈ 5 min · USDC ERC-20 ≈ 5 min · ETH ≈ 5 min · SOL ≈ 1 min · LTC ≈ 15 min

## PostgreSQL dedicated server hosting: FAQ

### How much RAM do I need for a 100 GB PostgreSQL database?

Aim to keep the hot part of the data in memory. With 128 GB or more, the whole 100 GB fits in shared_buffers plus the kernel cache. The manual then allows a lower random_page_cost, since reads rarely touch the disk.

### Can I run PostgreSQL in Docker on the server?

Yes. Huge pages and overcommit are host settings, though, so set them on the server itself, not inside the container. Store the data directory on the NVMe mirror, not in the container's writable layer.

### Which Linux image should I pick for PostgreSQL?

Any of them: Debian 13, Debian 12, Ubuntu 24.04 LTS, AlmaLinux 10, Rocky Linux 10 and Proxmox VE 9. Pick the distribution your team already patches. Proxmox VE suits you only if PostgreSQL will run inside virtual machines.

### Does Lumenfer manage or tune PostgreSQL for me?

No. You get root on a whole machine; installing, tuning and upgrading PostgreSQL is your job. The team handles the hardware, reboots and reinstalls you request in the dashboard.

### Can I pay for a database server without ID?

No KYC: we never ask for an ID, a selfie, documents, a card or a phone number. Top up in BTC, USDT, USDC, ETH, SOL, LTC (minimum $25) and order from the balance. Servers are prepared by a person once your payment is confirmed, within 72 hours rather than instantly; the dashboard shows progress and then the IP address when the machine is ready.

## Sources

1. [18.4. Managing Kernel Resources (overcommit, huge pages)](https://www.postgresql.org/docs/current/kernel-resources.html) — PostgreSQL 18 documentation (read 2026-11-01)
2. [19.4. Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html) — PostgreSQL 18 documentation (read 2026-11-01)
3. [19.7. Query Planning (random_page_cost, effective_cache_size)](https://www.postgresql.org/docs/current/runtime-config-query.html) — PostgreSQL 18 documentation (read 2026-11-01)
4. [19.3. Connections and Authentication (max_connections)](https://www.postgresql.org/docs/current/runtime-config-connection.html) — PostgreSQL 18 documentation (read 2026-11-01)
5. [28.1. Reliability (write caches, checksums, ECC)](https://www.postgresql.org/docs/current/wal-reliability.html) — PostgreSQL 18 documentation (read 2026-11-01)
6. [28.6. WAL Internals (WAL on a separate disk)](https://www.postgresql.org/docs/current/wal-internals.html) — PostgreSQL 18 documentation (read 2026-11-01)
7. [Chapter 25. Backup and Restore](https://www.postgresql.org/docs/current/backup.html) — PostgreSQL 18 documentation (read 2026-11-01)
8. [15.1. How Parallel Query Works](https://www.postgresql.org/docs/current/how-parallel-query-works.html) — PostgreSQL 18 documentation (read 2026-11-01)
9. [1.2. Architectural Fundamentals (a process per connection)](https://www.postgresql.org/docs/current/tutorial-arch.html) — PostgreSQL 18 documentation (read 2026-11-01)
10. [OSS usage recommendations (overcommit)](https://clickhouse.com/docs/operations/tips) — ClickHouse documentation (read 2026-11-01)
11. [EPYC-9354-3.84TB-NVMe-10Gbps](https://koddos.net/clients/store/amd-dedicated-server/epyc-9354-384tb-nvme-10gbps) — KoDDoS (read 2026-10-30)
12. [Dedicated servers](https://monovm.com/dedicated-server/) — MonoVM (read 2026-10-30)

---

Lumenfer: Lumenfer rents current-generation bare-metal servers in Amsterdam, Reykjavik, Zurich and Bucharest, paid in crypto with no KYC: no ID, no selfie, no documents. Every machine has a CPU launched in 2022 or later, DDR5 memory and NVMe drives, and is rented whole by one customer with root access. It is run by DomaineGoat LLC, a Panama company that ignores DMCA notices, answers only to Panamanian law, allows Tor exit relays and keeps no logs. On the 30-day term, every plan is priced at least 25% under a named comparable current-generation server from 13 no-KYC crypto hosts, read on 30 October 2026.