The patented methodology behind "more per core", and what it means for your budget
The question sounds too good to be true. Can you run the same SQL Server workloads on fewer CPU cores, without degrading performance?
The answer, supported by internationally patented methodology and validated across over 200 production environments, is yes. Typically 30–50% fewer cores. With the same workload throughput. Often with improved stability.
Here's how it works and what it's worth.
Why organizations overprovision SQL Server cores
SQL Server core provisioning decisions are typically made under uncertainty. At deployment time, the team knows the initial workload but not how it will grow. The standard response to uncertainty is overprovisioning. Add headroom, avoid future capacity crises, plan for growth.
This is rational. The problem is that the headroom, once provisioned, is rarely revisited. Workloads evolve. Some grow. Many stabilize or shrink. Systems that were genuinely needed at 64 cores three years ago may now sustain their workload at 44.
Without dedicated capacity analysis, no one knows. And because SQL Server licensing is typically paid annually regardless of utilization, the unnecessary cores continue to be licensed indefinitely.
What capacity optimization actually requires
Reducing SQL Server core requirements safely is not a simple matter of looking at average CPU utilization and applying a discount. Several factors must be modeled correctly.
Peak workload demand, not average demand, determines the minimum required capacity. An environment averaging 25% CPU might spike to 85% for two hours every quarter-end. The right-sized environment must handle that spike, not just the average.
Workload parallelism affects core requirements differently than serial processing. SQL Server's parallel query execution, degree of parallelism settings, and CPU thread availability interact in ways that require per-environment modeling.
VMware virtualization adds another dimension. vCPU-to-pCPU ratios, CPU Ready time, and vSphere scheduling behavior affect SQL Server performance in ways that standard monitoring metrics may not fully reflect.
Hardware platform matters. A 44-core environment on a modern, high-benchmark processor may outperform a 64-core environment on older hardware. SQL Governor uses spec.org chipset performance benchmarks to factor this into capacity modeling, ensuring that right-sizing recommendations are platform-specific, not generic.
What the patents protect
SQL Governor holds internationally granted patents covering two core capabilities relevant to SQL Server cost optimization.
The first covers the methodology for automated capacity analysis and workload-to-topology matching — the process of calculating optimized CPU, RAM, and storage requirements for a target SQL Server topology given actual workload patterns and business constraints.
The second covers predictive anomaly detection for SQL Server performance counter regression and CPU contention, enabling proactive identification of workloads that are approaching capacity limits before they create incidents.
These are not interface patents or minor process improvements. They represent a fundamentally different approach to understanding and optimizing SQL Server capacity, one that the market has not previously had access to.
The numbers
Tampa General Hospital: approximately 40% TCO reduction. Production clinical systems. Zero performance degradation.
Across 200+ optimization engagements: 98% delivered significant savings. Median savings: 30–40% of SQL Server licensing and hardware combined.
For a 10-server environment with a combined five-year TCO of €2M, that represents €600,000–€800,000 in recoverable cost. On a single 8-socket environment at current pricing, the savings potential exceeds €800,000 over five years.
These numbers come from production environments, with documented before-and-after configurations. They are not theoretical projections. They are measured outcomes from the methodology this post describes.
The question is not whether SQL Server core optimization delivers value. The question is how long your organization wants to wait before capturing it.
Timo Lindström
CEO, SQL Governor