Azure SQL cost optimization starts with the tier. Fix it before you tune a single query.

Azure SQL cost is set by the service tier and the commitment you size against real workload. Most overspend is provisioned compute running all day for a database busy a few hours, and query tuning cannot recover that gap.

Why does the service tier decide most of your Azure SQL cost?

The service tier and purchasing model set the price of every hour a database runs, before any query is tuned. In our reviews, roughly 3 of 5 databases sat on a tier sized for peak load while average load ran at 15 to 30 percent of capacity. That gap costs more than any index or query plan fix will return.

It usually starts at migration. The database was sized for its busiest hour, then left on provisioned compute around the clock. Most databases are busy a few hours a day, so the rest of the day is paid for and idle. A flat CPU line well under the tier ceiling is the clearest sign of it.

Which cost options apply once the tier is right?

Once the tier matches the workload shape, five cost options apply. We list them in order of effort, cheapest first, because the first two are billing changes that need no engineering work.

DTU or vCore: which purchasing model should cost work start from?

Start from vCore. It prices compute and storage separately, which makes right sizing visible, and it is the only model that accepts reserved capacity and Azure Hybrid Benefit. DTU bundles compute, memory and IO into one number. That suits small, stable databases where simplicity matters more than cost, but it is harder to optimize.

Microsoft's rule of thumb for the migration is at least 1 vCore for every 100 DTUs in Basic or Standard, and at least 1 vCore for every 125 DTUs in Premium. Treat that as a starting size, then correct it on measured load. The change behaves like a normal scaling operation, with a short connection drop at the end.

Which compute tier fits which workload shape?

• Provisioned compute. Fits steady, predictable load that runs most of the day. It bills by the hour whether the database is busy or not.
• Serverless. Fits intermittent, spiky and development workloads. It scales between a minimum and maximum vCore setting and bills per second of compute used. In General Purpose it can pause after an idle delay of at least 15 minutes, and a paused database pays for storage only. Hyperscale serverless scales but does not pause.
• Hyperscale. Separates compute from storage for very large databases and can cost less at scale than Business Critical. For small databases the tier overhead may not pay off.
• Business Critical. Buys local storage and replicas for latency sensitive systems. Check that the application needs it, because a General Purpose database with the same vCores costs less.

The wider Azure cost model this sits inside is covered in our Azure cost optimization playbook.

How do you find out what each Azure SQL database really uses?

Pull two weeks of resource history per database and compare average and peak load with what the tier provides. Size on that fortnight of observed data, and ignore the figure inherited from the migration project. Azure already keeps most of what you need.

• sys.resource_stats. Query it from the master database on each logical server. It holds CPU, data IO, log IO and storage figures in five minute intervals for roughly 14 days, which is exactly the window you want.
• sys.dm_db_resource_stats. Query it inside the user database for 15 second samples over the last hour. Use it to confirm a spike pattern while it happens.
• Azure Monitor metrics. CPU percentage, data IO percentage and, for serverless, billed vCores. Azure Monitor keeps platform metrics for 93 days, so use it when the busy period you need, such as a month end or quarter end close, falls outside the 14 day window.
• Cost Management and the license type setting. Group cost by resource and by meter to see which databases carry the bill. The license type on each database or instance shows whether it pays the license included rate or uses Hybrid Benefit.

Build one inventory row per database: tier, purchasing model, vCores or DTUs, average and peak CPU, the hours per day it is busy, license type and reservation coverage. That table drives every decision below.

When do reserved capacity and Hybrid Benefit pay off?

Both pay off on stable databases that will run for the whole term, and both punish commitments made ahead of a credible forecast. Reserved capacity lowers the compute rate on a one or three year term. Hybrid Benefit removes the SQL license charge where you already own the licenses, and the two apply to the same database together.

How does Azure SQL reserved capacity work?

You commit to a quantity of vCores in a region and performance tier, and Azure applies the lower rate to matching usage each hour.

It discounts compute on primary and billable secondary replicas, while storage, networking and the SQL license are billed separately. It applies to single databases, elastic pools and Managed Instance. DTU databases are excluded, and serverless is not covered.

• Size flexibility. You can scale within the same performance tier and region and keep the discount.
• Scope. A reservation scoped to one subscription stops helping when a database is relocated to another subscription, so a shared or management group scope is usually safer.
• Payment. Pay upfront or monthly. The monthly option spreads cost without changing the rate.
• Exchanges. SQL reservations can be exchanged between SQL Database, elastic pool and Managed Instance, which helps if a migration changes the target service.

Commit only the compute you are confident will run the full term, and cover the variable remainder with serverless or pay as you go. Our reservations and savings plans guide compares the commitment types, including the newer savings plan for databases, an hourly spend commitment that also covers serverless and Hyperscale.

How do SQL Server licenses convert under Hybrid Benefit?

SQL Server core licenses with active Software Assurance, or SQL Server subscription licenses, apply to Azure SQL Database vCore provisioned compute and to Managed Instance. The conversion depends on edition and target tier, and an Enterprise core goes four times as far on General Purpose.

• Dual use during migration. You get 180 days in which the same licenses can cover on premises servers and Azure at once. After that, a license used in Azure must leave its on premises server.
• Central assignment. Customers on an EA or a Microsoft Customer Agreement can assign licenses at billing account or subscription scope in Cost Management, and Azure applies them to running resources each hour.

The license mapping detail is in our Hybrid Benefit optimization guide, and the SQL Server licensing rules behind it sit in the SQL Server licensing guide.

What changes for Hyperscale databases in December 2026?

Hyperscale no longer needs Hybrid Benefit. Since December 15, 2023, new Hyperscale databases, serverless Hyperscale and Hyperscale elastic pools bill at a lower compute price with no separate SQL license charge. Hyperscale single databases created before that date can still use Hybrid Benefit, but only until December 2026, when they move to the same simplified pricing.

If you still assign licenses to older Hyperscale databases, list them now. Those cores become free to cover General Purpose or Managed Instance compute that is still paying the license included rate.

When do serverless and elastic pools beat provisioned compute?

• Serverless. Wins for spiky, intermittent or development databases, cutting 20 to 60 percent against provisioned compute that runs all day. The saving depends on idle time, so check the hours per day each candidate is busy before you move it.
• Elastic pools. Win when many databases peak at different times. You pay for the shared pool instead of every individual peak, a 15 to 40 percent saving where peaks are offset. Pools still take reserved capacity and Hybrid Benefit.

What does the fix look like on a 20 database example?

Say you run 20 Azure SQL databases, all provisioned, with $400,000 a year of compute at pay as you go rates. Six are always on production systems costing $200,000. Eight are reporting and internal apps busy a few hours a day, costing $100,000. Six are development and test databases with offset peaks, also $100,000.

The total saving is $146,200, about 37 percent. Every rate in the table is an illustrative point inside the ranges above, and real discounts vary by region, hardware generation and tier. The order matters: right sizing first means the reservation and the license assignment cover the smaller footprint.

Reversing that order is the costly version. A reservation bought on the original $200,000 production footprint would lock in the headroom that right sizing was about to release.

Why fix the Azure SQL tier before tuning queries?

Fix the tier, the purchasing model and the commitment first. Query and index work still matters, and it can let you drop a size once the structure is right. On the wrong tier, though, the saving is small against the fixed cost of idle capacity.

Why we do not start with query tuning

The standard guidance says tune queries and indexes first, then look at cost. We think that order is backwards. A 20 percent cut in CPU on a database that already idles most of the day changes nothing on the invoice until someone drops the tier, so the structural overspend dwarfs any query gain.

Change the tier and the commitment first, then tune, then check whether the tuned workload fits a smaller size.

Tuning a query on the wrong tier just makes the wrong bill slightly smaller.

How do you keep the savings after the first pass?

Savings from the first pass erode unless someone owns them, because new databases tend to be created on oversized tiers and reservations expire. A light monthly routine holds the gain.

• Monthly load review. Check compute use per database and flag any tier running well under its ceiling.
• Coverage target. Keep reserved capacity coverage above 70 percent of eligible always on compute.
• Creation policy. New databases start small, on serverless or a low vCore count, and scale up on evidence.
• License register. Reconcile Software Assurance cores against Azure assignments each quarter, and again whenever SA renews.
• Expiry calendar. Review each reservation 60 days before it ends so the renewal reflects current sizing.

The wider operating model sits in our Azure cost best practices.

What have we seen in Azure SQL cost reviews in 2024 and 2025?

Across roughly 35 to 45 Azure SQL environments we benchmarked between 2024 and 2025, the same pattern repeated regardless of industry. Teams worked on queries while paying for the wrong tier. The median cost reduction was 30 percent, and most of it came from the tier and the purchasing model.

• Sized for peak. Roughly 3 of 5 databases ran on a tier sized for peak while average CPU sat at 15 to 30 percent.
• Low reservation coverage. Reserved capacity covered below 40 percent of always on databases, leaving the largest single discount unclaimed.
• Unused Hybrid Benefit. The benefit went unused on 30 to 50 percent of eligible SQL compute, usually because the on premises license pool was never reconciled against Azure inventory.

Half the waste sat in the service tier and the other half in Hybrid Benefit not applied. Both are mechanical fixes rather than negotiations. Against an unoptimized starting point, reductions of 25 to 40 percent are realistic, and the largest single gain comes from fixing the tier. The wider context sits in our Microsoft practice.

Which Azure SQL cost mistakes are the most expensive?

The expensive mistakes come from doing things in the wrong order or at the wrong scope. Each one below either locks in waste for a term or leaves a discount you already paid for unclaimed.

Five mistakes we see repeatedly

1. Reserving before right sizing. The reservation fixes the oversized footprint for one or three years. Exchanges help, but refunds are capped at $50,000 of cancelled commitment in a rolling 12 month window.
2. Counting Enterprise cores one for one on General Purpose. Each Enterprise core with SA covers 4 vCores there, so a one to one assignment uses four times the licenses you need.
3. Moving a licensed production database to serverless. Serverless takes neither Hybrid Benefit nor reservations, so the per second saving can be smaller than the discounts you give up on a steady workload.
4. Copying the production tier to test. Test and development copies of a Business Critical database rarely need its local storage and replicas. General Purpose or serverless covers them at a lower rate.
5. Running development Managed Instances all week. A General Purpose instance can stop on a schedule, and while stopped it pays for data and backup storage only, with no vCore or SQL license charge.

What will the Microsoft account team say about Azure SQL spend?

• "Take the three year term for the bigger discount." Reply that you will reserve three years only on compute that survived right sizing and has a three year forecast. The rest goes on one year terms or stays flexible.
• "Hyperscale will be cheaper at your size." Ask for a costed comparison against General Purpose and Business Critical on your measured load, including storage and replicas.
• "Your Hybrid Benefit is already applied." Ask for the license type on each database and instance. Anything still on the license included rate is unclaimed.
• "Grow the Azure commitment to cover SQL growth." Size any commitment on consumption after the tier fix, since a figure built on today's bill commits you to spend you plan to remove. Our MACC negotiation guide covers the sizing, and the EA guide covers how it fits the renewal.

What to do next

1. Inventory every database. Record tier, purchasing model, vCores or DTUs, average and peak CPU from sys.resource_stats, license type and reservation coverage.
2. Move DTU databases to vCore. Size them with the 100 and 125 DTU rules, then correct on measured load, so reservations and Hybrid Benefit become available.
3. Right size and reshape. Cut provisioned tiers on a fortnight of observed data, move intermittent databases to serverless, and pool databases with offset peaks.
4. Map and assign your SQL Server licenses. Reconcile Software Assurance cores against Azure, apply the edition conversion, and release any cores tied to pre 2023 Hyperscale databases before December 2026.
5. Reserve what is proven. Buy reserved capacity only for compute that will run the full term, at shared or management group scope.
6. Set the monthly routine. Load review, the 70 percent coverage target and a creation policy. Our Microsoft practice can run the first pass with you.

Frequently asked questions