Azure SQL Database Pricing Guide UK 2026

DTU vs vCore: The Core Decision

Microsoft still actively supports both DTU and vCore models — which is part of why the decision is confusing. The DTU model was the original SQL Database pricing model. The vCore model launched in 2018 and is now the recommended path for new deployments, particularly if you have an Enterprise Agreement or existing SQL Server licences.

The key difference is what you are buying. A DTU (Database Transaction Unit) is an opaque blended measure of compute, storage, and IO. You cannot separate the components. A Standard S3 database gives you 100 DTUs and 250 GB of included storage. If your workload is IO-heavy, you pay for the full bundle regardless. If you want to scale compute independently of storage, you cannot.

The vCore model prices compute and storage separately. You pick a service tier (General Purpose, Business Critical, or Hyperscale), a vCore count, and a storage allocation. That separation unlocks two significant discounts the DTU model does not offer: Azure Hybrid Benefit and Reserved Instances.

DTU Model: When It Still Makes Sense

The DTU model still makes sense in specific scenarios:

• Small dev/test databases — Basic (5 DTU, ~£4.50/month) is hard to beat for a database that handles dozens of connections per day. There is no vCore equivalent at that price point.
• Existing workloads already sized and stable — If you have been running S2 for two years, the DTU model is predictable. Migration to vCore requires testing and a short downtime window.
• No EA and no SQL Server licences — Without AHB or RI, the vCore model loses its biggest advantage. At smaller sizes (S0–S2), DTU can be cheaper than PAYG vCore.

The DTU model starts to lose ground at S3 (100 DTU) and above. At S4 (200 DTU, ~£273/month), the vCore equivalent with AHB is materially cheaper. Above S6, the gap is significant enough to justify a migration project.

vCore: GP vs Business Critical vs Hyperscale

The vCore model has three service tiers with meaningfully different architectures and price points:

General Purpose is the baseline tier. Compute and storage are separated — compute runs on a single node and storage is backed by Azure Premium Storage. It includes 3 IOPS per GB and supports 1 to 80 vCores. The cost is approximately £0.14/vCore/hour in UK South. Most OLTP databases that are not latency-critical belong here.

Business Critical uses a built-in Always On availability group across three nodes. You get local SSD storage, higher IOPS, and a read-only secondary replica at no extra cost. The cost is approximately £0.29/vCore/hour in UK South — about 4× the GP rate. The secondary replica can serve read workloads, which changes the cost calculation for read-heavy applications: BC at 4 vCores may be cheaper than GP at 8 vCores once you factor in the free read replica.

Hyperscale is for databases above 4 TB or workloads that need rapid horizontal read scale-out. Storage is decoupled from compute using a log-based architecture. It is not cheaper than GP for normal-sized databases — the value is the architecture, not the price.

Provisioned vs Serverless

Serverless compute is available for General Purpose only. It auto-pauses the database after a configurable idle period (minimum 1 hour) and bills per vCore-second while active. The per-vCore rate is higher than Provisioned (approximately £0.49/vCore/hour vs £0.14/vCore/hour), but paused databases incur no compute cost.

The break-even point between Serverless and Provisioned depends on your utilisation pattern. If the database is active less than about 30% of the time, Serverless is cheaper despite the higher rate. If it is active most of the day, Provisioned is cheaper. Dev and test databases that are unused overnight and at weekends are ideal Serverless candidates.

Azure Hybrid Benefit

Azure Hybrid Benefit (AHB) lets you apply existing SQL Server licences with Software Assurance — or active SQL subscription licences — to reduce the compute cost of vCore databases. The saving is substantial: approximately 30% for General Purpose and 50% for Business Critical, because BC pricing includes a proportionally larger licence component.

AHB requires one SQL Server Enterprise Edition core licence per vCore for BC, or one per four vCores for GP (Standard Edition). If you have an EA and are running SQL Server workloads on-premises that are candidates for migration, the licence portability changes the economics significantly. A GP 4-vCore database with AHB costs approximately £75/month in compute instead of £105/month.

AHB cannot be applied to the DTU model. This is the clearest single reason to migrate from DTU to vCore if you have eligible licences.

Reserved Instances vs Savings Plan (March 2026)

Reserved Instances (RI) for SQL Database commit to a specific vCore count and service tier for 1 or 3 years. The 1-year RI saves approximately 33% on compute; the 3-year RI saves approximately 55%. RIs can be combined with AHB — the discounts stack.

In March 2026, Microsoft announced the Savings Plan for Databases — a new commitment option that applies a 35% compute discount for a 1-year commitment, but without requiring you to commit to a specific vCore count or tier. It is more flexible than a 1-year RI (which locks to a specific configuration) but less savings than a 3-year RI.

RI and Savings Plan are mutually exclusive — you pick one. For stable, sized workloads that have been running for more than six months, the 3-year RI is hard to beat at 55%. For workloads still scaling, the Savings Plan's flexibility is worth the slightly lower discount.

Elastic Pool: When It Is Worth It

An Elastic Pool allocates a shared pool of DTUs or vCores across multiple databases. Individual databases can burst to use more of the pool when others are idle. The cost-effectiveness depends on whether your databases have genuinely variable and non-overlapping peak usage.

The break-even analysis is straightforward: if the average utilisation across all databases is consistently below 50%, a pool is likely cheaper than the same databases as dedicated instances. The savings come from not having to provision peak capacity for every database independently.

The risk is the reverse: databases with correlated peaks — for example, a batch process that hits all five databases at the same time every night — will all compete for the same pool resources. In that scenario, dedicated instances are better and an Elastic Pool is actually more expensive because you have to size the pool to handle the combined peak.

DTU → vCore Migration: The Conversion Formula and Gotchas

The DTU-to-vCore conversion formula from Microsoft is: 1 vCore ≈ 100 DTUs for General Purpose. This is a rule of thumb, not a guaranteed equivalence. The DTU model blends compute, storage, and IO; the vCore model separates them. A workload that is storage-IOPS-heavy on Standard DTUs may need fewer or more vCores depending on the read/write pattern.

The migration steps are: (1) run Query Performance Insight on the DTU database to confirm there are no resource bottlenecks that indicate undersizing; (2) use the DTU-to-vCore calculator (or this one) to find the equivalent GP configuration; (3) create a new vCore database with the same schema, import data, and test; (4) cut over during a low-traffic window. There is a brief downtime window during the final connection string switch.

The gotcha most engineers hit: storage sizing. The DTU model includes storage in the tier. General Purpose vCore starts at 5 GB and charges per GB — so if you have a Standard S3 with 250 GB of included storage and only use 10 GB, you save on storage when you migrate. If you use 200 GB, the storage cost on vCore (200 × £0.10 = £20/month) is a new explicit line item that was hidden inside the DTU price.

SQL Database Calculator

Use the calculator below to compare DTU vs vCore costs, model Elastic Pool scenarios, and apply AHB and RI discounts. The DTU → vCore comparison in the results panel shows the equivalent GP configuration alongside the DTU cost.

Built and verified by an independent Azure engineer. Use the SQL Database Calculator → to estimate your costs.