Azure SQL Database Pricing: DTU vs vCore vs Serverless — What Each Model Costs and How to Reduce It

Azure SQL Database pricing is genuinely confusing. Not because any one piece of it is complicated, but because the service offers three different billing models that operate on entirely different units, offer different discount mechanisms, and require different optimization strategies. A FinOps engineer trying to normalize costs across a database estate that includes both DTU-model legacy applications and vCore-model modern services is essentially running two parallel pricing frameworks simultaneously.

This guide covers how each pricing model works, what each tier costs in practice, the optimization levers available per model, and the decisions that determine whether you can access Hybrid Benefit, reserved capacity, or Savings Plan discounts. It also covers two time-sensitive facts that most guides miss: the Azure Hybrid Benefit exception for Hyperscale databases, and the Fsv2 hardware retirement on October 1, 2026.

The DTU Purchasing Model: Simple, Predictable, and Missing Key Discounts

A Database Transaction Unit (DTU) represents a blended measure of CPU, memory, reads, and writes bundled into fixed tiers. Source: learn.microsoft.com/azure/azure-sql/database/service-tiers-dtu DIRECT QUOTE. You choose a tier and a DTU count, and Azure SQL bills you a fixed hourly rate for that allocation regardless of actual workload.

DTU service tiers are Basic, Standard, and Premium. Basic is designed for development and small applications. Standard covers a wide range of workloads with moderate performance requirements. Premium is designed for OLTP workloads with high transaction rates and low I/O latency requirements.

The appeal of the DTU model is predictability. You pick a tier, you know the monthly bill, there are no separate storage scaling decisions or vCore configuration choices. For small, stable workloads with simple billing requirements, DTU can be appropriate.

What DTU cannot do

The DTU model does not support Azure Hybrid Benefit for SQL Server. You cannot apply existing SQL Server licenses with Software Assurance to reduce compute costs on DTU-model databases.

The DTU model does not support reserved capacity. Azure SQL Database reserved capacity is only available in the vCore purchasing model.

The DTU model also does not offer the Serverless compute tier, Hyperscale service tier, or the ability to separately scale compute and storage. If you want any of these capabilities, you need the vCore model.

Microsoft recommends the vCore model for new deployments. The DTU-to-vCore migration is an online operation — you do not need to take the application offline. The migration can be performed via the Azure portal, PowerShell, Azure CLI, T-SQL, or the REST API.

The vCore Purchasing Model: Two Compute Tiers, Full Discount Access

The vCore model separates compute (virtual cores) from storage and lets you choose each independently. The vCore model offers four service tiers: General Purpose, Business Critical, Hyperscale, and the new Hyperscale Serverless. It also offers two compute tiers: provisioned and serverless. The combination of service tier and compute tier determines the pricing and available capabilities.

Provisioned compute tier: hourly billing for reserved capacity

In the provisioned compute tier, compute cost reflects the total compute capacity continuously provisioned for the application independent of workload activity.

Azure SQL Database (except for serverless) is billed on a predictable hourly rate. If the SQL database is active for less than one hour, you are billed for the highest service tier selected, provisioned storage, and IO that applied during that hour, regardless of usage or whether the database was active for less than an hour.

This hourly minimum billing behavior has an important implication: if you create and delete a database in under an hour, you are charged for the full hour. This matters for development workflows that spin up and tear down databases frequently.

Also read: Azure Hybrid Benefit: The Complete Guide to Stacking License Discounts with Reservations and Savings Plans

Service tier pricing differences

General Purpose is the standard tier for most workloads, with compute and storage on a separation architecture. It uses Azure Blob storage for database files, providing high availability and durability.

Business Critical is designed for OLTP workloads requiring high transaction rates, low latency I/O, and strong resilience. Because three additional replicas are automatically allocated in the Business Critical service tier, the price is approximately 2.7 times higher than in the General Purpose service tier for the same vCore count. Source: learn.microsoft.com/azure/azure-sql/database/purchasing-models DIRECT QUOTE. The 2.7x cost is not padding — it reflects the actual infrastructure cost of four nodes (one primary plus three replicas) running simultaneously.

Hyperscale is designed for databases that need to grow beyond the 4 TB General Purpose storage limit, with rapid scale-out and high read throughput via read replicas. Hyperscale storage scales automatically up to 100 TB. Pricing includes compute plus a per-TB storage charge.

Azure Hybrid Benefit for SQL Database: The Critical Exception

Azure Hybrid Benefit for SQL Server lets you apply existing SQL Server licenses with Software Assurance to reduce the software license component of the hourly vCore rate. The licensing math: one SQL Server Enterprise core license converts to 4 vCores in Azure SQL Database General Purpose or Hyperscale tier. Standard edition maps 1:1. Get the ratio wrong and you either under-provision or over-allocate licenses. Source: Azure Hybrid Benefit documentation for SQL Server.

Stacking Azure Hybrid Benefit with SQL Database reserved capacity can push total discounts well past 80% versus pay-as-you-go for organizations with existing SQL Server Software Assurance. Azure Hybrid Benefit removes the software license cost, reserved capacity then discounts the compute-only rate.

The Hyperscale exception: read carefully before purchasing

Azure Hybrid Benefit is not available for new Hyperscale databases as of December 2023. Existing Hyperscale single databases with provisioned compute can continue to use Azure Hybrid Benefit to save on compute costs until December 2026. Source: learn.microsoft.com/azure/azure-sql/database/service-tiers-sql-database-vcore DIRECT QUOTE.

This is a material constraint for teams planning new Hyperscale deployments. If your Azure SQL cost model assumed Hybrid Benefit savings on a new Hyperscale database, that assumption is incorrect. Budget Hyperscale at the full vCore rate without Hybrid Benefit for any new deployment after December 2023.

For existing Hyperscale databases currently using Hybrid Benefit: note the December 2026 sunset. When that date passes, compute billing switches to the full rate. If your Hyperscale databases represent significant spend, factor the post-December 2026 rate increase into your budget and reservation/savings plan planning.

The Serverless Compute Tier: Per-Second Billing and the Auto-Pause Trap

How serverless billing works

In the serverless compute tier, compute resources are autoscaled based on workload capacity and billed for the amount of compute used, per second.

The cost for a serverless database is the summation of the compute cost and storage cost. When compute usage is between the minimum and maximum limits, compute cost is based on vCores and memory used. When compute usage is below the minimum limits configured, compute cost is based on the minimum vCores and minimum memory configured. Source: learn.microsoft.com/azure/azure-sql/database/serverless-tier-overview DIRECT QUOTE.

The per-second billing rate published on the Azure pricing page: $0.0001450 per vCore-second, which works out to $0.5218 per vCore-hour. Verify current rates at azure.microsoft.com/pricing/details/azure-sql-database/. For a database configured at 1 vCore minimum and 4 vCore maximum, the minimum compute charge when active is $0.0001450 per second at 1 vCore — approximately $0.5218 per hour at minimum. This rate is higher than the provisioned compute rate for the same vCore count; the per-second billing flexibility carries a rate premium.

Auto-pause: what stops compute billing

The auto-pause feature is what stops compute charges. After a configurable period of inactivity (the auto-pause delay), the database pauses and you pay only for storage. The database automatically resumes when the next login or activity occurs, introducing a brief cold-start delay. Source: learn.microsoft.com/azure/azure-sql/database/serverless-tier-overview DIRECT.

The catch that consistently surprises teams: auto-pause requires no active connections AND no workload. In Azure SQL Database serverless, you are billed for compute per second whenever the database is in the active state, regardless of whether queries are actually running. Billing is based on the number of vCores being used at that moment, but it will never go below the minimum vCore value you configure. If users are connected via SQL Server Management Studio (including just having the Object Explorer open and not executing queries), those open connections keep the database active and prevent auto-pause.

The operational implication: if your serverless database is meant to pause during off-hours but team members habitually leave SSMS connections open, the database never pauses and you pay the minimum vCore rate continuously. Set a short auto-pause delay (the default is 60 minutes for the free offer), encourage users to disconnect when done, and monitor the auto-pause metrics in Azure Monitor to verify pausing is actually occurring.

When serverless makes sense versus provisioned

Serverless is appropriate for databases with intermittent, unpredictable usage — development databases, lightly used internal tools, batch jobs that run a few times per day and otherwise sit idle, reporting databases queried occasionally. If a database can reliably pause for significant portions of the day (several hours or more), serverless typically costs less than provisioned for the same maximum vCore capacity.

Serverless is not the right choice for continuously active production databases. If your database processes queries around the clock with minimal idle time, it will never auto-pause and the serverless per-vCore-second rate is higher than the provisioned per-vCore-hour rate for equivalent capacity. Continuously active databases should use the provisioned compute tier with reserved capacity to maximize savings. Currently, serverless is also only supported on Standard-series (Gen5) hardware.

Commitment discounts on serverless: the new Database Savings Plans

For a long time, serverless SQL had no commitment-based discount option. Reserved capacity does not apply to serverless databases. This changed with Azure Database Savings Plans. Azure Database Savings Plans cover Azure SQL Database serverless compute among other database services, with up to 35% savings at a 1-year commitment. Source: Azure Database Savings Plans documentation, 2026.

This is significant because serverless workloads previously had no way to reduce costs beyond the auto-pause behavior itself. Azure Database Savings Plans now provide a commitment layer for flexible and serverless database patterns. The plan covers spend across multiple database services — if you migrate from one covered service to another (for example from SQL Database provisioned to SQL Database serverless), the commitment continues covering the new service rather than stranding. Source: Azure Database Savings Plans documentation.

The hardware retirement you need to know about: Fsv2-series hardware for Azure SQL Database is no longer available to be created and will be retired October 1, 2026. Microsoft recommends transitioning to Hyperscale premium-series or Standard-series (Gen5) hardware. Source: learn.microsoft.com/azure/azure-sql/database/service-tiers-sql-database-vcore DIRECT QUOTE. If any of your Azure SQL databases run on Fsv2-series hardware, plan the migration now. Waiting until October creates a forced migration window that may coincide with other infrastructure changes.

Backup Storage Costs: The Line Item Most Teams Discover on Their First Bill

For single databases in the vCore model, backup storage is always charged per database, regardless of whether the database is in an elastic pool. Source: learn.microsoft.com/azure/azure-sql/database/purchasing-models DIRECT QUOTE. The backup storage charge covers automated backups (full, differential, and transaction log) retained according to your configured backup retention period.

The DTU model includes an initial allocation of backup storage at no additional charge. The vCore model bills backup storage separately from compute and data storage. For databases with long backup retention periods (up to 35 days for standard automated backups, or up to 7 years with long-term retention), the backup storage charge can be significant for large databases.

A point that creates unexpected bills: if you shrink a database (reducing actual data size) but your backup storage size stays high, your backup bill may not decrease proportionally. Backup storage reflects the amount of data in backup files, which includes historical change data. Heavy DML workloads (high INSERT/UPDATE/DELETE rates) generate larger differential and log backups than the static data size suggests.

Elastic Pools: When Multiple Databases Share Resources

Azure SQL Database elastic pools let you allocate a shared pool of compute resources (DTUs or vCores) that multiple databases draw from simultaneously. Elastic pools are appropriate when you have multiple databases with variable, uncorrelated peak usage patterns — if database A spikes in the morning and database B spikes in the afternoon, a shared pool can be sized smaller than the sum of their individual peak requirements.

For elastic pools in the vCore model, compute resources, I/O, and data and log storage are charged per pool. However, backup storage is always charged per database. Source: learn.microsoft.com/azure/azure-sql/database/purchasing-models DIRECT QUOTE. This means you still see per-database backup charges even for databases inside an elastic pool.

Elastic pools support Azure Hybrid Benefit and reserved capacity in the vCore model — the same discount mechanisms available for individual vCore databases apply to pool compute resources. For organizations running many small databases on similar workloads (SaaS applications with per-tenant databases, for example), elastic pools combined with vCore reserved capacity is a common cost-efficient pattern.

Also read: Azure Reserved Capacity: SQL, Cosmos DB, Blob Storage, and Synapse — What each Reservation Covers

The Discount Stack: How Each Model Accesses Discounts

The practical summary of which discount mechanisms are available to each pricing model:

• DTU model: fixed hourly billing only. No Hybrid Benefit. No reserved capacity. No Serverless. No Database Savings Plans.
• vCore provisioned model: Azure Hybrid Benefit (except new Hyperscale from December 2023). Reserved capacity for 1-year or 3-year terms (compute cost only, not storage or networking). Combined discounts can reach 80%+ when stacking Hybrid Benefit with reservations.
• vCore serverless model: Azure Database Savings Plans (1-year, up to 35% savings). No reserved capacity. Auto-pause for zero compute cost during idle. Azure Hybrid Benefit does not apply to serverless compute.

The right combination for most production Azure SQL environments: vCore provisioned for always-on databases (with Hybrid Benefit and reserved capacity where eligible), and vCore serverless for development, testing, and infrequently used databases where auto-pause can take effect regularly.

How Usage.ai Fits Into Azure SQL Database Cost Management

Usage.ai handles the commitment layer for Azure SQL Database: identifying which databases are candidates for reserved capacity versus Azure Database Savings Plans, sizing reservations to the stable vCore floor, purchasing commitments automatically, and monitoring utilization.

For FinOps teams managing mixed Azure SQL environments with a combination of DTU, vCore provisioned, and serverless databases, Usage.ai surfaces the recommendation to migrate eligible DTU databases to vCore to unlock Hybrid Benefit and reserved capacity — quantifying the exact monthly savings from that migration decision before it is made.

The buyback guarantee covers Azure SQL reserved capacity. If a production database is decommissioned, scaled down significantly, or migrated to a different service during a reserved capacity term, the unused portion returns as cashback in real money rather than sunk cost. For organizations with dynamic database estates where databases come and go with product lifecycles, this downside protection enables accurate commitment sizing rather than conservative under-commitment.

$91M+ in savings delivered to 300+ customers across AWS, Azure, and GCP. Fee is a percentage of realized savings only. No savings, no fee. 30-minute setup, billing-layer access only.

Frequently Asked Questions

1. What is the difference between DTU and vCore pricing in Azure SQL Database?

DTU (Database Transaction Unit) is a blended measure of CPU, memory, reads, and writes bundled into fixed tiers (Basic, Standard, Premium). It provides predictable hourly billing but does not support Azure Hybrid Benefit or reserved capacity discounts. The vCore model separates compute, memory, and storage into independently scalable components, supports both Azure Hybrid Benefit and reserved capacity, and offers the Serverless compute tier. Microsoft recommends vCore for new deployments. Source: learn.microsoft.com/azure/azure-sql/database/purchasing-models.

 

2. When should I use Azure SQL Database serverless?

Serverless is appropriate for databases with intermittent, unpredictable usage that can go genuinely idle for extended periods: development databases, lightly used internal tools, infrequent reporting databases. When the database is inactive (no connections, no activity) for the configured auto-pause delay, it pauses and compute billing drops to zero — only storage charges continue. Serverless is not appropriate for always-on production databases since the per-vCore-second rate is higher than provisioned, and a database that never pauses costs more on serverless than provisioned.

 

3. Can I use Azure Hybrid Benefit with Azure SQL Database Hyperscale?

Not for new Hyperscale databases created after December 2023. Azure Hybrid Benefit is not available for new Hyperscale databases as of December 2023. Existing Hyperscale single databases with provisioned compute can continue using Azure Hybrid Benefit until December 2026. After that date, they revert to the full compute rate. Source: learn.microsoft.com/azure/azure-sql/database/service-tiers-sql-database-vcore DIRECT.

 

4. Why is the Business Critical tier approximately 2.7x the price of General Purpose?

The Business Critical service tier automatically provisions three additional replicas alongside the primary, creating four nodes total that run simultaneously for high availability, in-memory OLTP support, and low-latency read replicas. The price reflects running four copies of the infrastructure rather than one. Source: learn.microsoft.com/azure/azure-sql/database/purchasing-models DIRECT QUOTE: ‘the price is approximately 2.7 times higher than in the General Purpose service tier.’

 

5. What is Azure Database Savings Plans and how does it apply to SQL Database?

Azure Database Savings Plans are a 1-year hourly spend commitment covering Azure SQL Database serverless, Azure SQL Managed Instance, Azure Database for PostgreSQL, Azure Database for MySQL, and other database services. They deliver up to 35% savings on serverless SQL Database compute — the first commitment-based discount ever available for serverless workloads. Unlike reserved capacity, a Database Savings Plan covers spend across multiple eligible database services, so the commitment continues if workloads migrate between covered services. Source: Azure Database Savings Plans documentation, 2026.