Reserved capacity for Azure SQL Database is a one or three year commitment to a level of vCore compute in the vCore purchasing model, in exchange for a discount over pay as you go rates. It covers the compute component only; storage and the SQL Server license are billed separately, which is exactly why it pairs so well with Azure Hybrid Benefit. Reserved capacity discounts the compute, Hybrid Benefit removes the license cost from the rate by applying licenses you already own, and stacked on the same database the two cut the effective cost well below either alone. The discipline that makes it safe is the same as every commitment: cover the steady vCore baseline you will certainly run for the full term, leave variable load on pay as you go, and never reserve the peak.
Here is how the reservation works, how it stacks, and how to size coverage without stranding spend.
What is reserved capacity for Azure SQL Database?
In the vCore purchasing model, a SQL Database or managed instance is sized by the number of virtual cores it runs. Reserved capacity lets you commit to a quantity of those vCores for one or three years and pay a discounted rate on them, rather than the full pay as you go rate. The longer term and the larger commitment carry the deeper discount, on the same risk for reward logic as Azure Reservations generally. The reservation is a billing construct, not a resource lock: it applies automatically to matching vCore usage within its scope, so you are not pinning a specific database, you are pre paying for a level of compute that any eligible database can draw against. Storage, backups, and licensing sit outside the reservation and are billed on their own.
Can you combine reserved capacity with Azure Hybrid Benefit?
Yes, and stacking the two is where the real saving lives. The pay as you go vCore rate bundles compute and a SQL Server license. Azure Hybrid Benefit lets you strip the license out of that rate by applying SQL Server licenses with active Software Assurance that you already own, so you pay a base compute rate instead. Reserved capacity then discounts that base compute rate for the term of the commitment. Apply both to the same steady database and you are paying a reduced rate on a license you already hold, which is materially below the headline pay as you go number. The two levers are independent and complementary: Hybrid Benefit addresses the license, reserved capacity addresses the compute commitment, and qualifying workloads should use both.
A European SaaS company ran a fleet of production Azure SQL databases at pay as you go vCore rates, with a stable core of compute that was online continuously and a smaller variable tier that scaled with reporting cycles. It already owned SQL Server licenses with Software Assurance but was not applying them in the cloud. Two changes were made in sequence. Azure Hybrid Benefit was applied to the eligible databases, removing the license component from the rate. Then reserved capacity was sized to the steady vCore baseline only, on a three year term, leaving the variable reporting tier on pay as you go. Stacking the two on the steady core, while keeping variable load flexible, cut the SQL Database compute spend by well over a third with no change to performance or availability. The figures are verified against billing data and anonymised.
How do you size reservation coverage without stranding spend?
Size to the floor, not the ceiling. Reserved capacity is worth the discount only on vCores you actually run for the whole term, so the target is your durable baseline: the level of compute that stays online through normal troughs, not the peak it reaches under load. Pull vCore utilization over a representative period, identify the level the fleet rarely drops below, and reserve to that. Leave the variable tier above it on pay as you go, where it costs more per hour but only when it runs. Reserving the baseline captures most of the discount available while keeping you clear of the failure mode that wastes commitments, paying a discounted rate on capacity that sits idle. If the baseline is uncertain, prefer a one year term or a smaller reservation and top up later rather than overcommitting on three years.
What if your needs change mid term?
Reservations are not entirely rigid. Azure allows reservations to be exchanged and, within limits, refunded, which gives you a path if a database is retired or resized or migrated. That flexibility is a safety valve, not a reason to oversize, because exchanges and refunds carry their own conditions and are best treated as exception handling rather than routine planning. The sounder approach is to size conservatively up front so you rarely need them, then use the exchange path only when a genuine architectural change strands a reservation. Review coverage on a regular cadence alongside the rest of your Azure commitment portfolio, so reservations track the real shape of the estate as it evolves rather than drifting out of alignment.
Frequently asked questions
What is reserved capacity for Azure SQL Database?
Can you combine reserved capacity with Azure Hybrid Benefit?
How do you size SQL Database reservation coverage?
Size your SQL Database reservations with us
We size Azure SQL Database reserved capacity against your durable baseline, stack it with Hybrid Benefit where you qualify, and keep coverage aligned as the estate changes. We take zero provider commissions and answer only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on either a Fixed Fee or a no risk Gainshare basis. Book a strategy call to scope it, and follow more in The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.