Database Hardware Sizing: CPU, Memory, NVMe, RAID and IOPS
Learn database hardware sizing for PostgreSQL, MySQL, SQL Server, Oracle, MongoDB and MariaDB across CPU, memory, NVMe/SSD, RAID, latency, IOPS, NUMA and virtualization.
What does this guide solve?
Database server sizing should start from measured workload, not product datasheets. CPU, memory and storage cannot indefinitely compensate for each other.
CPU sizing
OLTP often values high clock speed and low query latency, while analytical workloads can benefit more from core count and parallelism.
Monitor run queue, query CPU time, context switching, NUMA and virtualization steal/ready time—not CPU percentage alone.
Memory sizing
The goal is to keep as much active data/index working set in memory/cache as practical. PostgreSQL, InnoDB, SQL Server and MongoDB use memory differently.
Swap/paging can create severe performance problems for production databases.
Storage latency and IOPS
Database storage is about random IOPS, p95/p99 latency, queue depth and durable writes—not only MB/s throughput.
NVMe is especially valuable for logs/journals/temp space and heavy random I/O.
RAID and redundancy
RAID10 is commonly evaluated for transaction workloads because of performance and redundancy balance; RAID5/6 write penalty and rebuild impact need workload-specific analysis.
RAID is not backup, and controller write cache should be protected against power loss.
Virtualization
Databases can run very successfully in VMs, but control CPU overcommit, NUMA alignment, ballooning, shared-storage contention and noisy neighbours.
Critical database VMs may justify resource reservations and storage QoS.
Frequently Asked Questions
How many CPU cores does a database need?
There is no fixed formula. Size from query concurrency, CPU time and licensing model.
Is RAID10 always required?
No. Workload, storage technology, cloud design and redundancy model differ; it is often considered for write-heavy systems.
Are databases slow in virtual machines?
Not inherently. Well-designed virtual infrastructure can perform very well; overcommit and shared contention must be controlled.
Evaluate Your Database Infrastructure
We can review workload, security, hardware, HA and backup requirements together.