Azure SQL DTU vs vCore: when each is the wrong choice

Azure SQL Database has two pricing models that look interchangeable on the portal selector. They are not. The choice locks in or unlocks the two discounts that move the bill the most. Most teams who started before 2018 are still on the wrong one.

What DTU actually bundles

A DTU is a blended unit of compute, memory, and IO. The portal sells it as simplicity. In practice it means the rate card hides which resource you are paying for, and the discount surface is gone. DTU databases cannot use Azure Hybrid Benefit and cannot use Reserved Capacity.

That is the entire trade. You picked the simpler unit, you cannot apply the two discounts that take 60 to 70 percent off the bill on any production workload that runs longer than a year. A Standard S6 database costs $589 per month, every month, with no discount path. The same workload on vCore General Purpose 4-vCore with AHB and a 3-year Reserved costs roughly $230. About 60 percent off, with no change to the application.

The migration mapping

The mapping from DTU to vCore is roughly linear. Microsoft published guidance bundles the math, but the rule of thumb that holds for most workloads:

• Standard S2 (50 DTU) → GP Gen5, 2 vCore
• Standard S3 (100 DTU) → GP Gen5, 2 vCore
• Standard S4 (200 DTU) → GP Gen5, 4 vCore
• Standard S6 (400 DTU) → GP Gen5, 4 vCore
• Standard S7 (800 DTU) → GP Gen5, 8 vCore
• Premium P1 (125 DTU) → BC Gen5, 2 vCore (IO-bound)
• Premium P2 (250 DTU) → BC Gen5, 4 vCore
• Premium P4 (500 DTU) → BC Gen5, 8 vCore

The Premium tier maps to Business Critical because Premium is IO-optimized and BC is the vCore tier with local SSD. If your Premium database does not actually need the IO (most do not), GP plus Hyperscale or GP plus a larger vCore count will cost less.

The Azure SQL cost calculator models both sides on the same page so the dollar delta is visible before the migration.

The AHB stack on vCore

Hybrid Benefit on Azure SQL works the same way it works on VMs: the SQL Server license entitlement from your EA carries over to the cloud and removes the licensing component. On vCore the licensing component is roughly half the rate.

GP Gen5 4-vCore License Included is around $0.5063 per vCore per hour. AHB drops it to $0.252 per vCore per hour. That is $1,477 per month versus $735 per month, $8,900 per year saved on a single database. Multiply by however many SaaS-tenant databases you have.

Reserved Capacity stacks. 1-year takes 23 percent off the compute component. 3-year takes 41 percent. Same database, GP 4-vCore with AHB plus 3-year Reserved, lands at roughly $0.149 per vCore per hour. About $435 per month, down from $1,477. 70 percent off pay-as-you-go without touching the application.

When Hyperscale is the right answer

Hyperscale separates compute from storage and prices each one independently. Storage is $0.10 per GB per month with no upper bound, scales to 100 TB. Compute is per primary replica, with optional read-only replicas at the same vCore rate.

The break-even versus General Purpose:

• Below 200 GB: GP plus AHB is cheaper, every time.
• 200 GB to 1 TB: GP and Hyperscale are within 10 percent. Pick GP if storage is stable, Hyperscale if it grows.
• 1 TB to 4 TB: Hyperscale starts to win on storage scaling and read replicas.
• Above 4 TB: Hyperscale is the only option that makes sense. GP caps at 4 TB.

The trap on Hyperscale is small databases. We have audited tenancies with thirty 50 GB Hyperscale databases that should have been GP. The compute rate is similar but the read replicas, even at zero, get priced as a bundle. GP with AHB and 3-year Reserved is roughly half the cost on workloads under 500 GB.

The audit query

This lists every database with its tier and AHB status:

az sql db list \
  --resource-group prod-rg \
  --server my-sqlsrv \
  --query "[].{name:name, tier:currentServiceObjectiveName, ahb:licenseType, size_gb:maxSizeBytes}" \
  --output table

az sql db list-editions \
  --location eastus \
  --query "[?name=='GeneralPurpose'].supportedServiceLevelObjectives[].{name:name, vcore:sku.capacity}" \
  --output table

The columns to read: any database where tier starts with S or P is on DTU. Any vCore database where ahb is LicenseIncluded is paying for SQL licensing your EA already covers. Both are migration candidates.

The DTU-to-vCore migration runs online with no downtime:

# Identify DTU databases on the server
az sql db list -g prod-rg -s my-sqlsrv \
  --query "[?contains(currentServiceObjectiveName, 'S') || contains(currentServiceObjectiveName, 'P')]"

# Migrate to vCore General Purpose 4-vCore with AHB
az sql db update \
  --resource-group prod-rg \
  --server my-sqlsrv \
  --name my-db \
  --edition GeneralPurpose \
  --family Gen5 \
  --capacity 4 \
  --license-type BasePrice

Azure migrates the database to the new tier in place. Connection strings stay the same. Replication catches up, then a brief failover. Most production databases see less than five seconds of write unavailability. The Premium-to-Business-Critical equivalent is similarly transparent.

Why teams stay on DTU

The pattern is consistent across the audits we run:

• The original Bicep or ARM template was written before vCore existed for Single Database. Nobody updated the module.
• The DBA team is not on cloud cost call rotation. They never see the SKU on the bill.
• Someone tried Hyperscale on a small database, did not see savings, and concluded vCore is not worth migrating to. They did not see GP with AHB.
• The procurement team owns SA, the cloud team owns Azure. Same friction as VM Hybrid Benefit.

AHB and the vCore migration are usually the two largest line items on an Azure SQL audit. Run the query this week, check the calculator against the largest DTU database in your tenant, and pitch the change with the dollar delta in the title.

The companion piece on Azure Hybrid Benefit covers the eligibility rules and per-tenant license cap that apply equally to VM and SQL workloads.