Azure SQL Pricing Explained: DTU vs vCore (2026)

Every Azure SQL Database (and Managed Instance) is billed under one of two purchasing models, and you choose per database — there's no account-wide setting. The DTU-based model (Database Transaction Unit) blends compute, memory, I/O, and a fixed storage allowance into a single number and a single price per tier. It's the older model, dating back to Azure SQL Database's early years, and it still maps cleanly onto how a lot of teams already think about SQL Server sizing.

The vCore-based model prices compute (as virtual cores, with a selectable generation and hardware family) and storage independently, the way most other Azure compute services work. It's the only model with three separate service tiers — General Purpose, Business Critical, and Hyperscale — and the only model eligible for Reserved Capacity, Azure Hybrid Benefit, and serverless auto-scaling (Microsoft Learn: vCore purchasing model, 2026). Microsoft has not signaled any plan to retire the DTU model, but nearly all new platform features — Hyperscale, serverless, zone redundancy, next-gen General Purpose hardware — ship to vCore only.

DTU pricing is a flat monthly (billed hourly) rate per tier, with storage bundled up to a per-tier ceiling and overage billed separately:

Storage beyond the included allowance bills at roughly $0.17/GB-month. Basic tops out at 2 GB total and can't be extended; Standard and Premium can add storage independently of the DTU tier, up to the per-tier maximum. Basic and Standard use remote (Azure Premium Storage) backing; Premium uses local SSD for lower latency, which is most of why Premium costs several multiples more than Standard at a comparable DTU count.

vCore pricing is per-vCore-hour for compute, plus a separate per-GB-month rate for storage. Three service tiers cover different workload shapes:

General Purpose is the default choice for most production workloads: independently scalable compute and storage, remote storage redundancy, and eligibility for every discount lever below. Business Critical exists for workloads where a few milliseconds of write latency or an always-on readable secondary genuinely matters enough to justify nearly tripling the compute bill. Hyperscale exists for databases that are large, growing fast, or need near-instant backups and restores regardless of size — the 4 TB ceiling on General Purpose and DTU tiers simply doesn't apply.

Serverless is a billing option within the General Purpose vCore tier, not a separate service tier. You set a minimum and maximum vCore range and an auto-pause delay; Azure SQL scales compute within that range automatically and, after the configured period of inactivity, pauses the database entirely:

• Active compute bills per-second at roughly $0.52/vCore-hour (Gen5 General Purpose serverless rate) — a premium over the equivalent provisioned rate in exchange for not having to size compute ahead of time
• While paused, compute charges drop to $0 — you pay nothing until the next connection resumes the database, typically within a few seconds
• Storage keeps billing during a pause at the normal per-GB rate — serverless never stops charging for data at rest
• Auto-pause delay is configurable from 1 hour up to 7 days (or disabled entirely for a database that should never pause)

Serverless is a strong fit for dev/test databases, internal tools with bursty and unpredictable access patterns, and any database that's genuinely idle for large stretches of the day. It's a poor fit for anything with steady, near-continuous traffic — the per-vCore-hour premium over provisioned compute adds up fast once auto-pause never actually triggers, and cold-start latency after a pause is a real consideration for anything latency-sensitive.

Both models support elastic pools: instead of provisioning DTUs or vCores per database, you provision one pool and every database inside it shares that capacity. Pools bill for the pool's total DTU/vCore size regardless of how many databases sit inside it (up to a per-tier database count limit), which makes them a direct fit for the classic multi-tenant pattern — many databases that each spike unpredictably but rarely peak at the same moment.

A pool sized for the aggregate peak of, say, 50 small tenant databases almost always costs less than provisioning each database individually for its own worst case, because individual peaks rarely align. The tradeoff is that a genuinely correlated spike across many tenants at once — a batch job that runs against every database simultaneously, for example — can exhaust pool capacity in a way that per-database provisioning wouldn't.

Two discount mechanisms apply on top of vCore pricing — neither is available to DTU-based databases:

• Reserved Capacity commits to a vCore quantity, region, and service tier for 1 or 3 years in exchange for a discounted compute rate. Microsoft's own documentation is explicit that DTU-based (Basic, Standard, Premium) databases cannot be reserved at all — reservations only apply to General Purpose, Business Critical, and Hyperscale vCore compute (Microsoft Learn: Save on compute costs with Azure Reservations, 2026).
• Third-party pricing analyses commonly report Reserved Capacity discounts in the range of roughly 30–40% for a 1-year term and 50% or more for a 3-year term on General Purpose compute, though the exact percentage varies by tier, hardware generation, and region — Microsoft does not publish a single flat discount figure.
• Reservations cover compute only — storage, backup, and networking still bill at standard rates — and they don't auto-renew or transfer between subscriptions without an exchange.
• Azure Hybrid Benefit lets customers with Software Assurance-covered SQL Server licenses apply those licenses to Azure SQL Database or Managed Instance instead of paying the License-Included compute rate. Microsoft states this saves “up to 30 percent or more” versus pay-as-you-go, and that combining Azure Hybrid Benefit with Reserved Capacity can push total savings considerably higher (Microsoft Learn: Azure Hybrid Benefit for Azure SQL, 2026).

Neither discount is worth committing to on a database whose size is still changing. vCore size flexibility lets a reservation follow you up or down within the same tier and region without losing the discount, but a reservation bought against next quarter's guessed capacity, on a workload that's still being right-sized, routinely locks in more than you end up needing.

Small production app, steady light load: A Standard S3 database (100 DTU, 250 GB included storage) runs approximately $147/month, all-in, with no separate storage or I/O line items to track. This isn't directly comparable to a specific vCore size — Microsoft doesn't publish an exact DTU-to-vCore conversion — but as a rough guide, Microsoft's own sizing guidance places 100 DTU well below a 4-vCore General Purpose database in raw throughput. The point isn't that one number is directly cheaper than the other; it's that the DTU model gives you a single dial to turn, while vCore gives you two.

Mid-size production database on General Purpose: A 4-vCore Gen5 General Purpose database runs roughly 4 × $0.252 × 730 hrs ≈ $736/month in compute, plus storage at roughly $0.115–$0.25/GB-month — 100 GB adds another $12–$25/month. A 1-year Reserved Capacity commitment at a representative ~35% discount brings the compute portion down to roughly ~$478/month before amortizing any upfront fee; adding Azure Hybrid Benefit on top (for a Software Assurance customer, at Microsoft's stated “up to 30% or more”) can push the effective compute cost meaningfully lower still, though the exact combined figure depends on your specific licensing and term.

Dev/test database, idle most of the day: A serverless General Purpose database configured for 1–4 vCore auto-scaling, active roughly 4 hours/day and auto-paused the rest, bills approximately 4 hrs × 30 days × 2 avg vCore × $0.52 ≈ $125/month in compute, versus 4 × $0.252 × 730 ≈ $736/month for the same 4-vCore ceiling provisioned around the clock — roughly a 6x difference for a workload that genuinely sits idle most of the time. Storage bills the same either way.

Latency-sensitive OLTP on Business Critical: The same 4-vCore configuration on Business Critical runs roughly 4 × $0.679 × 730 ≈ $1,983/month in compute — about 2.7x the General Purpose figure — before storage, which is also priced higher per GB on Business Critical's local SSD. That premium buys three additional high-availability replicas and materially lower write latency; it's not a cost worth paying for a workload that doesn't need either.

• Staying on Premium DTU out of inertia. Premium's local-SSD pricing is a large multiple of Standard, and workloads that migrated to Premium years ago for I/O headroom often fit comfortably (and far more cheaply) on vCore General Purpose today.
• Trying to reserve a DTU-based database. Reservations only apply to vCore compute — a team that wants Reserved Capacity discounts has to migrate to the vCore model first, which also unlocks Business Critical, Hyperscale, and Hybrid Benefit.
• Provisioning General Purpose 24/7 for a database that's idle most of the time. The serverless example above shows roughly a 6x difference for a database active only a few hours a day — provisioned compute bills the same whether or not anything is querying it.
• Choosing Business Critical “to be safe” without a latency requirement that needs it. At roughly 2.7x General Purpose compute, Business Critical is expensive insurance for a workload that would run fine on General Purpose's standard HA.
• Sizing many small, spiky databases individually instead of pooling them. Elastic pools bill for shared capacity once, not per database — the classic multi-tenant pattern is usually cheaper pooled than provisioned per-tenant.
• Forgetting storage and backup are separate line items on vCore. Unlike DTU's bundled pricing, vCore compute and storage bill independently — a cost estimate built only around the vCore-hour rate misses a real and sometimes significant chunk of the bill.