Azure SQL Purchasing Models: DTU vs vCore
Azure SQL Database has two purchasing models and a compute tier that cuts across one of them, and the choice between them affects cost more than almost any other setting. The short version: DTU is simpler and always-on, vCore is granular and discountable, and serverless bills for what you actually use. The longer version is about which of those properties your workload can exploit.
DTU: the bundled option
A Database Transaction Unit is a composite measure of compute, storage, and I/O. You don't choose CPU or memory — Microsoft defines the number such that 100 DTU is roughly twice the machine 50 DTU is. It's the easy, preconfigured purchase option, with three tiers: Basic, Standard, and Premium.
What it gives up:
- It isn't available for Azure SQL Managed Instance at all — Managed Instance is vCore only.
- It doesn't support Azure Hybrid Benefit or License Mobility through Software Assurance.
- It offers no detailed visibility or control over resource consumption. You get a number, not a machine.
And the property that decides most cost questions:
DTUs are always provisioned and billed regardless of actual usage. For an application used once a month, that's a full month of billing for a few hours of work.
That single fact rules DTU out for intermittent workloads, and it's the reason serverless exists.
vCore: the granular option
A vCore is a virtual core. You choose how many, which gives direct control over compute cost, and you select compute and storage resources independently. In exchange you get:
- Higher compute, memory, I/O, and storage limits than DTU offers.
- A choice of hardware configuration, so compute and memory can be matched to the workload.
- Azure Hybrid Benefit and reserved capacity pricing — the two levers that meaningfully reduce the bill.
- Greater transparency in hardware details, which makes planning a migration from on-premises far easier, because you can reason about the target the same way you reason about the source.
- Finer scaling granularity, with more compute sizes available.
Three service tiers sit inside the vCore model — General Purpose, Business Critical, and Hyperscale — and because they differ on availability architecture as much as performance, they're covered in the post on Azure SQL high availability.
One caveat on Azure Hybrid Benefit
Azure Hybrid Benefit is one of vCore's main advantages, but it doesn't apply everywhere. It isn't available for new Hyperscale databases as of December 2023, because Hyperscale carries no SQL software licence fee for the benefit to offset. Existing Hyperscale single databases with provisioned compute can keep using it to save on compute costs until December 2026, per Microsoft's documentation as of November 2026. That date is close, so check whether it has moved before relying on it.
Serverless compute
Serverless is a compute tier for single databases within the vCore model, and it changes the billing question entirely.
Provisioned compute reflects capacity continuously allocated to the application, independent of workload activity, billed at a fixed hourly price. It never scales down to stopping the database.
Serverless compute autoscales based on workload activity and bills per second for the compute actually used. It supports automatic pausing and resuming based on activity — so an idle database costs nothing in compute.
The constraints:
- Serverless is supported only on Standard-series (Gen5) hardware.
- It autoscales up to 80 vCores.
- The memory-to-vCore ratio adapts dynamically to demand and can reach 24 GB per vCore, so a workload might use and be billed for 240 GB of memory against only 10 vCores.
For an application with genuine idle periods — the once-a-month reporting database, the development environment nobody touches at weekends — serverless is the answer to the problem DTU's always-on billing creates.
Storage and backup billing
Compute is only part of the bill, and the storage side works differently by tier.
For General Purpose and Business Critical, each compute size supports a configurable maximum data size, defaulting to 32 GB, and configuring it adds an extra 30% of billable storage automatically for the log file. You're charged for the maximum storage size configured, not the amount used, and you can select any size between 1 GB and the tier maximum in 1 GB increments.
For Hyperscale, the model inverts: maximum data storage is fixed at 128 TB and isn't configurable, you're charged only for allocated storage rather than the maximum with a 10 GB minimum, and you aren't charged for log storage at all.
tempdb uses local SSD storage in both cases, with its cost included in the vCore price.
Backup storage is billed separately from data and log storage:
- Point-in-time restore retention is configurable from 1 to 35 days, defaulting to 7. A backup storage amount equal to the configured maximum data size is provided at no extra charge.
- Long-term retention covers full backups for up to 10 years, with separate retention periods selectable for weekly, monthly, and yearly backups.
Backup storage itself can be locally redundant, zone-redundant, or geo-redundant — your choice across all three service tiers.
Elastic pools
An elastic pool buys a set of compute and storage resources shared by all databases in it, available under both purchasing models. Each database uses what it needs within the limits you set. It suits many databases with varying, uncorrelated load — where allocating enough capacity for each database's peak individually would mean paying for capacity that's idle most of the time.
The property to design around: autoscaling operates at pool level, not per database. Scaling decisions are made collectively for the whole pool.
Choosing
- Intermittent or unpredictable workload with real idle periods? Serverless, in the vCore model.
- Steady, predictable workload where you want the simplest possible pricing? DTU is defensible, and Basic or Standard covers a lot of small applications.
- Anything where you own SQL Server licences, want reserved capacity, or need to plan against on-premises hardware? vCore, for the Hybrid Benefit and the transparency.
- Managed Instance? vCore — there's no other option.
- Many small databases with uncorrelated load? An elastic pool, under either model.