Database Server Hardware: Cores, Clocks and Memory

Database servers are where the buy-more-cores reflex goes wrong. An OLTP database spends its life executing many short transactions, each mostly single-threaded, each sensitive to lock and log latency. That profile rewards clock speed, cache and memory capacity — and, thanks to per-core licensing on the big commercial engines, it actively punishes surplus cores.

CPU: frequency first

For transactional work, eight fast cores routinely beat sixteen slow ones. On refurbished platforms the interesting parts are the frequency-optimized SKUs: Xeon E5-2643 v4 and E5-2667 v4 (3.2–3.4GHz base) on 13G/Gen9 platforms, and Gold 6134/6144-class parts (8 cores at high clocks, generous cache) on Scalable systems like the R640 or DL360 Gen10. Analytics and warehousing invert the logic — parallel scans love cores — but for the classic ERP/CRM/e-commerce backend, buy gigahertz.

Licensing belongs in the hardware decision

SQL Server and Oracle price per core, with per-server minimums. A 24-core pair can cost several times the hardware's price every year in licenses it does not need. The refurbished market makes the right-sizing trivial: choose the 8-core high-clock SKU, populate one socket if the workload allows, and put the savings into RAM and NVMe. This is one of the few areas of IT where the cheaper hardware decision and the faster one are the same decision.

Memory: buy the working set

The goal is for the hot portion of the database — the pages actually being read and written all day — to live in the buffer pool. Watch the buffer cache hit ratio and page-life metrics on the current system; if the hot set is 80GB, a 128GB server transforms performance and a 512GB server adds little. Populate channels evenly (all four per socket on E5, all six on Scalable) so the capacity arrives with its bandwidth.

Storage: latency is the metric

Transaction commit speed is bounded by log-write latency. Enterprise NVMe changes the game here — sub-100µs writes versus roughly ten times that on SATA SSDs. The clean refurbished pattern: a mirrored pair of NVMe drives for data and log (separated if the engine benefits), power-loss protection non-negotiable, and a separate boring mirror for the OS. Platforms matter: the R640 offers NVMe-capable bay configurations, and U.2 support generally begins in earnest with 14G/Gen10 — worth choosing that generation for a database role even when a 13G box looks cheaper.

The rest of the box

Redundant PSUs, obviously. Out-of-band management, obviously. And one deliberate decision: keep the database on bare metal or give it a dedicated host. Sharing a hypervisor with twenty general VMs invites noisy-neighbor latency of exactly the kind transactions feel most.

A reference build: Dell R640 8SFF, 2× Gold 6134, 192GB in twelve 16GB RDIMMs, two 1.6TB power-loss-protected NVMe drives mirrored for the database, two SATA SSDs for the OS, dual 10GbE. Fast where the database feels it, cheap where it does not, and licensed like a machine half its apparent size.