AWS
Microsoft Azure
Google Cloud
Key takeaways
1
Size a new database Savings Plan from eligible hourly usage left after existing reservations and Savings Plans, priced at the plan rate not the total MySQL bill.
2
Test the proposed commitment against planned vCore changes, other eligible databases in scope, and quiet hours. A plan can remain fully used even when its benefit shifts away from MySQL.
3
Compare the same forecast under a reservation, a database plan, both, and pay-as-you-go. The largest advertised discount does not necessarily produce the lowest total cost.
A growing MySQL fleet can make a new commitment seem obvious. But a reservation may already cover much of its compute, and the next scale change could remove what remains.
How much uncovered, plan-eligible usage will recur each hour, and is a Savings Plan for Databases the best way to price it? For general mechanics and purchase steps, see our Azure database Savings Plan guide.
Buy only when that residual is durable enough within the chosen scope to justify a fixed hourly commitment for the selected term. Compare its modeled total cost with adding a MySQL reservation or leaving the uncertain portion on pay-as-you-go; planned fleet changes can reverse today’s result.
MySQL Flexible Server has Burstable, General Purpose, and Memory Optimized tiers. Microsoft’s MySQL pricing page shows one- and three-year savings plan columns for listed General Purpose and Memory Optimized SKUs; its Burstable table lists pay-as-you-go pricing only.
Check actual meters and term rates by downloading your account’s Savings Plan price sheet. Do not infer eligibility for every configuration or associated charge from the service name.
Record each candidate’s SKU, region, meter, rates, and existing benefit. Account for HA and replica compute separately. Keep storage, backup, I/O, and network costs in the whole-bill comparison, even when excluded from the commitment. Microsoft’s “up to 35%” database-plan example uses Azure SQL Database serverless, not MySQL.
How much uncovered, plan-eligible usage will recur each hour, and is a Savings Plan for Databases the best way to price it? For general mechanics and purchase steps, see our Azure database Savings Plan guide.
Short Answer
First, identify the MySQL meters that qualify for an Azure Savings Plan for Databases. Subtract usage expected to receive existing reservation and Savings Plan benefits, then calculate the remaining usage at Savings Plan rates for each hour.Buy only when that residual is durable enough within the chosen scope to justify a fixed hourly commitment for the selected term. Compare its modeled total cost with adding a MySQL reservation or leaving the uncertain portion on pay-as-you-go; planned fleet changes can reverse today’s result.
Which MySQL Costs Can a Database Savings Plan Cover?
Azure Database for MySQL appears in Microsoft’s Savings Plan for Databases overview. That does not mean every server charge is discounted. The MySQL pricing page separates compute from storage, I/O, backup storage, and other features. Size the commitment from eligible meters, not the invoice total.MySQL Flexible Server has Burstable, General Purpose, and Memory Optimized tiers. Microsoft’s MySQL pricing page shows one- and three-year savings plan columns for listed General Purpose and Memory Optimized SKUs; its Burstable table lists pay-as-you-go pricing only.
Check actual meters and term rates by downloading your account’s Savings Plan price sheet. Do not infer eligibility for every configuration or associated charge from the service name.
Record each candidate’s SKU, region, meter, rates, and existing benefit. Account for HA and replica compute separately. Keep storage, backup, I/O, and network costs in the whole-bill comparison, even when excluded from the commitment. Microsoft’s “up to 35%” database-plan example uses Azure SQL Database serverless, not MySQL.
Calculate the Hourly Opportunity After Reservations
Map eligible hourly compute to its server and SKU, then apply commitments you already own:
1
Match MySQL reservations first. Check the region, deployment type, performance tier, applicable hardware series, scope, and vCore quantity. Microsoft's MySQL reserved-capacity guidance allows vCore size flexibility within a tier and region, so a reservation is not necessarily limited to the server size visible when purchased.
2
Account for existing database Savings Plans. Check their term, scope, hourly amount, and actual consumption. Other eligible databases in scope may use the same benefit. Do not commit twice against the same usage.
3
Price the residual at its Savings Plan rate. Azure deducts discounted cost, not pay-as-you-go value, from the hourly commitment. Test that dollar amount across many hours.
Azure applies matching reservation benefits before Savings Plan benefits. If multiple plans or eligible services share a scope, model Azure’s benefit ordering instead of permanently assigning a plan to “the MySQL server.”
Illustrative calculation, not an Azure price quote: Suppose two General Purpose MySQL servers each run at eight vCores in the same region, deployment type, tier, and qualifying hardware series.
A matching eight-vCore reservation is already in place, and there is no existing database Savings Plan. Assume the other eight vCores are eligible at a hypothetical $0.12 per vCore-hour pay-as-you-go rate and $0.10 per vCore-hour plan rate.
Illustrative calculation, not an Azure price quote: Suppose two General Purpose MySQL servers each run at eight vCores in the same region, deployment type, tier, and qualifying hardware series.
A matching eight-vCore reservation is already in place, and there is no existing database Savings Plan. Assume the other eight vCores are eligible at a hypothetical $0.12 per vCore-hour pay-as-you-go rate and $0.10 per vCore-hour plan rate.
| Hourly step | Calculation | Result |
|---|---|---|
| Fleet compute | 8 + 8 vCores | 16 vCores |
| Existing reservation benefit | 16 − 8 | 8 vCores left |
| Uncovered usage at pay-as-you-go rate | 8 × $0.12 | $0.96/hour |
| Same usage at plan rate | 8 × $0.10 | $0.80/hour |
If usage persists and no other benefit intervenes, a $0.80/hour plan could save $0.16/hour versus $0.96/hour on demand. The existing reservation costs the same in both cases and is outside this incremental comparison. A purchase requires your rates, inventory, scope, and forecast.
Test the Baseline Against Planned Fleet Changes
Suppose the fleet falls from 16 to 12 vCores, while the reservation still matches eight. The remaining four consume only $0.40 of the $0.80 plan at the illustrative rate. Without other eligible usage in scope, $0.40 expires. The plan costs $0.80 versus $0.48 on demand for those four vCores: $0.32 more for that hour.When MySQL scales up, extra usage may spill into pay-as-you-go. Before adding a plan, distinguish a lasting floor from a temporary peak.
Reservation expiry needs its own before-and-after comparison. Expiring reserved vCores may become plan-eligible residual, but renewing the reservation could still cost less for a stable configuration. Test both paths from the expiry date; do not size a full-term plan as if the reservation disappeared on day one.
Test scheduled vCore reductions, tier or region moves, server additions or retirements, and HA or replica changes. Microsoft bills HA primary and standby compute and storage, and bills replicas separately.
Scaling vCores restarts the server. A stopped server ceases MySQL compute charges while it remains stopped, but Azure automatically restarts it after 30 days; a purchased plan keeps billing.
Model the chosen benefit scope, not MySQL alone. Other eligible databases may consume commitment that MySQL no longer uses, preserving utilization but shifting the benefit. A narrow scope can strand it.
Our Azure Savings Plan scope guide explains the boundaries.
Choose the Right Mix: Reservation, Savings Plan, or Pay-as-You-Go
Run the same projected hours and rates through each option. Compare commitment payments, uncovered usage, and unused benefit over the term. Headline discounts alone miss those costs.| Option | Strongest fit | Main test before buying |
|---|---|---|
| MySQL reservation | Predictable aggregate vCores within the matching attributes | Will enough matching compute remain through the term? |
| Database Savings Plan | Durable eligible spend that may move across qualifying configurations or services | Will enough discounted usage remain within scope each hour? |
| Reservation plus plan | Stable matching core plus a dependable eligible residual | Have existing benefits been removed from the new plan baseline? |
| Pay-as-you-go for now | Declining, short-lived, or poorly forecast residual | Is waiting for a clearer floor cheaper than unused commitment? |
In the example above, a new reservation for the eight residual vCores wins only if its amortized cost plus pay-as-you-go charges for any unmatched hours is lower than the plan scenario’s cost.
Repeat the comparison after the 12-vCore scale-down, when the plan’s unused $0.40 changes the result. Use your quoted reservation price, not a made-up discount.
MySQL reservations retain vCore size flexibility within the same region and tier when other matching attributes qualify. A database plan is less tied to a configuration but does not refund unused hours.
Azure’s recommendations simulate historical usage, not your planned migration. Advisor and portal recommendations use a 30-day lookback; the API offers more windows.
Allow recommendations to reflect recent commitment purchases. For broader context, see our Azure Savings Plans versus reservations guide.
A plan can be fully used by other eligible databases in scope while MySQL’s share falls. An apparently low daily utilization figure can also coexist with on-demand spillover in other hours.
In Azure Cost Management, use the plan’s utilization history and amortized cost data. Microsoft identifies unused plan cost with ChargeType = UnusedSavingsPlan and PricingModel = SavingsPlan; resource and subscription allocation can show where the benefit went.
Azure can revise benefit allocation as usage arrives within a 48-hour window, so avoid judging a purchase from a single fresh billing snapshot.
Review these measures when a reservation is bought or expires, servers move scope, vCores change, or a database is retired. You can change a plan’s benefit scope after purchase, but not its hourly commitment, term, or billing frequency.
If the fleet grows, another purchase is a separate commitment, not a resize of the first. That makes a pre-purchase forecast and a named owner for ongoing review valuable.
For supported purchases, your team approves a recommendation before we call Azure’s API. We cannot start, stop, or resize production resources.
With Flex Insured Commitments, teams can access up to 67% savings on server compute costs through an eligible three-year MySQL reservation with none of the commitment risk.
If an eligible Flex Commitment costs more than equivalent on-demand usage, cashback covers the qualifying difference under the applicable program terms. Cashback does not cancel the Azure commitment or automatically protect commitments purchased independently.
Our fee is an agreed percentage of realized savings, billed monthly in arrears after provider billing data is finalized.
Repeat the comparison after the 12-vCore scale-down, when the plan’s unused $0.40 changes the result. Use your quoted reservation price, not a made-up discount.
MySQL reservations retain vCore size flexibility within the same region and tier when other matching attributes qualify. A database plan is less tied to a configuration but does not refund unused hours.
Azure’s recommendations simulate historical usage, not your planned migration. Advisor and portal recommendations use a 30-day lookback; the API offers more windows.
Allow recommendations to reflect recent commitment purchases. For broader context, see our Azure Savings Plans versus reservations guide.
Manage MySQL Coverage After Purchase
Monitor two outcomes separately. Utilization shows how much of the plan’s hourly commitment was used. MySQL coverage shows how much intended, qualifying MySQL usage received a benefit and how much remains on demand.A plan can be fully used by other eligible databases in scope while MySQL’s share falls. An apparently low daily utilization figure can also coexist with on-demand spillover in other hours.
In Azure Cost Management, use the plan’s utilization history and amortized cost data. Microsoft identifies unused plan cost with ChargeType = UnusedSavingsPlan and PricingModel = SavingsPlan; resource and subscription allocation can show where the benefit went.
Azure can revise benefit allocation as usage arrives within a 48-hour window, so avoid judging a purchase from a single fresh billing snapshot.
Review these measures when a reservation is bought or expires, servers move scope, vCores change, or a database is retired. You can change a plan’s benefit scope after purchase, but not its hourly commitment, term, or billing frequency.
If the fleet grows, another purchase is a separate commitment, not a resize of the first. That makes a pre-purchase forecast and a named owner for ongoing review valuable.
How We Review MySQL Commitment Opportunities
After a vCore change or reservation expiry, the question is whether the remaining hourly usage can support another commitment. We analyze usage at the billing layer and offer a read-only Savings Test to assess the opportunity before purchase access is enabled.For supported purchases, your team approves a recommendation before we call Azure’s API. We cannot start, stop, or resize production resources.
With Flex Insured Commitments, teams can access up to 67% savings on server compute costs through an eligible three-year MySQL reservation with none of the commitment risk.
If an eligible Flex Commitment costs more than equivalent on-demand usage, cashback covers the qualifying difference under the applicable program terms. Cashback does not cancel the Azure commitment or automatically protect commitments purchased independently.
Our fee is an agreed percentage of realized savings, billed monthly in arrears after provider billing data is finalized.
Final Verdict: Commit to the Baseline That Survives Change
Commit against recurring plan-rate usage left after existing benefits, not the total MySQL bill. If a projected scale-down would leave recurring unused commitment, buy a smaller plan or leave that uncertain usage on pay-as-you-go.Frequently asked questions
Does Azure Savings Plan for Compute cover MySQL Flexible Server?
Managed Azure Database for MySQL is listed under the separate Savings Plan for Databases. Check its qualifying meters rather than assuming a compute plan discounts the managed database bill.
Can a MySQL reservation and a database Savings Plan both apply?
Yes, to different portions of qualifying usage in an hour. Azure applies a matching reservation first; a database plan can then apply to eligible usage remaining within its benefit scope. Avoid sizing both against the same vCores.
Does changing server size waste a MySQL reservation?
Not necessarily. MySQL reservations have vCore size flexibility within the matching performance tier and region. Test aggregate matching usage, deployment type, applicable hardware series, and scope; moving to a different tier or region requires a new match assessment.
Can other databases use a plan sized around MySQL?
Yes, when their eligible usage falls within the database plan's scope. Azure applies benefits according to its rules rather than permanently assigning the plan to MySQL. That may maintain utilization while changing cost allocation.
Can I lower the hourly commitment if MySQL usage falls?
No. Microsoft permits a scope change but does not let you change the purchased hourly amount or term. Model the downside before purchase, then monitor unused cost and the workloads consuming the benefit.
Share
Facebook
X
LinkedIn
Reddit
