Fast, predictable databases on NVMe Gen5 bare metal

Database performance on modern hardware is mostly a question of what fits in memory. Estimate your working set, the tables and indexes your queries touch in a typical hour, not the full size on disk. If it fits in RAM with room to spare, reads come from memory and the NVMe drives mostly absorb writes.

Starting points for a server dedicated to the database:

• PostgreSQL: shared_buffers at about 25% of RAM and effective_cache_size at about 75%; the OS page cache does the rest.
• MySQL and MariaDB (InnoDB): innodb_buffer_pool_size at 60 to 75% of RAM.
• Redis and Valkey: set maxmemory well below physical RAM, leaving headroom for fork-based snapshots.

As an estimate, assuming about 30% of RAM stays free for connections, sorts and the OS, a Pro 32 caches a working set of roughly 270 GB, a Pro 48 about 400 GB and a Pro 64 about 540 GB. Bandwidth matters too: 12 channels of DDR5-6000 give each EPYC 9005 socket about 576 GB/s of theoretical peak memory bandwidth.

Every Pro server has at least two NVMe Gen5 drives, so mirror them. Software RAID 1 with mdadm, or a ZFS mirror, keeps the database running through a drive failure, and spare parts on site in every location mean the failed drive can be replaced quickly. On a Pro 64, RAID 10 across the four drives gives roughly twice the write bandwidth of a single mirror.

Choices that matter more than raw drive speed:

• File system: XFS or ext4 mounted with noatime. On ZFS, a common starting point is a recordsize matching the database page: 8K for PostgreSQL, 16K for InnoDB.
• No parity RAID for write-heavy databases: RAID 5 and 6 turn small random writes into read-modify-write cycles.
• Benchmark first: run fio with your block size and pgbench or sysbench at your concurrency before migrating, and keep the results as a baseline.
• Free space: copy-on-write file systems and SSDs slow down when nearly full, so plan to stay under about 80%.

Our guide to software RAID on NVMe with mdadm covers the setup step by step.

Run the standby in the same location and connect it over a free private VLAN: replication stays off the public interface and internal traffic is not billed. A typical high-availability layout:

• Two identical Pro servers as primary and standby, with synchronous or asynchronous replication.
• A failover manager: Patroni with etcd for PostgreSQL, or MySQL InnoDB Cluster, with a third small node such as a Core 16 for quorum.
• A routing layer: HAProxy with Patroni health checks, or MySQL Router, so clients always reach the current primary. Add PgBouncer for connection pooling.

For disaster recovery, add an asynchronous replica in a second location over WireGuard or TLS. Traffic is unmetered, so cross-site replication adds no transfer cost. Keep backups separate from replicas: a replica copies a bad DELETE instantly, while a backup lets you go back in time. pgBackRest or Percona XtraBackup to a Storage 264 handles large archives well.