Databases
Run PostgreSQL, MySQL, ClickHouse or Redis on a dedicated database server where the buffer pool, the NVMe queue and every EPYC core serve one tenant: you.
Every EPYC plan uses ECC DIMMs, which correct bit errors on the way to the CPU, not only inside the chip like DDR5’s on-die ECC.
From 128 GB to 384 GB of RAM, so the hot part of your data is served from the buffer pool instead of the disks.
Random reads and fsync-heavy commits go straight to local NVMe, with no network block storage or shared queue in between.
Link primary and replica in the same location over a free private VLAN, or across regions through a WireGuard tunnel.
Recommended servers
From a first deployment to a busy production setup. Live stock and prices; in-stock picks are online in minutes.
Our pickPrimary for a growing app
12C / 24T · 3.7–5.4 GHz
12 Zen 4 cores up to 5.4 GHz favor fast single queries; 128 GB DDR5 ECC and 2 × 1.92 TB NVMe suit most OLTP databases under a terabyte.
Large OLTP or analytics
24C / 48T · 2.85–4.0 GHz
24 cores, 256 GB of 8-channel DDR4 ECC and 2 × 3.84 TB NVMe on 10 Gbps, for big buffer pools, parallel queries and quick replica rebuilds.
ClickHouse and big data
32C / 64T · 3.25–3.8 GHz
32 Zen 4 cores, 384 GB of 12-channel DDR5 ECC and 256 MB of L3 for scans and aggregations over billions of rows, on a 10 Gbps port.
Sizing
These bands are rough guides, not measurements: what matters is how much of your data is hot, so check cache hit ratios on your current system before you pick.
| Database profile | What drives the size | Suggested plan |
|---|---|---|
| PostgreSQL or MySQL under ~500 GB | Hot data fits in 128 GB; fast cores for single queries | AMD EPYC 4464P |
| Valkey or Redis cache and sessions | Dataset in RAM plus headroom for fork-based snapshots | AMD EPYC 4464P |
| OLTP with 1–2 TB of data, many clients | Bigger buffer pool, more cores, PgBouncer in front | AMD EPYC 7443P |
| MongoDB replica set member | WiredTiger cache near half of RAM; working set in memory | AMD EPYC 7443P |
| ClickHouse analytics on billions of rows | Cores and memory bandwidth for scans; NVMe for parts | AMD EPYC 9354P |
Expert notes
Short, practical advice from our engineers for this workload.
A commit is only durable once it reaches stable storage. On a primary, keep the safe defaults: fsync = on in PostgreSQL, innodb_flush_log_at_trx_commit = 1 and sync_binlog = 1 in MySQL or MariaDB. If losing the last instant of commits after a crash is acceptable, PostgreSQL’s synchronous_commit = off trades that window for speed without risking corruption.
cat /proc/mdstat.pg_test_fsync before tuning anything.recordsize to the page size (16K for InnoDB, 8K for PostgreSQL as a starting point) and cap the ARC so it doesn’t fight the buffer pool.A database that reads from RAM rarely waits. Size memory to the hot data, then tune each engine so it doesn’t fight the others or the OS:
shared_buffers around 25% of RAM, effective_cache_size around 70%, and a modest work_mem, since every sort or hash in every query can claim it.innodb_buffer_pool_size at 60–75% of RAM on a server that runs nothing else.maxmemory well below RAM, because snapshots fork the process and copy-on-write needs headroom.max_memory_usage so one heavy report can’t take down the server.Then watch the cache hit ratio: if it drops under load, more RAM usually helps more than faster disks.
Keep the replica you would fail over to in the same location, linked by a free private VLAN: latency stays low enough that synchronous replication is affordable. Add an asynchronous replica in another location over WireGuard for disaster recovery; a synchronous commit across an ocean would wait for the round trip on every transaction.
Root access means you install exactly what you need. These are proven choices for this workload.
FAQ
For any database you cannot rebuild from elsewhere, yes. A flipped bit in RAM can be written to disk as a valid-looking page and then copied to every replica and backup. ECC corrects single-bit errors and flags double-bit ones. All EPYC plans use ECC; the Performance-family Ryzen plans use non-ECC DDR5, which is fine for caches and stateless apps but a weaker choice for a primary database.
Keep the default RAID 1 on a primary: it survives a failed NVMe while the drive is replaced, which our SLA targets within four hours of diagnosis. RAID 0 doubles capacity and write bandwidth but loses everything with one drive, so reserve it for replicas you can rebuild. ZFS adds checksums, compression and snapshots, in exchange for tuning recordsize and the ARC.
For PostgreSQL, set the new server up as a streaming replica with pg_basebackup, let it catch up, then promote it during a short write freeze. MySQL and MariaDB work the same way with a mariadb-backup or XtraBackup copy plus replication. Logical dumps are simpler but slower on large databases, and they need downtime that grows with the data size.
ClickHouse spreads scans across every core and benefits from memory bandwidth, so the EPYC 9354P, with 32 cores, 12-channel DDR5 and 384 GB, is the natural pick for large tables. Smaller analytics workloads fit the EPYC 7443P. Columns often compress to a fraction of their raw size, so 2 × 3.84 TB of NVMe holds more data than the raw number suggests.
Yes, and on one machine you save a network hop on every query. Give the database a fixed memory budget first, let the application use what is left, and pin heavy workers to separate cores if they compete. Split them once the app needs to scale out or the database needs a replica: the private VLAN keeps the link between them off the internet.
Pick one of the recommended in-stock servers and it can be online in minutes. Need something bigger or different? Our engineers quote custom builds within one business day.