Cost

Reserve SQL PaaS database capacity

One decision that takes a stable Azure SQL Database or Managed Instance bill and cuts the compute line by committing to capacity you are already running, without changing a single database.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

SQL reserved capacity: the basics

What is Azure actually offering when it tells you to reserve SQL capacity?

Azure SQL Database and SQL Managed Instance on the vCore model are billed by default at the pay-as-you-go rate: you pay for the compute by the hour, with no commitment. That flexibility is convenient for a workload you are still sizing, but it is the most expensive way to run a database that has settled into a steady, predictable size. Reserved capacity is the alternative. You commit to a number of vCores in a region and service tier for a one or three year term, and in exchange Azure discounts the compute rate on any matching database for the life of the reservation.

Azure Advisor surfaces this as a cost recommendation: 'Consider SQL PaaS DB reserved instance to save over the pay-as-you-go costs' (it appears in newer portals as '(Preview) Consider SQL PaaS DB reserved capacity to save over your pay-as-you-go costs'). Advisor looks at your past 30 days of SQL usage, finds the capacity you have been running consistently, and works out how much the equivalent reservation would have saved. It only raises the recommendation when there is a stable baseline worth committing to, which is why it is one of the safer cost recommendations to act on.

The key thing to understand is that a reservation is a billing instrument, not a deployment. You do not move, resize or redeploy any database. The reservation is a commitment that sits over your billing account, and Azure automatically applies the discounted rate to whatever matching vCores are running at any moment. Buy the reservation and the databases you already have keep running exactly as they were, just at a lower compute rate.

In this lesson you will learn how Azure SQL reserved capacity discounts vCore compute, how Advisor decides there is a stable baseline worth reserving, how to size and buy the reservation safely with the az CLI or Bicep, and how the size flexibility and exchange rules keep the commitment from boxing you in. The focus throughout is the savings: what the reservation takes off the bill, what the payback looks like, and which calls are risk-free versus a genuine trade-off.

Fun fact

Same database, smaller bill

A reservation is one of the few changes you can make in Azure that lowers a production bill without anyone touching production. There is no migration, no downtime, no resize and no config change on the database itself: the discounted rate is applied at the billing layer to whatever matching vCores happen to be running. A team can buy a three-year SQL reservation in the portal at the end of a sprint review and the only observable effect is that next month's invoice for an unchanged set of databases is materially smaller. The catch, and the reason Advisor only recommends it on a steady baseline, is that the discount is paid for with a commitment: the value only lands if the capacity really does keep running.

Sizing a SQL reservation from real usage

Priya is the platform lead at a SaaS company whose core product runs on a handful of Azure SQL Database General Purpose Gen5 databases. Advisor has raised the SQL PaaS reserved-capacity recommendation, estimating a saving against the current pay-as-you-go spend.

Before committing to anything, Priya wants to see the actual reservation recommendation Advisor has generated, including the vCore quantity and term it has sized from the last 30 days of usage, so the commitment matches the real baseline rather than a guess.

Pull the SQL reserved-capacity recommendations Advisor has generated for the subscription. The Cost category recommendations carry the suggested SKU, region, term and saving.

$ az advisor recommendation list --category Cost \ --query "[?contains(shortDescription.solution, 'reserved')].{problem:shortDescription.problem, impact:impact}" -o table

Problem Impact

--------------------------------------------------------------- -------

Consider SQL PaaS DB reserved instance to save over pay-as-you-go High

# Advisor sized this from your last 30 days of SQL usage. Read the

# full recommendation for the exact vCore quantity, region and term.

Advisor only raises this when it sees a stable baseline worth committing to. The recommended quantity is the floor it observed over 30 days, not your peak.

How a SQL reservation applies the discountdeep dive

A reservation does not attach to a specific database. It is a commitment to a quantity of vCores for a given resource type ('SqlDatabases' or 'SqlManagedInstances'), region, service tier and hardware generation, held against a billing scope. Each hour, Azure looks at the matching SQL compute running in that scope and applies the reserved rate to as many vCores as the reservation covers, then bills anything above that at the normal pay-as-you-go rate. Add or remove databases and the discount simply flows to whatever matches, up to the reserved quantity.

Two flexibility features keep the commitment from being brittle. vCore size flexibility means you can scale a database up or down, or move capacity between single databases and elastic pools, within the same service tier and region without losing the benefit: reserve 16 General Purpose Gen5 vCores and the discount covers, say, a 4 vCore database plus an 8 vCore pool just as readily. Scope flexibility means the reservation can be applied to a single subscription, a resource group, a management group, or shared across all eligible subscriptions in the billing account, so you are not pinned to where the workload sits today.

The boundaries matter as much as the flexibility. The reserved rate covers compute vCores only: storage, backups, networking and any SQL Server licence cost are billed separately and are not discounted. The discount does not cross service tiers (General Purpose, Business Critical, Hyperscale) or regions. And reservations do not apply to the serverless compute tier or to DTU-based (Basic, Standard, Premium) databases at all, so those need to move to provisioned vCore first to be reservable. Knowing exactly what the reservation does and does not cover is what stops a commitment being mis-sized.

What is the impact of leaving SQL capacity unreserved?

The direct impact is straightforward overspend. A vCore database that runs a steady shape around the clock on pay-as-you-go is paying the on-demand premium every hour for capacity it is demonstrably going to keep using. Across an estate of stable production databases that compounds into a material, recurring overpayment, which is exactly the gap Advisor quantifies from your own 30-day usage when it raises the recommendation.

The second-order impact is that the unclaimed saving is invisible until someone looks. Pay-as-you-go is the default, so a database that settled into a steady size months ago keeps quietly billing at full rate with nothing flagging it on the invoice itself. The cost is not a spike that triggers an alert; it is a flat line that is simply higher than it needs to be, which is why these recommendations can sit open for a long time.

There is also an opportunity cost in capital terms. Money spent on undiscounted compute is money not spent elsewhere, and for a finance function the difference between a committed, discounted SQL line and an open pay-as-you-go one is real budget that could fund other work. Capturing the discount on the stable baseline is one of the highest-confidence cost moves available in Azure precisely because Advisor only surfaces it when the usage justifies it.

How do you buy a SQL reservation safely?

Treat this as a sizing exercise, not a shopping trip. The order matters: confirm the baseline and price the commitment before you buy, so you reserve the floor you actually run and not a number that strands spend.

1. Read what Advisor actually recommended

Start from the Advisor SQL reserved-capacity recommendation, which is sized from your last 30 days of usage. Note the resource type, region, service tier, hardware generation and the vCore quantity it suggests. That quantity is the observed baseline, the capacity you ran consistently, which is the safe target to reserve.

2. Separate the steady baseline from the spike

Reserve only the capacity that runs around the clock. Seasonal, batch or experimental vCores that are idle most of the time belong on pay-as-you-go, because a reservation on idle capacity strands spend instead of saving it. Confirm the databases are provisioned vCore, not serverless or DTU-based, since those are not reservable.

3. Price both terms before committing

Use the calculate command to see the exact price and saving for one-year versus three-year before you buy. Match the term to your confidence in the workload's longevity: three years captures Azure's documented discount ceiling, one year commits for less. Choose the broadest sensible scope (shared or management group) so the discount can flow as workloads move.

4. Buy, then track it as captured value

Purchase the reservation, then record the expected monthly saving and the exchange and refund path. Reservations are exchangeable without penalty and refundable within the rolling USD 50,000 quota, so a workload that genuinely changes is recoverable. Re-check Advisor periodically as usage grows, since a larger steady baseline may justify topping up the reservation.

# 1. Price the commitment first: calculate 3-year vs 1-year before buying.
#    Replace <sku> with the recommended SKU and <billing-scope> with your
#    subscription id. Read the recommended values from Azure Advisor.
az reservations reservation-order calculate \
  --reserved-resource-type SqlDatabases \
  --sku <sku> \
  --location uksouth \
  --term P3Y \
  --billing-plan Monthly \
  --quantity 16 \
  --applied-scope-type Shared \
  --billing-scope <billing-scope> \
  --display-name sql-gp-gen5-uksouth

# 2. When the price and saving look right, purchase the reservation order.
#    Generate a fresh order id; the discount then applies automatically to
#    matching vCores in scope, no database is touched.
order_id=$(cat /proc/sys/kernel/random/uuid)
az reservations reservation-order purchase \
  --reservation-order-id "$order_id" \
  --reserved-resource-type SqlDatabases \
  --sku <sku> \
  --location uksouth \
  --term P3Y \
  --billing-plan Monthly \
  --quantity 16 \
  --applied-scope-type Shared \
  --billing-scope <billing-scope> \
  --display-name sql-gp-gen5-uksouth

Quick quiz

Question 1 of 5

Azure Advisor raises 'Consider SQL PaaS DB reserved instance to save over the pay-as-you-go costs'. What does buying the reservation change about your databases?

Keep learning

Go deeper on how Azure SQL reservations are priced, sized and managed across the term.

You can now treat the SQL reserved-capacity recommendation as what it is: a billing decision that discounts compute on databases you already run, without touching one of them. Read what Advisor sized from your real usage, reserve the steady baseline and leave the spike flexible, price both terms before committing, and record the saving and the exchange and refund path so the commitment is understood as recoverable. The result is a smaller, committed SQL line for an unchanged estate.

Back to the library

SQL reserved capacity: the savings view

Turning a recurring pay-as-you-go SQL line into a committed, discounted one

This is the rare cost recommendation that lowers the bill rather than asking you to spend. Azure documents savings of up to 33 per cent against the pay-as-you-go, licence-included rate when you reserve SQL compute, and up to around 80 per cent when you combine the reservation with Azure Hybrid Benefit on workloads where you already hold eligible SQL Server licences. The exact figure depends on tier, region and term, so treat the headline as a ceiling and use Advisor's own estimate, calculated from your real 30-day usage, as the number to budget against.

The commitment is genuine: a reservation is a one or three year prepayment or monthly billing plan, so it converts a variable cost into a fixed one. That is a finance decision, not an engineering one. The right frame is the baseline. The vCores you run every hour of every day are the safe ones to reserve; the spiky, seasonal or experimental capacity is the part you leave on pay-as-you-go. Reserve the floor, not the peak.

The downside is bounded and well understood. Azure offers self-service exchange of reservations with no penalty, and self-service refund (cancellation) subject to a rolling twelve-month refund quota of USD 50,000 across the billing scope. So a reservation on a workload that genuinely shrinks is recoverable, within limits, rather than money lost. That asymmetry, a documented discount against a bounded, recoverable downside, is what makes a well-sized reservation close to free money.

This lesson is for the finance partner who sees the Advisor SQL reservation recommendation and wants to know how real the saving is, how to size the commitment so it does not strand spend, and how recoverable the decision is if the workload changes. It covers the documented discount range, the baseline-versus-peak framing, and the exchange and refund rules that bound the downside.

Fun fact

Same database, smaller bill

How a finance partner sizes the SQL commitment

Priya is the finance partner for the platform team. The Advisor recommendation lands with a headline saving against the current SQL pay-as-you-go spend, and the instinct is not to wave the three-year purchase straight through. It is to separate the baseline from the peak. The team's core databases run the same General Purpose Gen5 shape every hour of every day; the analytics database scales up only for the month-end run. The committed, around-the-clock vCores are the safe ones to reserve. The spiky analytics capacity stays on pay-as-you-go, because a reservation on capacity that is idle most of the month strands spend rather than saving it.

Priya then frames the term as a trade. The one-year reservation captures a smaller discount but commits for less; the three-year captures Azure's documented ceiling, up to roughly a third off on its own, and more again where Azure Hybrid Benefit applies to licences the company already holds, but locks in for longer. Because reservations are exchangeable without penalty and refundable within the rolling USD 50,000 quota, the three-year is recoverable rather than irreversible, which tips a genuinely stable workload toward the longer term. The finance pack reads: 'Reserve the steady baseline of N vCores on the three-year term for the documented discount; leave the month-end analytics spike on pay-as-you-go; the commitment is recoverable within the exchange and refund rules if the product re-platforms.'

Why the unreserved baseline belongs on the savings register

The arithmetic here is unusually clean. For the vCores a database runs every hour, the reservation is close to pure saving: Azure documents up to roughly a third off the pay-as-you-go, licence-included rate, and up to around 80 per cent when combined with Azure Hybrid Benefit on eligible licences. The cost of acting is the commitment itself, and that commitment is recoverable through no-penalty exchange and through refund within the rolling USD 50,000 quota. The cost of not acting is the full premium, paid every month, on capacity you were always going to run.

The discipline is in the sizing, not the decision to buy. Reserve the demonstrated floor and the saving is captured with almost no downside; reserve the peak and you strand spend on capacity that sits idle. The finance role is to push the commitment toward the baseline Advisor measured, choose the term that matches how confident you are in the workload's longevity, and record the expected saving so the reservation shows up as captured value at the next review rather than an open recommendation.

What finance owns in a SQL reservation

Finance does not run the purchase command, but it owns the decision that makes the saving real: how much to commit, for how long, and how recoverable the commitment is. Three levers.

1. Commit to the baseline, never the peak

Make it explicit that the reservation should cover only the vCores the workload runs around the clock, the floor Advisor measured over 30 days, and that seasonal or experimental capacity stays on pay-as-you-go. Reserving the baseline captures the discount with almost no downside; reserving the peak strands spend on idle capacity. The right metric is committed vCores as a share of the demonstrated steady-state, not as a share of peak.

2. Choose the term as a confidence trade

Treat one-year versus three-year as a direct trade between discount depth and commitment length. The three-year captures Azure's documented ceiling, up to roughly a third on its own and more with Azure Hybrid Benefit, but commits for longer. Anchor the choice to how confident the business is that the workload survives that horizon, and price both with the calculate command before signing off.

3. Record the saving and the exit

Book the expected monthly saving as captured value so the reservation shows up as a result, not an open recommendation, and record the exchange and refund path alongside it. Exchanges carry no penalty and refunds are available within the rolling USD 50,000 quota across the billing scope, so the commitment is recoverable. Documenting that exit up front is what lets the business commit to the longer term with confidence.

Quick quiz

Question 1 of 5

Advisor estimates a saving on the SQL reservation. As the finance partner, what is the documented discount you should budget against?

Keep learning

Go deeper on how Azure SQL reservations are priced, sized and managed across the term.

You have finished the finance view of SQL reserved capacity. You know the discount is documented, up to roughly a third on its own and up to around 80 per cent with Azure Hybrid Benefit, that the saving is captured by committing to the demonstrated baseline rather than the peak, and that the downside is bounded by no-penalty exchange and refund within the rolling USD 50,000 quota. Next time the recommendation appears, you will size to the floor, choose the term as a confidence trade, and book the saving as captured value rather than leaving it open.

Back to the library

SQL reserved capacity: the headline

Whether the estate is paying list price for database capacity it runs around the clock

Every steady-state database on the pay-as-you-go rate is paying a premium for flexibility it is not using. Reserved capacity is Azure's standing offer to discount that compute, by up to roughly a third on its own, and up to around 80 per cent combined with licences you may already own, in return for a one or three year commitment. Advisor is telling you, with a specific figure drawn from your own usage, that this money is being left on the table.

The leadership question is not technical. It is whether the organisation is willing to commit to capacity it is demonstrably going to use anyway. For a database that has run the same shape for months, that commitment is low risk: the reservation is exchangeable without penalty and refundable within a bounded quota if the workload genuinely changes.

This is a savings decision, not a security or reliability one. Nothing about the databases changes. The only question is whether the finance discipline to commit to a stable baseline is in place to capture a discount the platform is openly offering.

A short read for the leader who needs to know what reserving SQL capacity saves, why it is a low-risk commitment for a stable workload, and what a defensible reservation strategy across the estate looks like, without touching a single database.

Fun fact

Same database, smaller bill

What a disciplined reservation decision looks like from the top

After a cost review flagged that the SQL line had been flat for the better part of a year and still being billed at full pay-as-you-go rates, the CFO asked the obvious question: if the capacity is so predictable, why are we paying the price for flexibility we never use? The honest answer was that nobody owned the commitment decision. The discount was available, Advisor had been recommending it for months, and it simply had not been actioned because reserving capacity felt like a risk rather than what it is, a saving.

The team's response was to make the reservation a deliberate, owned decision rather than an open Advisor item. They sized the commitment to the demonstrated baseline, not the peak, bought a three-year reservation on the steady core and left the seasonal capacity flexible, and recorded the expected saving and the exchange and refund path so the commitment was understood as recoverable. The next cost review opened with a smaller SQL invoice for an unchanged set of databases, and a one-line note that the commitment was sized to real usage and reversible within Azure's rules. That shift, from leaving a documented discount unclaimed to capturing it as a governed decision, is the value this recommendation delivers, and it costs nothing but the discipline to commit to capacity you are already running.

Why this is a savings decision leadership should make quickly

This is the inverse of most cost-control work. Instead of asking the business to cut something it values, it asks only that the organisation commit to capacity it is already running and demonstrably depends on. The reward is a documented discount on a recurring line, and the risk is bounded by Azure's own exchange and refund rules.

The cost of hesitating is measurable and recurring: every month the recommendation sits open, the estate pays full pay-as-you-go rates on a baseline that was never going away. For a workload that has been stable for months, this is among the lowest-risk, highest-confidence savings decisions on the table, which is exactly the kind leadership should be quickest to approve.

The leadership move on SQL reservations

The executive handle is not to approve each purchase line by line; it is to put ownership on the commitment decision so a documented discount stops sitting unclaimed.

1. Give the reservation decision an owner and a deadline

An open Advisor cost recommendation is unclaimed savings with nobody accountable for it. Assign ownership of the SQL reservation decision and ask for a date by which the steady baseline is reserved on the right term and the seasonal capacity is deliberately left flexible. The goal is a governed decision, not an item that drifts open across cost reviews.

2. Ask for the saving as a number, sized to real usage

Require the team to bring the expected monthly saving drawn from Advisor's own 30-day estimate, and the committed vCores as a share of the demonstrated baseline, not the peak. That is the difference between a commitment sized to what the estate actually runs and a guess that strands spend. Approve against the number, not the intent.

3. Treat the commitment as recoverable, and say so

The hesitation around reservations is usually a fear of being locked in. Make explicit that Azure allows no-penalty exchange and refund within a bounded quota, so a commitment sized to a stable workload is recoverable if that workload genuinely changes. Naming the exit path up front is what lets leadership approve the longer, deeper-discount term rather than defaulting to caution.

Quick quiz

Question 1 of 5

Why is reserving SQL capacity framed as a savings decision rather than a security or reliability one?

Keep learning

Go deeper on how Azure SQL reservations are priced, sized and managed across the term.

Two takeaways. Reserving SQL capacity is the rare cost decision that asks only that you commit to capacity you already run, so the discount is among the lowest-risk savings on the table. And the defensible position is not 'we will get to it'; it is a sized, owned commitment to the steady baseline on the right term, with the seasonal capacity left flexible and the recoverable exit path on the record.

Back to the library

Part of the learning path Lock in Azure commitments

Reserve SQL PaaS database capacity

SQL reserved capacity: the basics

Same database, smaller bill

Sizing a SQL reservation from real usage

How a SQL reservation applies the discountdeep dive

What is the impact of leaving SQL capacity unreserved?

How do you buy a SQL reservation safely?

1. Read what Advisor actually recommended

2. Separate the steady baseline from the spike

3. Price both terms before committing

4. Buy, then track it as captured value

Quick quiz

Keep learning

SQL reserved capacity: the savings view

Same database, smaller bill

How a finance partner sizes the SQL commitment

Why the unreserved baseline belongs on the savings register

What finance owns in a SQL reservation

1. Commit to the baseline, never the peak

2. Choose the term as a confidence trade

3. Record the saving and the exit

Quick quiz

Keep learning

SQL reserved capacity: the headline

Same database, smaller bill

What a disciplined reservation decision looks like from the top

Why this is a savings decision leadership should make quickly

The leadership move on SQL reservations

1. Give the reservation decision an owner and a deadline

2. Ask for the saving as a number, sized to real usage

3. Treat the commitment as recoverable, and say so

Quick quiz

Keep learning

Related cost lessons