TL;DR
Azure SQL Database pricing runs on three purchasing models, DTU, provisioned vCore, and serverless vCore, and the service tier you choose drives most of the bill. Stacking a 3-year Reserved Capacity commitment with Azure Hybrid Benefit is the fastest way to cut it, up to 80% off the pay-as-you-go rate.
Key Takeaways Azure SQL Database has three purchasing models, DTU, provisioned vCore, and serverless vCore, and only the vCore models qualify for Reserved Capacity or Azure Hybrid Benefit. The service tier, General Purpose, Business Critical, or Hyperscale, changes the storage architecture. Business Critical typically costs about 2.7 times General Purpose at the same vCore count. Backup storage (point-in-time restore and long-term retention) and the zone-redundancy add-on sit outside the compute bill, and they are the line items most teams miss when estimating cost. Serverless auto-pause looks free until an open connection or background job keeps the database active, which is the most common serverless billing surprise. Stacking Azure Hybrid Benefit (up to 55% off compute) with a 3-year Reserved Capacity commitment can cut the effective vCore rate by up to 80%. However, neither discount applies to Hyperscale or serverless. Kanerika’s Microsoft data-platform migration practice is recognized with Azure’s Data Warehouse Migration specialization. It treats Azure SQL Database cost decisions as part of a broader Microsoft data-platform strategy, not an isolated line item. In Flexera’s State of the Cloud survey, respondents estimate that 29% of their cloud spend is wasted, the first increase after five straight years of decline, which Flexera attributes to the rising cost complexity of AI and new platform services. Azure SQL Database is one of the places that waste hides. A team prices a service tier, signs off on the number, then watches the bill climb as backup storage, a zone-redundancy add-on, and a serverless database that never actually pauses quietly stack up.
Azure SQL Database has three separate purchasing models, DTU, provisioned vCore, and serverless vCore, and each one unlocks a different set of discounts. Layered on top is the service tier, General Purpose, Business Critical, or Hyperscale. This service tier changes the storage architecture and can move the price by close to 3x at the same compute size.
This guide walks through what each model actually charges for and where the hidden line items sit. It also shows how enterprises stack Reserved Capacity with Azure Hybrid Benefit to bring the effective rate down, and closes with how Azure cost optimization fits into a broader Microsoft data platform strategy, not just one database’s bill.
What Determines Azure SQL Database Pricing Azure SQL Database does not have one price. It has three separate purchasing models, and each one turns a different set of dials, compute, storage, redundancy, and commitment length, into the monthly bill.
The purchasing model decides which discounts are even available. DTU pricing is a flat, bundled rate. vCore pricing separates compute from storage, and only vCore databases qualify for Azure Reservations or Azure Hybrid Benefit.
Underneath the purchasing model sits the service tier, General Purpose, Business Critical, or Hyperscale. Each one uses a different storage architecture, and that architecture, not the vCore count alone, is why two databases with identical compute can carry very different bills.
A short list of what actually moves the number:
Purchasing model , DTU, provisioned vCore, or serverless vCoreService tier , General Purpose, Business Critical, or HyperscaleHardware generation , Standard-series (Gen5), DC-series, or Hyperscale premium-seriesReserved storage and actual backup storage , billed separately from computeCommitment length , pay-as-you-go, or a 1-year or 3-year reservationThis guide breaks down what each model charges for and where the line items most teams miss actually sit. It also shows how enterprises stack discounts to bring the effective rate down by as much as 80%. Choosing between purchasing models is really one piece of a larger data platform migration decision . The right database tier, after all, depends on where the workload sits in the broader Microsoft data estate.
One scope note before going further. This guide covers Azure SQL Database, the relational, transactional service. Document-oriented or globally distributed workloads usually belong on Azure Cosmos DB instead. That service prices compute in request units rather than vCores or DTUs. It is a genuinely different decision, not just a differently priced version of the same one.
DTU-Based Pricing: Basic, Standard, and Premium Tiers The DTU model bundles CPU, memory, reads, and writes into a single number. A database transaction unit blends all four into one score, calibrated against an OLTP benchmark workload that Microsoft designed to resemble typical real-world applications.
Doubling the DTUs of a database roughly doubles the resources available to it. A Premium P11 database at 1,750 DTUs provides about 350 times the compute power of a Basic database at 5 DTUs. That comparison is a useful gut check when a team is deciding whether to scale up or change tiers entirely.
Tier Max DTUs Max storage IO latency Best for Basic 5 2 GB 5 ms read / 10 ms write Dev, test, infrequent access Standard 10 to 3,000 1 TB 5 ms read / 10 ms write General production workloads Premium 125 to 4,000 4 TB 2 ms read/write Low-latency OLTP, in-memory tables
DTU pricing has one structural weakness. It is the only model that cannot use Reserved Capacity or Azure Hybrid Benefit. Microsoft’s own reservation documentation states plainly that DTU-based databases, Basic, Standard, or Premium, are not eligible for reservation pricing at all.
When Teams Move Off DTU Teams migrating an on-premises SQL Server instance often start on DTU because it loosely maps to a familiar “server size.” Many move to vCore once the SQL Server migration is stable and real workload patterns are known. At that point, the discount-eligible vCore model usually becomes the cheaper long-term choice.
DTU also caps out lower than vCore. Standard tops out at 3,000 DTUs and 1 TB, and Premium tops out at 4 TB. Enterprises running cloud data warehouse -scale workloads outgrow those ceilings well before they outgrow vCore’s 128 TB Hyperscale limit.
The move off DTU is usually part of a bigger project rather than a standalone resize. Choosing the right data migration tools to move schema, data, and connection strings without downtime matters more to the project timeline than the DTU-to-vCore mapping itself.
vCore-Based Pricing: General Purpose, Business Critical, and Hyperscale The vCore purchasing model separates the bill into service tier, hardware generation, vCore count, memory, reserved storage, and backup storage. That separation is also what makes vCore eligible for Reserved Capacity and Azure Hybrid Benefit, benefits DTU cannot access at all.
A vCore represents one logical CPU. Provisioned compute bills a fixed hourly rate for capacity that is always on, whether or not the workload is using it. Serverless compute, covered in the next section, bills per second instead.
Three service tiers sit on top of the vCore model, and they are not just performance tiers. Each one is a genuinely different storage architecture, which is the real reason the price gap between them is so large.
Tier Storage type Storage size Availability Discount models General Purpose Remote premium storage 1 GB to 4 TB 1 replica, zone-redundant HA Reservations, Hybrid Benefit Business Critical Local SSD (per node) 1 GB to 4 TB 3 replicas, 1 free read-scale copy Reservations, Hybrid Benefit Hyperscale Decoupled, local SSD cache 10 GB to 128 TB 0 to 4 configurable replicas Reservations only, no new Hybrid Benefit
How the Three Service Tiers Compare in Practice General Purpose separates a stateless compute layer from data files sitting in Azure Blob storage. It is the budget-oriented default, and Microsoft recommends it as the starting point for most new workloads.
Business Critical instead runs a four-node cluster where compute and storage sit together on the same local SSD, replicated across three secondary copies. That extra resilience comes at a cost. Microsoft’s own documentation puts Business Critical compute at roughly 2.7 times the price of General Purpose at the same vCore count.
Hyperscale decouples storage entirely, caching locally but scaling storage independently up to 128 TB. Customers choose their own replica count, from zero to four. This flexibility lets Hyperscale control resiliency cost instead of forcing every database to pay for redundancy it does not need.
Teams evaluating Hyperscale against a lakehouse platform for the same analytical workload should treat it as a genuinely different architecture question. Kanerika’s comparisons of Azure Synapse vs Databricks and Azure Databricks vs Snowflake cover that decision in more depth than a pricing guide for a single transactional database can.
Serverless Compute: Pay-Per-Second, With a Catch Serverless bills per second instead of per hour. Compute autoscales between a minimum and maximum vCore count that the team sets, and the database pauses automatically after a configurable period of inactivity. At that point, only storage costs apply.
Microsoft’s serverless documentation defines auto-pause precisely. It triggers only when session count is zero and CPU usage in the user workload pool is zero, for the entire configured delay window. Miss either condition and the database stays online.
That precision is the catch. An open connection pool, a monitoring agent, or a background job that never fully disconnects can hold a serverless database “active” indefinitely. At that point, it bills the minimum provisioned compute continuously instead of ever reaching the zero-cost paused state.
Serverless is only available on the vCore model, only on Standard-series (Gen5) hardware, and only in the General Purpose and Hyperscale tiers, not Business Critical. It also cannot use Azure Hybrid Benefit or Reserved Capacity under any circumstances, because there is no fixed provisioned rate to discount.
It fits a specific workload shape well, intermittent, spiky traffic with real idle periods, or a brand-new database where nobody yet knows how much compute it needs. A steady, always-on production database is almost always cheaper on provisioned vCore with a reservation attached.
Kanerika Service
Running a Mixed Azure and SQL Server Estate?
Kanerika’s Azure Cloud Solutions practice assesses real DTU and vCore utilization before recommending a service tier, purchasing model, or migration path.
Explore Azure Cloud Solutions Catching a database that never actually pauses requires watching it, not guessing. Azure monitoring tools that track active sessions and CPU-in-user-pool over time turn “is this serverless database actually pausing” from a support ticket into a dashboard.
The Storage and Backup Costs Most Teams Miss Compute is the number everyone estimates first. Storage and backup are the numbers that show up on the first real invoice and start the “why is this higher than we planned” conversation.
In General Purpose and Business Critical, configuring a maximum data size automatically adds 30 percent more billable storage for the log file, on top of the data size itself. Hyperscale works differently. It bills only for storage actually allocated, with no fixed maximum and no separate log charge.
Backup storage is billed separately from data and log storage, and it covers two distinct capabilities:
Point-in-time restore (PITR) , full, differential, and transaction log backups retained for 1 to 35 days, which grow with the database’s rate of changeLong-term retention (LTR) , optional full backups retained for up to 10 years to meet compliance requirements, billed on top of PITRZone redundancy adds one more line item. Enabling zone-redundant storage on General Purpose databases and elastic pools bills the zone-redundancy add-on separately from standard compute. In addition, a Reserved Capacity commitment needs its own separate “vCore ZR” reservation to cover it. A standard vCore reservation does not automatically extend to the zone-redundant add-on.
None of this is hidden exactly. It is documented. It is just easy to price the headline vCore rate and skip the backup and redundancy lines. The result is a bill that runs 15 to 25 percent above the original estimate.
Teams building a broader data warehouse tooling stack around Azure SQL Database should price backup and retention against the same compliance requirements driving the rest of the platform. This approach beats setting retention policy per database in isolation.
Elastic Pools: Pricing When You Run Many Databases Most enterprises are not pricing one database. They are pricing dozens, and many of those databases spend most of the day nearly idle.
An elastic pool shares a single resource budget across every database inside it. That budget is measured in elastic Database Transaction Units under the DTU model, or pooled vCores under the vCore model. A database under heavy load draws more of the shared pool. A quiet database draws almost nothing, and the pool guarantees every member a minimum floor so no single database starves the rest.
Pools fit a specific pattern well, many databases with a low average utilization and unpredictable, infrequent spikes, the classic shape of a multi-tenant SaaS estate. A database with consistently high, predictable utilization usually costs less as its own single database than as a pool member. This is because it stops sharing capacity it would use anyway.
Kanerika’s engineering teams see this most often in data warehouse migration work. A client moves 40 to 60 per-tenant databases off an on-premises SQL Server farm and prices each one individually out of habit. As a result, an elastic pool would have covered the same workload at a fraction of the combined vCore count.
The same per-tenant pattern shows up constantly in Azure migration tooling projects. Dozens of small databases typically arrive from an on-premises multi-tenant application built long before pooling existed as an option.
DTU vs vCore: Which Purchasing Model Actually Costs Less There is no universal answer, because the two models are optimized for different things. DTU bundles a fixed amount of everything into one price. The vCore model, by contrast, lets a team pay separately for exactly the compute and storage the workload needs. It also unlocks Reserved Capacity and Azure Hybrid Benefit on top of that.
For a small, stable, low-complexity workload, DTU’s simplicity can still be the cheaper and easier option, especially below Standard S3, where CPU-intensive workloads start to need more than DTU’s bundled allocation provides.
For anything larger, longer-lived, or running with existing SQL Server licenses, vCore is very rarely more expensive once discounts are applied. It is also the only path to Hyperscale’s storage ceiling or Business Critical’s replica model. Microsoft itself frames vCore as the model built for migrations where matching on-premises hardware specs to cloud resources matters. This is also why teams comparing Azure against AWS and Google Cloud tend to size the vCore model first. After all, it is the closest analog to what they are used to pricing elsewhere.
The practical decision rule Kanerika’s teams use with clients is simple. Start any new, unpredictable workload on DTU or serverless vCore to avoid over-committing before usage patterns are known. Then, move it to provisioned vCore with a reservation the moment its utilization becomes predictable for more than a quarter. Teams weighing whether to migrate a workload onto Microsoft Fabric or another platform instead of staying on Azure SQL Database can model the switching cost first. Kanerika’s free Migration ROI Calculator makes that comparison before locking in either purchasing model.
How to Cut Azure SQL Database Costs: Reservations, Hybrid Benefit, and Right-Sizing Three levers do almost all of the real cost-cutting work here, and they stack.
Right-sizing comes first, before any commitment. Teams frequently choose a vCore count at deployment time and never revisit it. The only lever with zero commitment risk is reviewing actual CPU, memory, and IO utilization against the provisioned size. This review should happen on a recurring cadence, not just once at launch.
Azure Hybrid Benefit comes next. Enterprises with active Software Assurance on existing SQL Server licenses can apply Azure Hybrid Benefit to General Purpose and Business Critical databases for a significant discount on the compute rate. It does not apply to Hyperscale or serverless, and existing Hyperscale databases can only keep using it through December 2026.
Reserved Capacity stacks on top of both. A 1-year or 3-year vCore reservation locks in a discounted rate against a committed amount of compute in a specific region, tier, and hardware configuration. It does not need to be tied to a specific database. Any matching deployment in scope automatically gets the benefit, and Microsoft’s guidance confirms reservations apply only to the vCore model, never DTU.
Combined, Azure Hybrid Benefit and a 3-year reservation can cut the effective compute rate by up to 80% off the full pay-as-you-go, license-included price. That combination is why enterprises standardizing on Microsoft Azure Consumption Commitment agreements treat SQL Database reservations as a default line item, not an optional optimization.
Reservation Risks Worth Knowing Before You Commit One caution on reservations. They are a billing discount, not a resource guarantee. Buying a reservation does not pre-allocate infrastructure, and canceling, exchanging, or refunding one carries limitations worth reading before committing three years of spend.
Reservation sizing gets harder, not easier, mid-migration. A team actively running an Azure data migration should wait until vCore counts stabilize post-cutover. Only then should it lock in a 3-year term against a size that is still likely to change.
On-Demand Webinar
How to Reduce Your Fabric Migration Cost with Microsoft Funding
A practical look at using Microsoft funding programs to offset the cost of moving a Microsoft data estate, including Azure SQL Database workloads, onto Microsoft Fabric.
Watch the Webinar → A Worked Pricing Example: Estimating a Mid-Size OLTP Workload Numbers make the model concrete faster than another paragraph of theory. Consider a mid-size order-management application, predictable business-hours traffic, roughly 200 GB of active data, and a requirement for standard high availability but not sub-2-millisecond storage latency.
That profile points toward General Purpose, not Business Critical. The workload is predictable enough to skip serverless. The comparison worth running is provisioned vCore at pay-as-you-go versus the same configuration with Azure Hybrid Benefit and a 3-year reservation applied.
Pick the tier and size. General Purpose, Standard-series (Gen5), sized to the vCore count that covers observed peak CPU with headroom, not a round number chosen by guesswork.Add storage. Reserved data storage for the 200 GB, plus the automatic 30 percent log allowance, priced per GB per month.Add backup. PITR storage sized to the configured retention window, plus any LTR policy required for compliance.Price it three ways. Full pay-as-you-go, pay-as-you-go with Azure Hybrid Benefit alone, and Hybrid Benefit stacked with a 3-year reservation.The gap between the first and last number in that comparison is routinely the single largest line item a FinOps review finds. It shows up in a database that has been running unreviewed for a year or more. The Azure pricing calculator runs this exact comparison for a specific region and configuration, and it is worth re-running every time a workload’s shape changes materially.
That same 200 GB order-management database rarely serves transactions alone. It usually also feeds a Power BI reporting layer. The read load from dashboards refreshing throughout the day is exactly the kind of extra IO that pushes a General Purpose estimate toward Business Critical, often before anyone accounts for it.
Common Azure SQL Database Pricing Mistakes That Inflate the Bill Most cost overruns trace back to a small, repeating set of mistakes, not to Azure pricing being unpredictable.
Defaulting to Business Critical for non-critical workloads. Paying roughly 2.7 times the General Purpose rate for replica resilience a workload does not actually need is the single most expensive habit on this list.Forgetting backup storage exists as a separate charge. PITR and long-term retention are billed independently of compute and data storage, and neither shows up in a quick vCore-only estimate.Leaving steady workloads on pay-as-you-go. A database running unchanged for six months with no Reserved Capacity is leaving a discount of up to 80% unclaimed for no reason tied to actual risk.Running “serverless” databases that never pause. An open connection pool or monitoring agent blocks auto-pause silently, and the database bills like provisioned compute at a worse effective rate.Never revisiting vCore sizing after launch. A size chosen at go-live based on projected, not measured, load routinely overshoots real utilization by a wide margin within the first quarter.Each mistake is straightforward to fix in isolation. The harder part is catching all five on a recurring cadence instead of once at deployment and never again. This is exactly where cloud cost management programs actually earn their keep. Pipelines feeding the database matter too. A poorly tuned Azure Data Factory pipeline writing in small, frequent batches drives up log IO and, indirectly, the compute tier needed to keep up with it.
Azure SQL Database or Something Else? Comparing the Alternatives Azure SQL Database is not the only place a SQL Server workload can land in Azure, and the pricing comparison only makes sense next to what each alternative is actually built for.
Option Pricing basis Choose it when Azure SQL Database DTU or vCore, per database Modern app, single-database isolation is fine SQL Managed Instance vCore, per instance Needs near-full SQL Server surface area or cross-database queries SQL database in Microsoft Fabric Fabric capacity units Already standardizing analytics on Microsoft Fabric SQL Server on Azure VM VM compute + SQL license Needs OS-level control or a legacy, unsupported feature
SQL Managed Instance targets teams that need near-complete SQL Server compatibility, including cross-database queries and SQL Agent jobs, features single databases do not support. It prices closer to a dedicated instance than a per-database service.
SQL database in Microsoft Fabric is the newest path, billed through Fabric capacity rather than standalone vCores. It fits organizations already committed to Microsoft Fabric as their analytics platform who want an operational database inside the same governance boundary.
SQL Server on an Azure VM remains the answer for workloads that need full operating-system access. It also fits legacy SQL Server features that Azure SQL Database has not implemented. It is rarely the cheapest option once management overhead is counted, but it is sometimes the only compliant one.
Talk to Kanerika
Not Sure Which Azure SQL Database Tier Fits Your Workload?
Kanerika’s data platform team reviews your real utilization data and licensing position, then recommends the tier, purchasing model, and discount stack that fits.
Talk to Kanerika → When None of These Four Are the Right Fit None of these four are the right comparison if the actual requirement is AI workloads reading from the database rather than more transactional capacity. That is a separate evaluation, closer to Azure AI Foundry territory than a database-tier decision. It is worth scoping before assuming the database itself needs to change.
How Kanerika Helps Enterprises Control Azure SQL Database Costs Pricing tables answer “what does this cost.” They do not answer “what should we actually be running.” That is the harder and more valuable question for most enterprises carrying a mix of legacy SQL Server, Azure SQL Database, and Microsoft Fabric workloads.
Kanerika earned Microsoft’s Data Warehouse Migration to Microsoft Azure specialization in December 2025, on top of an existing Azure Data and Analytics specialization. That recognition reflects a delivery model built around four stages. Kanerika assesses the current estate and its real utilization data, then designs the target tier and purchasing model against actual workload behavior. From there, the team migrates or right-sizes in controlled waves and governs the result with recurring cost reviews instead of a one-time cleanup.
That assessment stage is where most of the savings identified in this guide actually get found. Kanerika’s teams pull real DTU and vCore utilization history before recommending a tier, rather than sizing off the application’s original architecture diagram. That diagram is almost always stale by the time a cost review happens.
A Proof Point From Kanerika’s Microsoft Data-Platform Work One proof point from that broader Microsoft data-platform practice is Kanerika’s work helping FoodPharma consolidate six operational systems onto Microsoft Fabric. Microsoft’s own published customer story verifies the result directly. The consolidation cut cross-functional reporting time from two business days to 90 minutes. It also recovered roughly 15 hours a week of manual data work for the BI team.Case Study
80% Faster Insights: Azure Data Factory to Fabric Migration
Kanerika’s Azure Data Factory to Microsoft Fabric migration work for a Microsoft data-platform client delivered 80% faster insights, the same delivery discipline applied to Azure SQL Database cost decisions.
Read the Case Study →
The pitfall Kanerika’s teams watch for most often is a tier choice made once at deployment and never revisited. Meanwhile, the workload, the license position, and the available discounts all keep changing underneath it. A platform-agnostic view across Azure SQL Database, Fabric, Snowflake , and Databricks also matters here. Sometimes the honest recommendation is that the workload belongs on a different Microsoft data platform tier entirely, not just a differently priced version of the current one. Occasionally, that means an Azure-to-Fabric migration rather than a database resize at all.
For enterprises running a live SQL Server or Azure SQL Database estate today, Kanerika’s Azure Cloud Solutions practice runs that assessment against real usage data. It does this before recommending a single vCore.
Frequently Asked Questions What determines Azure SQL Database pricing? Azure SQL Database pricing depends on the purchasing model (DTU, provisioned vCore, or serverless vCore), the service tier (General Purpose, Business Critical, or Hyperscale), the hardware generation, reserved and actual backup storage, and whether a commitment discount like Reserved Capacity or Azure Hybrid Benefit applies. The purchasing model determines which discounts are even available, and the service tier determines the underlying storage architecture and resilience level.
Is DTU or vCore cheaper for Azure SQL Database? It depends on the workload. DTU’s bundled, simple pricing can be cheaper for small, stable, low-complexity databases, especially below Standard S3. For larger or longer-lived workloads, vCore is rarely more expensive once Azure Hybrid Benefit and Reserved Capacity are applied, since DTU databases cannot use either discount at all.
How much can Azure Hybrid Benefit save on Azure SQL Database? Azure Hybrid Benefit can save up to 55% on the compute rate for General Purpose and Business Critical databases when an enterprise has active Software Assurance on existing SQL Server licenses. It does not apply to the Hyperscale tier for new databases or to the serverless compute tier.
Can I combine Azure Hybrid Benefit with Reserved Capacity? Yes. Stacking Azure Hybrid Benefit with a 3-year Reserved Capacity commitment can cut the effective compute rate by up to 80% off the full pay-as-you-go, license-included price. Reserved Capacity itself is only available on the vCore purchasing model, never DTU.
Does Azure SQL Database serverless actually save money? It can, for workloads with genuine idle periods, since compute cost drops to zero while a database is paused. The savings disappear if the database never actually pauses, which happens when an open connection, background job, or monitoring agent keeps at least one session active through the entire auto-pause delay window.
Why is my Azure SQL Database bill higher than the vCore price I calculated? The most common reasons are backup storage (point-in-time restore and long-term retention, both billed separately from compute), the zone-redundancy add-on if zone-redundant storage is enabled, and the automatic 30% log storage allowance added on top of configured data size in General Purpose and Business Critical.
What is the price difference between General Purpose and Business Critical? Business Critical typically costs about 2.7 times more than General Purpose at the same vCore count. The premium reflects Business Critical’s four-node cluster architecture with three secondary replicas on local SSD storage, versus General Purpose’s single stateless compute layer backed by remote Blob storage.
Is Azure SQL Database cheaper than SQL Server on a VM? Azure SQL Database is usually cheaper once management overhead is included, since it removes patching, backup infrastructure, and OS administration from the customer’s side. SQL Server on an Azure VM can still work out cheaper for specific cases, such as workloads needing full OS-level control or a legacy SQL Server feature Azure SQL Database has not implemented, but those cases are the exception rather than the rule.
