Azure SQL gives you three ways to pay for compute: provisioned vCore, serverless, and elastic pools. We see organisations pick the wrong model all the time, and the cost difference can be thousands per year per database.
Provisioned: The Safe Default That Bleeds Money
You pick a number of vCores, you get that compute 24/7. Simple, predictable, and you pay whether CPU is at 100% or flatlined at zero.
We regularly see databases provisioned with 8 vCores averaging below 10% utilisation. Someone picked 8 "just in case" during deployment and nobody revisited. At General Purpose pricing, that's roughly £190/month in unused capacity per database. Multiply across a handful of databases and it's a meaningful line item nobody questions.
When it's right: Consistent, predictable workloads at 40-60% CPU with known peak periods. Pair with reserved capacity and Hybrid Benefit for the best economics.
Serverless: Brilliant in Theory, Full of Gotchas
Auto-scales between min and max vCores. Pauses when idle, you only pay for storage. Sounds perfect. But:
Auto-pause isn't instant. Minimum one-hour delay before pausing. If your workload has frequent short idle gaps, you might never actually pause, and the per-second rate is higher than provisioned.
Cold start hurts. Resume takes 1-2 minutes. Connections fail during that time. We've seen teams deploy to serverless, get paged at 3am because the health check timed out on resume, and switch back to provisioned the next morning.
Minimum vCores still cost money. Even scaled down, you pay for the floor. If the database is active most of the time at low utilisation, you could pay more than right-sized provisioned.
When it's right: Dev/test databases idle evenings and weekends (save ~75%). Reporting databases active a few hours daily. Internal tools with spiky usage and users who tolerate a brief cold start. The rule: genuinely idle 50%+ of the time and app handles the cold start.
Elastic Pools: Shared Compute, Shared Risk
Multiple databases sharing a provisioned set of vCores. Compelling economics when databases have staggered peaks.
The key insight most teams miss: you're provisioning for the pool, not individual databases. If one database spikes, every other database gets starved.
Sizing mistake 1: Sizing for the sum of all peaks. If peaks don't overlap, you've massively over-provisioned.
Sizing mistake 2: Sizing for the average. When peaks do overlap (month-end), every database fights for scraps.
When it's right: 4+ databases with non-overlapping peaks, individually too small for dedicated compute. Poor fit when all databases peak simultaneously or one database dominates the pool.
DTU vs vCore
DTU bundles compute, memory, and IO into a single opaque unit. For new workloads, use vCore. It's transparent, compatible with Hybrid Benefit and reserved capacity, and maps to a mental model engineers understand. If you have existing DTU databases, evaluate a move to vCore, often cheaper once Hybrid Benefit is factored in.
The Restore Gotcha
This one catches people out regularly: a developer restores a database from backup for testing or debugging. Azure restores it using the same pricing tier as the source. If the production database is on 8 vCores provisioned, the restored copy is on 8 vCores provisioned. Every restored copy is a separate billable instance.
We've seen environments where developers restored multiple copies over a few weeks and forgot to clean them up. Each copy running on provisioned vCore, each billing the same as production. The bill for "test" databases exceeded the production database cost.
The fix: always restore to serverless or the lowest DTU tier for testing purposes. Restore, change the tier immediately, do your work, delete when done. Don't let restored databases sit on production-tier compute.
The Migration Gotcha
Switching between models causes a brief connectivity drop. Connections are dropped and need re-establishing. Plan changes during a maintenance window, test in non-production first. Do not switch a production database to serverless on a Friday afternoon.
The Pattern
The right pricing model isn't set-and-forget. Workload patterns change, new features deploy, and what was right six months ago might be costing significantly more today. Treat database pricing as a living decision.
Not sure which Azure SQL pricing model fits your workloads? Request a FinOps assessment. We identify exactly where you're overspending.