How SQL Tuning Saved Six Figures and Cut Cores by 75%

An ERP software company was running SQL Server on a 16-core Azure VM with serious performance and reliability issues. Their vendor’s recommendation: add more power.

We tuned instead — two rounds of optimization plus a SQL Server 2022 migration took them from 16 cores to 4. Their customer count increased. Their licensing bill dropped by six figures.

Key Takeaways

• 16 cores → 8 → 4 in two tuning rounds — each round cut cores in half while handling more workload.
• Two 16-core servers (Always On AG) became two 4-core servers — 32 total cores down to 8, with high availability preserved.
• Configuration, maintenance, and query optimization — not hardware upgrades — drove the reduction.
• SQL Server 2022 migration contributed to the second round of core reduction.
• SQL licensing savings alone approached six figures — list price for Enterprise is ~$15K per 2-core pack. Cut 24 cores and the math is obvious.
• “Add more power” is the most expensive wrong answer in SQL Server performance.

We did a SQL Server Check Assessment. Three categories of problems surfaced:

• Configuration issues. Parallelism settings that create thread contention, memory allocation that didn’t match the workload, TempDB layouts misaligned with the core count. Default settings on a production server are a reliable source of wasted CPU — and every wasted cycle is spend.
• Missing maintenance. Stale statistics meant the optimizer was choosing bad plans confidently. Degraded indexes meant more I/O than necessary. No consistency checks meant corruption risk sitting undetected. Skipping maintenance turns a well-configured server into a sluggish one over time.
• Inefficient queries. Missing indexes, unnecessary scans on large tables, suboptimal execution plans — the kinds of problems that make a server look CPU-starved when it’s actually just doing unnecessary work.

None of these required more hardware. All of them required attention.

Round 1: 16 Cores to 8

We addressed configuration and maintenance first — the changes that affect every query on the server without touching application code.

After fixing configuration issues and implementing proper maintenance procedures, CPU utilization dropped enough to cut cores in half.

We validated each downsizing step under production-like load, watching top CPU queries before and after. The 16-core instance moved to 8 cores with equal or better performance.

This is the pattern we see repeatedly: a significant portion of CPU usage on most SQL Servers isn’t workload — it’s waste. Fix the waste and the hardware requirement shrinks.

Round 2: 8 Cores to 4

The second round focused on query-level optimization and a migration to SQL Server 2022.

Query tuning targeted the highest-resource consumers in the workload — the queries responsible for the most CPU, the most reads, the most execution time. Optimizing even a handful of top offenders can dramatically change the server’s resource profile.

The SQL Server 2022 migration also contributed — but only after we raised compatibility level to 160 and validated plan behavior.

Features like Parameter Sensitive Plan optimization (PSP) require compat 160; upgrading binaries alone doesn’t unlock them.

Once enabled, engine-level improvements — Intelligent Query Processing, better cardinality estimation, PSP — reduced CPU for certain query patterns without code changes. The magnitude varies by workload, but in this case the combination of query tuning and engine improvements was enough to cut cores in half again.

Eight cores became four. Performance improved. The customer count on the platform increased.

Full Picture: 32 Cores to 8

The client was running Always On Availability Groups — two servers for high availability. Both were 16-core instances. Both went through the same optimization process.

Two 16-core servers became two 4-core servers. Thirty-two total cores became eight. High availability stayed intact. The workload grew.

Licensing Math

SQL Server 2022 Enterprise lists at about $15,000 per 2-core pack (discounts vary by agreement, Azure Hybrid Benefit, and whether you’re on perpetual + SA or subscription/PAYG). The reduction:

• Before: 32 cores total (2 servers × 16 cores) = 16 two-core packs
• After: 8 cores total (2 servers × 4 cores) = 4 two-core packs
• Reduction: 12 two-core packs at list price = significant six-figure licensing delta

We took both nodes down to 4 cores — the per-VM licensing minimum — so the configuration is as lean as it can sensibly go.

Whether the savings show up as reduced perpetual license capex or lower subscription/PAYG spend depends on the licensing model. Either way, cutting 24 cores out of your SQL Server footprint is a linear cost reduction. Between licensing and smaller VM sizes, total savings landed in the low six figures.

The vendor’s recommendation — more cores — would have moved costs in the opposite direction.

Why “Add More Power” Is the Wrong Default

When SQL Server performance degrades, the organizational instinct is to scale up. It’s fast, it’s easy to approve, and it doesn’t require anyone to investigate what’s actually happening.

But scaling up doesn’t fix:

• Configuration settings that waste CPU on every query
• Stale statistics that cause the optimizer to choose bad plans
• Missing indexes that force unnecessary scans on large tables
• Queries that consume 10x the resources they should

Scaling up just runs the same waste on a bigger machine. You pay more, and the underlying problems remain — ready to surface again when the workload grows.

The harder path — investigate, diagnose, fix — takes longer. But it’s the only path that reduces costs while improving performance.

When to Tune vs. When to Scale

Not every server can be tuned down to 25% of its original cores. This result required specific conditions:

• Access to the workload. We could analyze and optimize queries. If you’re running a sealed vendor application with no ability to modify queries or add indexes, your tuning options are limited (though configuration and maintenance improvements still apply).
• A configuration that had never been reviewed. Default settings on a production server are a reliable source of wasted resources. If someone has already optimized your configuration, the gains from that step will be smaller.
• Maintenance that didn’t exist. A server running for years without statistics updates or index maintenance has accumulated significant performance debt. Paying that debt back delivers large, immediate improvements.
• Workload characteristics that responded to tuning. OLTP workloads with many small queries and predictable access patterns tend to benefit most from indexing and optimization. Analytical or warehouse workloads with unavoidable large scans may genuinely need the cores.

If you’ve already tuned configuration, maintained statistics, optimized your top queries, and CPU is still high — then scaling is the right answer. Scale because you’ve confirmed the workload needs it, not because nobody looked.

Bottom Line

The client was told to add more power. We removed waste instead.

Sixteen cores became four. Two 16-core HA servers became two 4-core servers. Customer count went up. Licensing costs dropped by six figures.

Fast systems are never an accident. They’re the result of someone actually looking at what’s happening inside the database.