Cost

Reserve Azure Database for MySQL capacity

A steady MySQL Flexible Server billed at pay-as-you-go is paying a premium for flexibility it never uses. Committing to a one or three year reservation on the same compute removes that premium from the bill, with no change to the server and no change to performance.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Reserving MySQL capacity: the basics

What is Azure actually charging you a premium for?

An Azure Database for MySQL Flexible Server that runs around the clock is the textbook candidate for a reservation. Pay-as-you-go pricing buys you the right to stop paying the moment you delete the server, and for a steady production database you never exercise that right. You keep the server running month after month and pay the on-demand rate for the privilege of a flexibility you do not use. A reserved capacity commitment is the deal where you give back that flexibility, commit to keep an equivalent amount of MySQL compute running for one or three years, and Azure drops the compute rate in exchange.

Azure Advisor spots this for you. Its cost recommendation, 'Consider Database for MySQL reserved instance to save over the pay-as-you-go costs', looks at your recent compute usage and flags servers steady enough that a reservation would cost less than continuing on demand. It is the clearest kind of finding on the report: there is no risk to weigh and no security door to close, only money being left on the table on workloads you are going to run anyway.

The important detail is what the reservation does and does not cover. It is a billing instrument, not a resource. It discounts the compute (vCore) portion of a matching Flexible Server, and it does not touch storage, backup, networking or any software charge, which keep billing at their normal rates. You do not migrate, resize or restart anything. The server runs exactly as before; only the compute line on the invoice changes.

In this lesson you will learn why a steady Azure Database for MySQL Flexible Server is a strong reservation candidate, how to read and right-size the Azure Advisor recommendation, exactly what a reservation does and does not discount, and how to buy one from the CLI or Bicep without touching the running server. You will also learn where the genuine trade-off sits, so you commit the baseline you are sure of and keep variable workloads on demand.

Fun fact

The discount that was always sitting there

Azure reservations are a pure billing construct: buying one creates no new resource, changes no setting on your server and is invisible to the application. The discount is applied after the fact, hour by hour, by matching your reservation's attributes against the compute you are already consuming. That is why a reservation can start saving money minutes after purchase with nobody touching the database, and why the saving silently stops the day the term ends unless you renew. The capacity was always running. The reservation just stopped you paying the on-demand premium for it.

Finding the reservable MySQL spend

Priya runs the platform team at a SaaS company whose product sits on a handful of Azure Database for MySQL Flexible Servers that have run continuously since launch. Azure Advisor has surfaced the cost recommendation 'Consider Database for MySQL reserved instance to save over the pay-as-you-go costs' against the production subscription.

Before committing to anything, Priya wants to see exactly what Advisor is recommending and how big it sizes the saving, so the commitment matches real baseline rather than a spike. She starts by pulling the cost recommendation straight from the Advisor API.

Pull the Advisor cost recommendations for the subscription and look for the Database for MySQL reserved capacity prompt. This is the same recommendation the portal shows, read straight from the API.

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

Problem Impact

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

Consider Database for MySQL reserved instance to save over the

pay-as-you-go costs High

# Advisor sized this from your last 30 days. Now confirm the STEADY baseline before buying.

Advisor flags the opportunity and its size, but it is per subscription and based on a 30 day look-back. Before buying, confirm how much compute actually runs steady-state so you reserve the baseline, not the peak.

How an Azure reservation discount actually appliesdeep dive

A reservation is matched to usage by its attributes, not bound to a specific server. The discount applies to any Azure Database for MySQL Flexible Server compute in the reservation's region and performance tier that fits the reserved quantity, for every hour that compute runs. Because of vCore size flexibility, a reservation bought at one vCore size applies across other sizes in the same tier and region, so scaling a server up or down within the tier does not strand the benefit. If you run less matching compute in an hour than you reserved, the unused portion of that hour is simply not discounted; it does not roll over.

The reservation covers compute only. Storage, backup, networking and any software or licence component of the MySQL bill keep billing at their normal pay-as-you-go rates. This is why the saving is best reasoned about as a discount on a known slice of the invoice rather than on the server as a whole, and why a reservation never changes how the server behaves: it is an accounting overlay, applied after the meter records usage.

The commitment is fixed at purchase. You choose a one-year (P1Y) or three-year (P3Y) term and an Upfront or Monthly billing plan, and you cannot change the billing plan afterwards without going through the exchange process. The reservation does not auto-renew: when the term ends the discount stops and the compute reverts to pay-as-you-go, so the renewal decision is one to diarise rather than assume.

What is the impact of leaving steady MySQL on pay-as-you-go?

The direct impact is overspend. Every hour a steady production database runs at the on-demand rate when it qualifies for a reservation is a premium paid for flexibility the workload never uses. Across an always-on fleet over a one or three year horizon, that premium compounds into a material and entirely avoidable line on the bill. Microsoft documents the compute saving as up to roughly two-thirds off pay-as-you-go on the longest term, so the gap between the reserved and on-demand rate is the recurring cost of inaction.

The second-order impact is forecast quality. On-demand spend on permanent workloads makes the database bill look more variable than the business actually is, which muddies budgeting. A reservation converts a slice of that spend into a known, committed rate for the term, so the always-on baseline becomes a fixed and predictable number rather than a monthly on-demand figure that drifts with usage.

There is no security or compliance consequence here, which is exactly what makes this finding distinctive. Unlike most recommendations on a cost-and-security report, the only thing at stake is money. The downside of acting is bounded by the commitment, and the downside of not acting is paying the on-demand premium indefinitely on workloads you have already decided to keep.

How do you reserve MySQL capacity safely?

Treat the purchase as a sizing exercise, not a one-click accept. The order matters: confirm the baseline is genuinely permanent before you commit to a term, so the commitment never outruns the demand behind it.

1. Confirm the baseline from real usage

Pull the Advisor recommendation and check it against the actual run history of each candidate server. Reserve only the compute that has been steady and is expected to keep running. A server that was recently scaled up for a one-off event is not baseline yet, so exclude it until it proves out.

2. Match the reservation attributes to the server

A reservation discounts compute in a specific region and performance tier, sized in vCores. Read the region, tier and size off the server so the reservation lands on it. vCore size flexibility means you do not have to match the exact size within the tier, but you must match the region and tier, or the discount will not apply.

3. Choose term, scope and billing plan deliberately

Pick a three-year (P3Y) term for proven permanent baseline to get the deepest discount, and a one-year (P1Y) term where confidence is lower. Set the scope to Shared to let the discount float across subscriptions, or Single to pin it to one. Choose Upfront or Monthly billing, remembering the billing plan cannot be changed later without an exchange.

4. Price it, buy it, and diarise the renewal

Run the calculate step first to confirm the price and saving, then purchase. Because reservations do not auto-renew, set a reminder before the term ends so the discount does not silently lapse back to pay-as-you-go. Leave genuinely variable capacity on demand rather than over-committing.

# 1. Read the target server's region, tier and size so the reservation matches it.
az mysql flexible-server show \
  --resource-group prod-rg --name prod-mysql-01 \
  --query "{region:location, sku:sku.name, tier:sku.tier}" -o table

# 2. Price the reservation BEFORE buying. Confirm the saving and exact terms.
sub=$(az account show --query id -o tsv)
az reservations reservation-order calculate \
  --reserved-resource-type MySql \
  --sku Standard_D4ds_v4 \
  --location westeurope \
  --term P3Y \
  --billing-plan Upfront \
  --quantity 2 \
  --applied-scope-type Shared \
  --billing-scope "$sub" \
  --display-name prod-mysql-reservation

# 3. Purchase only the proven baseline. A new reservation order id is a fresh GUID.
order_id=$(cat /proc/sys/kernel/random/uuid)
az reservations reservation-order purchase \
  --reservation-order-id "$order_id" \
  --reserved-resource-type MySql \
  --sku Standard_D4ds_v4 \
  --location westeurope \
  --term P3Y \
  --billing-plan Upfront \
  --quantity 2 \
  --applied-scope-type Shared \
  --billing-scope "$sub" \
  --display-name prod-mysql-reservation

Quick quiz

Question 1 of 5

Azure Advisor recommends a Database for MySQL reserved instance against a production subscription. What is the most accurate way to think about what a reservation is?

Keep learning

Go deeper on how Azure Database for MySQL reservations are priced, how the discount is applied, and how to manage the commitment over its term.

You can now treat a steady Azure Database for MySQL Flexible Server as a reservation candidate rather than a standing on-demand cost: read the Advisor recommendation, confirm the baseline is genuinely permanent, match the reservation's region and tier to the server, price it with the calculate step, and buy only what you are confident you will run for the term. The server never changes; only the compute line on the bill does.

Back to the library

Reserving MySQL capacity: the savings view

Trading unused flexibility for a lower compute rate on databases you already run

This is one of the cleanest savings levers in Azure. A steady MySQL Flexible Server on pay-as-you-go is paying an on-demand premium for the option to walk away, an option a production database never takes. A reservation converts that standing on-demand spend into a discounted committed rate. Microsoft documents the compute discount as up to roughly two-thirds off the pay-as-you-go rate on a three-year term, with one-year terms saving less; the exact figure depends on the tier, region and term, so treat the headline as a ceiling and price your own servers before you commit.

The cost model is easy to reason about because the reservation only ever discounts compute. Storage, backup and networking carry on at their normal rates, so the saving applies to a known, isolatable slice of the bill. There is no migration cost, no engineering project and no performance trade. The only real decisions are term length, scope and how much of your steady fleet to commit, and Advisor sizes the recommendation from your actual usage so you are not guessing.

The one thing to respect is that a reservation is a commitment. You are agreeing to keep paying for that compute for the full term whether or not the server still exists, so the finance job is to commit only the baseline you are confident you will keep running, and leave genuinely variable or short-lived workloads on demand.

This lesson is for the finance partner who sees an Azure Advisor cost recommendation to reserve MySQL capacity and wants to know what it really saves, what it commits the business to, and how to size the purchase so the saving is banked without over-committing. It covers the discount model, the term and scope choices, and the difference between baseline that is safe to reserve and capacity that should stay on demand.

Fun fact

The discount that was always sitting there

How a finance partner frames the reservation decision

Priya is the finance partner for the platform team. The Advisor recommendation to reserve MySQL capacity lands with a headline saving attached, and the instinct is not to wave it through on the strength of that number alone. The recommendation prices a saving against the past 30 to 60 days of usage, so the first question is whether that usage is the genuine baseline or a temporary peak. A reservation is a one or three year commitment, and the saving is only real if the compute keeps running for the term.

Priya asks the team to separate the fleet into baseline and variable. Two production servers have run unchanged at the same size for over a year and will clearly keep running; those are safe to reserve on a three-year term for the largest discount. One server was scaled up for a seasonal launch and may shrink again; that capacity stays on demand or takes a shorter one-year term. The finance pack reads: 'We reserve the proven baseline at the deepest discount, keep the variable tier flexible, and the only thing we give up is the freedom to delete databases we have no intention of deleting.' The saving is banked against committed workloads, and nothing is over-committed against a spike.

Why unreserved baseline belongs on the savings register

The arithmetic here is unusually clean for cost work. The saving is a documented discount on a compute line you can isolate, the usage is already measured, and Advisor has sized the recommendation for you. There is no project to fund, no migration, no performance trade and no risk to insure against. The expected value of acting is the discount multiplied by the committed hours over the term, minus nothing but the flexibility you were not using.

The discipline finance owns is matching commitment to confidence. A reservation is a take-or-pay obligation for the full term: if the workload shrinks or moves, you still owe the commitment. So the right posture is to reserve the proven, permanent baseline at the deepest term for the largest discount, take shorter one-year terms where confidence is lower, and leave genuinely variable capacity on demand. Done that way, the saving is banked against workloads you are certain of and the commitment never outruns the demand behind it.

What finance can do about the unreserved baseline

Finance cannot run the purchase command, but it owns the framing that turns an Advisor recommendation into a right-sized commitment that banks the saving without over-committing. Three levers.

1. Separate proven baseline from variable capacity

Make the split explicit: which MySQL compute has demonstrably run for the long term and will keep running, and which is seasonal, experimental or likely to change. Reserve the first at the deepest term and leave the second on demand. The metric that belongs on the savings review is the share of always-on MySQL compute that is on a commitment versus still paying the on-demand premium.

2. Match term length to confidence, not just to the deepest discount

A three-year term saves the most but commits the most. Reserve the workloads you are certain of on three years, take one-year terms where confidence is lower, and accept a smaller discount in exchange for not locking in capacity you might not keep. The goal is the largest saving you can bank without committing past your own forecast confidence.

3. Track the renewal and the utilisation, not just the purchase

A reservation does not auto-renew, so the saving lapses silently at term end unless someone acts. And if a reserved server is deleted or shrinks below the reserved quantity, you keep paying the commitment for unused capacity. Put both on the finance calendar: a renewal review before each term ends, and a periodic utilisation check so the committed quantity still matches running demand.

Quick quiz

Question 1 of 5

Advisor reports a headline saving for reserving a MySQL server. As the finance partner, what is the right first check before committing?

Keep learning

Go deeper on how Azure Database for MySQL reservations are priced, how the discount is applied, and how to manage the commitment over its term.

You have finished the finance view of reserving MySQL capacity. You know the saving is a documented discount on an isolatable compute line, sized from real usage, with the only trade being unused flexibility. Next time an Advisor reservation recommendation lands, you will check the baseline is genuine, match term length to confidence, commit the proven baseline at the deepest term, keep variable capacity on demand, and track both utilisation and renewal so the saving is banked and never silently lapses.

Back to the library

Reserving MySQL capacity: the headline

Whether the always-on databases are paying the on-demand premium they do not need to

Some spend is a risk decision and some is simply a price you are overpaying out of habit. A production MySQL database that has run continuously for a year and is still billed at the pay-as-you-go rate is the second kind: it is paying a premium for a flexibility the business is never going to use.

The leadership question is not technical. It is whether the organisation is committing to the workloads it has already, in practice, committed to. If a database is going to run for the next three years regardless, paying the on-demand rate the whole time is a choice to leave money on the table. A reservation simply prices that reality in.

This is a low-risk, high-certainty saving. There is no change to the application, no downtime and no security consequence. The only thing being given up is the freedom to delete a database the business has no intention of deleting, in return for a materially lower compute bill on the workloads that keep the lights on.

A short read for the leader who needs to know why an always-on database billed at the on-demand rate is overpaying, why reserving it is a near risk-free saving rather than a budget gamble, and what the one real commitment, the term, actually obliges the business to.

Fun fact

The discount that was always sitting there

What it looks like when always-on spend is priced as committed

At a cost review the CFO asked why the database line had not moved in eighteen months despite the team talking about cost discipline. The honest answer was that the production databases had been billed at the pay-as-you-go rate the entire time, because nobody had converted the obvious always-on workloads onto a commitment. The business was, in effect, renting by the hour servers it had owned for over a year.

The team's response was to treat reservations as the default for proven baseline rather than an optimisation nobody got around to. They took the Advisor recommendation, confirmed which servers were genuinely permanent, and committed those to three-year reservations while leaving the variable tier on demand. The compute line on the next invoice dropped immediately, with no change to the product, no downtime and no risk to weigh. The shift, from paying the on-demand premium on workloads the business had already committed to, to pricing that commitment in, is the one-line saving this capability delivers.

Why this is the easiest saving to approve

Most cost decisions trade money against risk, capability or effort. This one does not. Reserving steady MySQL compute lowers the bill on databases the business has already committed to running, with no change to the product, no downtime and no security exposure. The only thing surrendered is the option to delete a database nobody intends to delete.

The cost of getting it wrong is small and bounded by the commitment, while the cost of doing nothing is the on-demand premium paid every hour, indefinitely, on permanent workloads. This is the rare class of decision where the upside is certain, the downside is capped and understood, and the right answer is simply to act on the proven baseline.

The leadership move on reserved capacity

The executive handle is not to approve each reservation individually; it is to make reserving proven, always-on baseline the default and to keep the commitment matched to genuine confidence. Three asks.

1. Make commitment the default for permanent workloads

Ask why any database that has run continuously for a year is still on the pay-as-you-go rate. The default for proven, always-on compute should be a reservation, with on-demand reserved for capacity that is genuinely variable. That single policy shift converts a recurring overpayment into a banked saving across the estate.

2. Keep the commitment matched to confidence

A reservation is a take-or-pay commitment for its term, so the discipline is to commit only the baseline the business is confident it will keep. Endorse three-year terms for proven permanent workloads and shorter terms where the future is less certain, so the organisation never locks in capacity it may not need.

3. Ask for the saving to be tracked, not assumed

The proof this is working is a reported figure: the share of always-on database compute under reservation and the saving it banks, reviewed each cycle, with renewals diarised before terms lapse. A reservation that silently expires back to on-demand quietly undoes the saving, so the ask is for the number to be tracked rather than taken on trust.

Quick quiz

Question 1 of 5

At a cost review you ask why the database bill has not moved despite always-on production servers. What is the defensible end state to look for?

Keep learning

Go deeper on how Azure Database for MySQL reservations are priced, how the discount is applied, and how to manage the commitment over its term.

Two takeaways. Reserving always-on MySQL compute is the rare cost decision with a certain upside and a bounded, understood downside, so making reservations the default for proven baseline is the easy call. And the commitment is the only thing being given up, so keep it matched to confidence: longer terms for permanent workloads, shorter where the future is less certain, and the saving tracked each cycle rather than assumed.

Back to the library

Part of the learning path Lock in Azure commitments

Reserve Azure Database for MySQL capacity

Reserving MySQL capacity: the basics

The discount that was always sitting there

Finding the reservable MySQL spend

How an Azure reservation discount actually appliesdeep dive

What is the impact of leaving steady MySQL on pay-as-you-go?

How do you reserve MySQL capacity safely?

1. Confirm the baseline from real usage

2. Match the reservation attributes to the server

3. Choose term, scope and billing plan deliberately

4. Price it, buy it, and diarise the renewal

Quick quiz

Keep learning

Reserving MySQL capacity: the savings view

The discount that was always sitting there

How a finance partner frames the reservation decision

Why unreserved baseline belongs on the savings register

What finance can do about the unreserved baseline

1. Separate proven baseline from variable capacity

2. Match term length to confidence, not just to the deepest discount

3. Track the renewal and the utilisation, not just the purchase

Quick quiz

Keep learning

Reserving MySQL capacity: the headline

The discount that was always sitting there

What it looks like when always-on spend is priced as committed

Why this is the easiest saving to approve

The leadership move on reserved capacity

1. Make commitment the default for permanent workloads

2. Keep the commitment matched to confidence

3. Ask for the saving to be tracked, not assumed

Quick quiz

Keep learning

Related cost lessons