Specifying a SQL Server or Oracle database host: cores, licensing and NVMe (UK 2026)

A database host is the one server where buying the wrong CPU costs you twice — once for the silicon, and every year after in per-core database licences. Get the core count, memory and storage latency right and a modest two-socket box will outrun a far bigger, badly-specified one. Here is how we spec SQL Server and Oracle hosts for UK customers.

Sizing a database CPU

Cores cost twice: silicon and licence

SQL Server Enterprise and Oracle Database are licensed per core. Every core you add is a recurring licence line, so the goal is the fewest, fastest cores that meet the workload — the opposite of a scale-out web tier. High-frequency, lower-core-count SKUs (and Oracle's core factor) often slash licence spend while improving single-query latency.

Pin the database to whole NUMA nodes where possible and size the VM/host so the working set stays NUMA-local — remote memory access is a silent tax on OLTP latency.

Memory: fit the working set, then some

Databases love RAM. Size to hold the hot working set (plus tempdb / SGA / PGA) in memory, populate channels evenly for full DDR5 bandwidth, and leave headroom for growth. Memory bandwidth — not just capacity — drives analytical query throughput, which is where channel count on Xeon 6 and EPYC matters.

Storage is latency, not just IOPS

Put data, log and tempdb on low-latency NVMe. Logs are latency- and write-sensitive (favour write-intensive or mixed-use endurance), data files are throughput-and-capacity, tempdb is bursty. Gen5 NVMe and a sensible tier layout matter more here than raw drive count.

•Log: low-latency, write-intensive/mixed-use NVMe, isolated
•Data: mixed-use NVMe sized for capacity + throughput
•tempdb / scratch: fast NVMe, generously provisioned
•Boot: separate mirrored BOSS/M.2 — never on the data tier

Database host storage layout

Resilience and HA

Dual PSUs, redundant fans, ECC memory with the platform's RAS features (patrol scrub, ADDDC) and out-of-band management are table stakes. For HA, decide early between Always On Availability Groups / Data Guard (application-level) and cluster-level protection — it changes how many hosts and what shared/local storage you buy.

Choosing the box

For most UK database workloads this lands on a 1U/2U dual-socket Dell PowerEdge, HPE ProLiant or Lenovo ThinkSystem with high-clock CPUs and all-NVMe storage; very large in-memory databases move up to a four-socket scale-up server. Pick the CPU with our processors guidance, the drives with SSD & NVMe, and build the host in the configurator.

FAQs — Specifying a SQL Server or Oracle database host

CPU & licensing

How many cores for a SQL Server host?

Fewer than you think — SQL Enterprise is licensed per core, so target the smallest core count that meets the workload using high-clock CPUs. This usually cuts both licence spend and query latency. See our processor selection guide.

Does CPU choice affect Oracle licence cost?

Yes — Oracle applies a core factor per processor type, so the CPU you choose changes the licence maths directly. High-frequency, lower-core SKUs often win. We model licence-inclusive TCO when you scope a build with us.

Storage

What NVMe layout for a database server?

Isolate the transaction log (low-latency, write-intensive/mixed-use), put data files on mixed-use NVMe sized for capacity and throughput, and give tempdb/scratch fast generously-provisioned NVMe. Boot from a separate mirrored device. More in our NVMe guide.