Azure SQL Database cost optimization starts with a single decision that quietly governs the whole bill: which purchasing model you are on. From there it is a sequence of matching the tier and size to the workload, using serverless and elastic pools to stop paying for idle databases, and stacking Hybrid Benefit and reservations on the clean baseline. Done in that order, the savings are large and durable.
This article is part of our Azure cluster. For the full picture, start with our complete guide to Azure cost optimization, the pillar this piece links up to. Database optimization is the Cut step of our See, Cut, Lock, Run method applied to the data tier.
Azure SQL Database offers the vCore model and the DTU model. The vCore model gives transparent, separately sized compute and storage, supports Hybrid Benefit and reservations, and is where most cost control happens. The DTU model bundles resources into simple tiers. For anything cost-sensitive, the vCore model gives you the levers.
Match the tier and size to the workload
Within the vCore model, the service tier sets the price floor. General Purpose suits most workloads. Business Critical adds low-latency local storage and high availability at a premium that many databases do not need. Hyperscale targets very large or rapidly growing databases. The most common waste we find is Business Critical chosen by default for databases that would run perfectly well on General Purpose, paying a large premium for resilience the workload does not require.
Then size the compute. Read the database's real CPU, memory, and IO over at least two weeks, and pick a vCore count where the workload's high-percentile utilization lands with headroom, not where it idles at single-digit CPU. Over-provisioned vCores are the same waste as an oversized VM, and the fix is the same disciplined rightsizing we apply across the estate.
Use serverless for spiky and intermittent databases
The serverless compute tier for Azure SQL Database scales vCores automatically with load and can pause a database during inactivity so you stop paying for compute while it is idle, billing only for storage. For development databases, test environments, internal tools, and any workload with long quiet periods, serverless can cut compute cost dramatically versus a provisioned database sitting at a fixed size around the clock. The trade is a brief resume latency on the first query after a pause, which is fine for the workloads it suits and wrong for latency-critical production.
Paying Business Critical rates for General Purpose workloads?
Our Azure cost audit profiles every database, flags over-tiered and over-sized instances, and models the serverless, pooling, and commitment moves available. On the performance model, you pay only from realized savings. No savings, no fee.
Book an Azure cost audit →Pool many small databases with elastic pools
If you run many databases with uncorrelated, bursty usage, such as a per-tenant SaaS pattern, elastic pools let them share a pool of resources rather than each paying for its own peak. Because the databases rarely peak at the same time, the pool can be sized well below the sum of the individual peaks, often a substantial saving over many separately provisioned databases. The skill is grouping databases with complementary usage patterns and sizing the pool to the aggregate, not the worst case of every member.
Stack Hybrid Benefit and reservations last
Once the tier, size, and pooling are right, apply rate discounts on the clean baseline. Azure Hybrid Benefit lets you bring existing SQL Server core licenses to remove a large slice of the per-vCore cost on the vCore model. On top of that, reserved capacity for the steady, predictable databases cuts the compute rate further for a one or three year commitment. Buying these last, after rightsizing, is what keeps the discount from locking in waste. Buy them first and you commit to oversized databases for years.
| Workload | Best fit | Why |
|---|---|---|
| Steady production | vCore General Purpose + reservation + Hybrid Benefit | Lowest rate on a predictable baseline |
| Spiky / intermittent | Serverless | Auto-scale and auto-pause cut idle cost |
| Many small DBs | Elastic pool | Share capacity across uncorrelated peaks |
| Very large / growing | Hyperscale | Scales storage and read replicas independently |
Service tiers and compute options above reflect Azure SQL Database as of May 2026. Verify current tiers, serverless behavior, and reservation terms in Azure documentation before changing production databases, as the service evolves.
The Azure Cost Optimization Field Guide includes the database sizing worksheet and the tier-selection decision tree we use on engagements. It is the downloadable companion to this article.
The short version
Move cost-sensitive databases to the vCore model, match the tier and vCore size to real utilization, use serverless for spiky and intermittent work, pool many small databases with elastic pools, and stack Hybrid Benefit and reservations on the clean baseline last. For the compute side of the same estate, see AKS cost optimization. When you want it run across every database at once, that is exactly what our Azure cost optimization service delivers.