Skip to content
- Azure SQL Database Pricing: DTU, vCore, Serverless, and the Hidden Backup Cost
Azure SQL Database Pricing: DTU, vCore, Serverless, and the Hidden Backup Cost
Azure SQL Database gives you three ways to pay for the same service — and that's where the trouble starts. The DTU model bundles compute and storage into a single number. The vCore model lets you pick CPU, memory, and storage independently. Serverless bills by the second based on actual usage. Each model uses different units, different scaling logic, and different backup billing — which means your FinOps team is essentially running three parallel cost models for one database service.
In customer conversations, we consistently hear the same frustration: teams can't accurately allocate Azure SQL costs back to the business units that generate them.
This guide breaks down each pricing model with current numbers and shows you how to build a showback model that actually works across all three.
What Are the Microsoft Azure SQL Database Pricing Models?
Azure SQL Database offers two purchasing models — DTU-based and vCore-based — with the vCore model further split into provisioned and serverless compute tiers. Here's the quick version:
- DTU (Database Transaction Unit): A blended measure of CPU, memory, reads, and writes bundled into fixed tiers. You pick a tier, you get a predictable monthly bill. Simple, but opaque — you can't see how much CPU vs. memory you're actually consuming.
- vCore (Provisioned): You choose the exact number of virtual cores and the service tier independently. You're billed per hour for the capacity you've allocated, whether you use it or not. More transparent, more control, more room to over-provision.
- vCore (Serverless): Same vCore architecture, but compute scales automatically between a minimum and maximum you set. Billing is per-second at $0.0001450 per vCore-second ($0.5218/vCore-hour). The database can auto-pause during idle periods, dropping compute cost to zero — though storage charges continue.
Microsoft recommends the vCore model for new deployments, and they've published a migration guide for teams moving from DTU. But plenty of organizations still run both models in parallel, which is exactly where showback complexity explodes.
DTU Pricing: The Bundled Approach
The DTU model groups everything into three service tiers with fixed price points. It's the older model, and Microsoft hasn't added new features to it in years — but it's still widely used because the pricing is dead simple.
Here are the current rates for single databases (East US, pay-as-you-go):
| Tier | DTUs | Included Storage | Price |
|---|---|---|---|
| Basic | 5 | 2 GB | ~$4.90/month |
| Standard S0 | 10 | 250 GB | ~$14.72/month |
| Standard S3 | 100 | 250 GB | ~$147.00/month |
| Standard S6 | 400 | 250 GB | ~$588.00/month |
| Premium P1 | 125 | 500 GB | ~$456.25/month |
| Premium P4 | 500 | 500 GB | ~$1,825.00/month |
Note: DTU pricing includes PITR backup storage at no additional charge. This is a significant difference from the vCore model — more on that below.
The upside of DTUs is predictability. You know exactly what you'll pay each month. The downside is that you can't see the underlying resource consumption. A DTU is a composite metric — if your database is CPU-bound but has plenty of memory headroom, you're still paying for the full bundle. And there's no way to scale CPU independently.
For dev/test environments and small applications with predictable workloads, Basic and Standard S0 tiers at $5–$15/month are hard to beat. Though it's important to note that even within DTU, misconfiguring the tier can lead to cost surprises.
vCore Pricing: Granular Control, Granular Bills
The vCore model lets you choose compute and storage independently, with three service tiers that reflect different performance and availability characteristics:
General Purpose — The workhorse tier. Starts at 2 vCores with 10.2 GB memory at $0.5044/vCore-hour for locally redundant storage. A 4-vCore General Purpose database runs approximately $730/month. Zone redundancy bumps that to ~$1,000/month.
Business Critical tier — Built for low-latency, high-availability workloads. The same 2-vCore configuration costs $1.3589/vCore-hour — roughly 2.7x the General Purpose price. You're paying for three additional high-availability replicas running on local SSD storage.
Hyperscale — Designed for databases up to 100 TB. Pricing starts at $0.5653/vCore-hour for 2 vCores, slightly above General Purpose. Azure SQL Database Hyperscale uses storage snapshots instead of traditional backups, which changes the backup cost model entirely. You can configure 0–4 high-availability replicas and pay accordingly.
Here's where it gets interesting for FinOps teams: vCore pricing separates compute from storage, but it also separates backup storage as its own line item. Unlike DTU, where backup is included, vCore databases are charged approximately $0.12/GB/month (LRS) for PITR backup storage beyond what's included. We'll dig into this in the backup section.
The vCore model also supports Azure Hybrid Benefit, which lets you apply existing SQL Server licenses with Software Assurance to reduce compute costs by 30–55%. And reserved capacity (1-year or 3-year commitments) is only available in the vCore model — not DTU.
Serverless Pricing: Pay-Per-Second with a Catch
Serverless sounds like the perfect FinOps model: you set a minimum and maximum vCore range, the database scales automatically, and you're billed by the second for actual compute used. During idle periods, the database pauses entirely and you pay only for storage.
The per-second rate is $0.0001450/vCore-second, which works out to $0.5218/vCore-hour.
But there are catches that frequently surprise teams:
The minimum vCore floor matters. Even when you set the minimum to 0.5 vCores, that's still 2.02 GB of memory allocated. If your database never actually pauses (because queries hit it every few minutes), you're paying the serverless rate continuously, without the option for reserved capacity discounts.
Auto-pause has a delay. By default, the database pauses after one hour of inactivity. The first query after a pause triggers a cold start that can take 30–60 seconds. For production workloads with any kind of health check or monitoring polling, auto-pause effectively never triggers.
One Redditor calculated that the bare minimum cost for Azure SQL vCore Serverless without auto-pause is $233.02/month — which caught several commenters off guard. Another user reported an unexpectedly high ~$30 bill for what they assumed would be a cheap experimental instance. The pricing model is pay-per-second, but "per second" adds up fast when the database stays active.
When serverless actually saves money: Dev/test databases that are only used during business hours. Staging environments that sit idle overnight and on weekends. Low-traffic internal tools where auto-pause can actually trigger. For anything with continuous traffic, provisioned compute with reserved capacity is almost always cheaper.
The Hidden Cost: PITR Backup Storage
Here's the cost that rarely makes it into initial estimates: Point-in-Time Restore (PITR) backup storage.
Azure SQL Database automatically creates full backups weekly, differential backups every 12–24 hours, and transaction log backups approximately every 10 minutes. These backups are stored separately from your database and are retained for 7 days by default (configurable up to 35 days).
The billing works differently depending on your pricing model, and this asymmetry is where costs hide:
DTU model: PITR backup storage is included at no additional charge. You can set retention up to 35 days without extra cost. Long-term retention (LTR) beyond 35 days is a separate charge, but day-to-day PITR is free.
vCore model (provisioned and serverless): You get free backup storage equal to your maximum configured data storage size. Beyond that, you're charged approximately $0.12/GB/month for locally redundant storage (LRS), with higher rates for zone-redundant ($0.18/GB/month) and geo-redundant ($0.24/GB/month) options.
This is where it gets expensive for write-heavy workloads. PITR backup size isn't just your database size — it's the cumulative size of full backups, differential backups, and transaction log backups within your retention window. For databases with high write churn (frequent inserts, updates, deletes), transaction log backups accumulate rapidly. A 50 GB database with heavy write activity can easily generate 200+ GB of backup storage over a 14-day retention window.
The showback problem is even worse. Backup storage billing for Azure SQL Managed Instances is at the instance level, not per-database. So if you're running multiple databases on a Managed Instance, you can see the total backup bill but you can't attribute it to individual databases without pulling metrics from Azure Monitor and doing your own allocation math.
As one practitioner on r/AZURE noted, allocating costs within elastic pools requires pulling DTU or vCore usage per database from Azure Monitor, calculating each database's percentage of total pool consumption, then allocating the pool cost proportionally. It's tedious, and most teams just split it evenly — which means the team with the lightweight reference database subsidizes the team running the write-heavy transactional workload.
Azure SQL Database Pricing Comparison
Here's a side-by-side view to help you evaluate which model fits your workload:
| Feature | DTU | vCore (Provisioned) | vCore (Serverless) |
|---|---|---|---|
| Billing unit | DTUs (bundled) | vCores per hour | vCores per second |
| Minimum cost | ~$5/month (Basic) | ~$365/month (2 vCores GP) | ~$233/month (0.5 vCores, no pause) |
| Storage included | Yes (per tier) | Separate charge | Separate charge |
| PITR backup included | Yes (free) | Up to max data size | Up to max data size |
| PITR overage rate | N/A | ~$0.12/GB/month (LRS) | ~$0.12/GB/month (LRS) |
| Reserved capacity | Not available | 1-year and 3-year | Not available |
| Azure Hybrid Benefit | Not available | Yes (30–55% savings) | No |
| Auto-scaling | No | No | Yes (min/max vCores) |
| Auto-pause | No | No | Yes (after idle period) |
| Hardware options | Fixed | Gen5, DC, Fsv2, M-series | Gen5 only |
| Service tiers | Basic, Standard, Premium | GP, Business Critical, Hyperscale | Limited compared with provisioned vCore |
| Best for | Predictable, small workloads | Production, hybrid benefit | Dev/test, intermittent use |
Note: Prices reflect East US, pay-as-you-go rates. Azure Hybrid Benefit and reserved capacity can reduce vCore costs significantly.
Cost Allocation Challenges: Which Team Owns What?
This is where Azure SQL pricing creates real operational pain.
When a FinOps team tries to build showback or chargeback reports for Azure SQL, they run into a structural problem: the three pricing models produce fundamentally incomparable cost units. Team A's database costs 100 DTUs. Team B's costs 4 vCores. Team C's costs vary by the second. How do you normalize these into a single cost-per-workload metric that the CFO can review?
The typical approach involves pulling utilization metrics from Azure Monitor for each database, mapping them to cost via the Azure pricing API or Cost Management export, then allocating shared resources (elastic pools, Managed Instance compute, backup storage) proportionally. In five recent customer conversations, teams described this process as manual, error-prone, and lagging weeks behind actual spend.
The specific pain points we hear:
Elastic pool allocation is essentially guesswork. Azure doesn't break out per-database costs within a pool. You see the pool cost as one line item. To allocate it, you need to pull eDTU or vCore consumption metrics per database, calculate percentage shares, and apply them to the pool cost. Most teams don't do this — they split evenly, which distorts actual cost attribution.
Backup storage has no per-database breakdown on Managed Instances. You can see the total PITR storage cost for the instance, but not which database is generating the most backup volume. Write-heavy databases that churn through transaction logs drive disproportionate backup costs, but there's no native way to see this in Cost Management.
Mixed-model environments are the norm. Legacy applications sit on DTU. New services deploy on vCore. Dev environments use serverless. Building a unified cost view across these models requires custom normalization logic that most teams build in spreadsheets — and that breaks every time someone provisions a new database in a different model.
At Flexera's FinOps Forward 2026 virtual summit, a key theme was that FinOps has expanded beyond cloud cost control into a technology value discipline. IDC's Jevin Jensen noted that teams are being asked to manage more scope without losing control. Azure SQL is a perfect example: the database service itself is well-engineered, but the cost visibility layer wasn't built for multi-team showback across heterogeneous pricing models.
How to Optimize Azure SQL Database Costs
Optimization starts with understanding which levers exist in each model. Here's what actually moves the needle:
Right-size DTU tiers based on actual peak usage. Azure provides DTU consumption metrics in the Azure portal. If your Standard S3 database consistently uses less than 40 DTUs, you can step down to S2 or S1 and save 50%+. The key metric is the percentage of DTU used over the last 14 days — look at the 95th percentile, not the average.
Evaluate vCore reserved capacity. A 1-year reservation on General Purpose compute saves approximately 33% over pay-as-you-go, and a 3-year reservation saves around 55%. If your database is running continuously and you've right-sized the tier, reservations are the single largest cost reduction lever. But they require commitment — you're paying whether you use the capacity or not.
Apply Azure Hybrid Benefit if you have SQL Server licenses. If your organization has Microsoft SQL Server licenses with active Software Assurance, applying AHB to vCore databases saves 30–55% on compute. This benefit stacks with reserved capacity, so you can get both discounts simultaneously.
Use serverless strategically, not by default. Serverless is optimal when a database has genuine idle periods — dev/test, staging, internal dashboards used only during business hours. For production databases with continuous traffic, provisioned compute with reserved capacity will almost always be cheaper. Run both scenarios in the Azure pricing calculator before committing.
Reduce PITR retention to what you actually need. The default retention is 7 days. If your compliance requirements allow it, keeping it at 7 days instead of extending to 35 days can significantly reduce backup storage costs on vCore databases. For long-term compliance, use Long-Term Retention (LTR) which stores weekly/monthly/yearly backups at lower cost than keeping a 35-day PITR window.
Consolidate into elastic pools when workloads allow. If you have multiple databases with complementary usage patterns (not all peaking at the same time), elastic pools let you share Azure resources across databases for a single pool cost. The savings can reach 60–80% compared to individual provisioned databases — but only if your peaks genuinely don't overlap.
Monitor backup storage growth on vCore databases. Backup storage is the cost that creeps up without triggering alerts. Set up Azure Monitor alerts for backup storage consumption, particularly on write-heavy databases. If backup storage consistently exceeds 2x your database size, investigate whether you can reduce write churn or shorten retention.
How nOps Helps with Azure Database Cost Management
Here at nOps, we help teams cut through the complexity of multi-model database pricing — across AWS, Azure, and GCP.
1. Unified cost visibility across pricing models. Get consistent, unified tagging, cost allocation, reporting and unit economics across your Azure, multicloud, Kubernetes and AI costs.
2. Commitment management for Azure. nOps continuously evaluates your usage and optimizes your commitments with zero effort on your part. Our adaptive laddering approach ensures you get maximum savings AND flexibility even with dynamic workloads.
3. Savings-first pricing model. We have a “pay for results” model that aligns incentives and ensures you pay nothing if we don’t deliver measurable savings.
nOps manages over $4B in cloud spend and was recently ranked #1 on G2 for Cloud Cost Management. Book a free savings analysis to see how much more you can save on Azure.
The Bottom Line
- Azure SQL pricing is more complex than it looks. Three pricing models, separate backup billing on vCore, and no native per-database cost breakdown in pools or Managed Instances.
- Backup storage is the hidden cost driver. On vCore databases with high write churn, PITR backup can exceed compute cost if left unchecked.
- Accurate showback requires tooling. Manual allocation across DTU, vCore, and serverless environments breaks at scale.
Frequently Asked Questions
Let's dive into a few FAQ about Azure SQL Database resources, allocating your Azure services, and how cloud pricing differs from traditional SQL Server deployments.
Which Azure SQL pricing model is cheapest for small applications?
Does Azure SQL charge for backup storage?
Can I use Reserved Instances with Azure SQL Serverless?
How do I allocate Azure SQL elastic pool costs to individual teams?
