New See exactly what you're overpaying AWS in under 60 seconds. Try the Calculator for free →

RDS MySQL R7g vs R8g Reserved Instances: buying guide

Compare R7g and R8g for RDS MySQL, understand RI pricing and migration timing, and choose the right Graviton commitment strategy.
Updated September 1, 2026
19 min read
RDS MySQL R7g vs R8g Reserved Instances Guide
In this article
Key takeaways
1
R8g is generally the better starting point for a new memory-optimized RDS MySQL deployment when the Region and engine version support it.
2
AWS says R8g and M8g Reserved Instances receive deeper discounts than R7g and M7g, but exact rates vary by offering and should be checked in the RDS console or API before purchase.
3
ICR can be negative. Recovered cashback can improve or eliminate a negative ESR, but does not guarantee a positive result.
4
Use ESR for standard savings reporting and ICR when documented cashback recovery is part of the commitment model.
5
R8g performance claims are benchmark maxima. Test your own workload before resizing or buying commitment coverage.
For teams comparing RDS MySQL R7g vs R8g Reserved Instances, R8g is the stronger default for a new, supported, memory-optimized baseline. AWS reports up to 40% better performance and up to 29% better On-Demand price-performance for Graviton4 RDS instances compared with Graviton3, and AWS says R8g and M8g Reserved Instances provide deeper discounts than R7g and M7g.

Short answer

Choose R8g over R7g for a new memory-optimized RDS MySQL workload when R8g is available in your Region, your engine version is supported, and the workload is stable enough for commitment coverage. If you already own R7g RIs, compare the remaining term with the cost of moving early because the reservation will not transfer to R8g. For exact pricing, use the live RDS Reserved Instance offerings in the AWS console, CLI, or API rather than relying on an old hourly-rate snapshot.

R7g to R8g decision matrix

Situation Best next step Why
New deployment Test R8g, then buy coverage You avoid starting a fresh commitment on the older generation
Active R7g RI Compare RI expiry and stranded-commitment cost R7g coverage does not apply to R8g
Uncertain baseline Stay On-Demand while testing Commitment should follow a stable workload, not precede it

Graviton options for RDS MySQL

Graviton3 powers the db.m7g and db.r7g families. AWS introduced these RDS classes with up to 30% better performance and up to 27% better price-performance than Graviton2 for supported open-source database workloads. Graviton4 powers db.m8g and db.r8g. AWS reports up to 40% better performance and up to 29% better On-Demand price-performance compared with Graviton3 for RDS open-source databases. The exact improvement depends on engine version, workload characteristics, query mix, memory behavior, and instance size. For this guide, R7g and R8g are the important comparison because both are memory-optimized families. Graviton5-based M9g is also available for RDS MySQL, but it is a general-purpose family and matters mainly when you are reconsidering whether the workload needs the R-family memory profile at all.

Why R8g is the stronger default

AWS explicitly states that Reserved Instances for 8th-generation Graviton R8g and M8g offer deeper discounts than the corresponding R7g and M7g generation. Do not convert that statement into a universal R8g savings percentage. AWS states that RDS Reserved Instances can save up to 69% compared with On-Demand for steady-state usage, but that is a broad RDS maximum, not an R8g-specific discount. The correct purchasing workflow is:
  1. Select the target instance family based on workload requirements.
  2. Validate the target size with representative production traffic.
  3. Check the live RI offering for the exact Region, engine, deployment option, term, and payment option.
  4. Buy only against the stable baseline you expect to keep.

How to compare live RI pricing

RDS Reserved Instance pricing and availability vary by Region, database engine, deployment configuration, instance class, term, and payment option. Retrieve a live offer in the RDS console or with the DescribeReservedDBInstancesOfferings API, filtering for your target instance class, engine, offering type, duration, and Multi-AZ setting. The API returns the offering’s fixed price and recurring charges, which you can use to calculate the total cost of the RI over the commitment term. Compare that result with the equivalent On-Demand instance compute cost and record the retrieval date with your comparison.
Amazon RDS Reserved Instance purchase screen showing MySQL RI pricing and term details.

Calculate your live RI comparison

Compare costs over the same commitment term.

On-Demand compute cost
=
On-Demand hourly rate × hours in the term
Total RI cost
=
Upfront fee + (recurring RI hourly charge × hours in the term)
Effective RI hourly cost
=
Total RI cost ÷ hours in the term

Use 8,760 hours for a one-year comparison or 26,280 hours for a three-year comparison.

For example, a Partial Upfront offering should include both the upfront fee and every recurring hourly charge during the term. Do not multiply an already amortized effective hourly rate by the term and then add the upfront fee again, because that would double-count part of the RI cost. Compare instance compute costs only. RDS storage, I/O, backups, data transfer, and Extended Support charges are separate from the Reserved Instance discount.

Which RI should you buy?

1. Is R8g available in your Region?

R8g availability has expanded since launch, but you should still confirm the required size in the target Region before planning the migration or reservation.

2. Does your MySQL version support R8g?

Current AWS DB instance-class support documentation lists R8g support for MySQL 8.0.32 and later. Engine lifecycle now matters separately from instance-class compatibility. If you are on MySQL 5.7 or MySQL 8.0, account for RDS Extended Support charges and plan an upgrade path because those charges are separate from RI discounts. For a new deployment, evaluate MySQL 8.4 as the current standard-support major version rather than building a fresh long-lived commitment around a version already in Extended Support. See the RDS Extended Support guide for the lifecycle cost layer.

3. Do you already own R7g RIs?

RDS size flexibility can apply reservations across eligible sizes within the same instance class family, but it does not bridge R7g and R8g. If you migrate while an R7g RI is still active, the R7g reservation continues according to its term even though your new R8g instance cannot use that coverage. Review RDS MySQL RI size flexibility before scheduling the change.

4. How stable is the baseline?

A Reserved Instance is appropriate for predictable usage. If database count, Region, instance family, or architecture may change materially, stay On-Demand until the new baseline is proven. AWS lists All Upfront and Partial Upfront RDS Reserved Instances as available in one- or three-year terms, while No Upfront RIs are available only for one year. Confirm the exact offering for your Region, engine, deployment configuration, and instance class before purchasing.

Validate R8g before reserving

AWS’s up to 40% Graviton4 performance figure is a benchmark maximum, not a guarantee for every MySQL workload. Validate the target R8g configuration against the current R7g baseline before purchasing RI coverage. Run the test for at least 48 to 72 hours and include both normal traffic and at least one representative peak workload period. Replay or route comparable traffic to both configurations so the comparison reflects similar query volume, concurrency, dataset size, and background jobs. Set the acceptance thresholds before testing. A practical baseline-relative purchase gate is:
  • p95 and p99 query latency: remain within your production SLO and no more than 5% above the existing R7g baseline.
  • Read and write throughput: reach at least 95% of the baseline at equivalent workload volume.
  • CPU utilization: p95 CPU should not increase by more than 5 percentage points compared with the baseline, while preserving enough headroom for expected peaks.
  • Database Load: p95 Database Load should remain within 10% of the baseline at comparable concurrency.
  • Memory pressure: minimum FreeableMemory should remain at least 90% of the baseline minimum, with no new sustained memory-pressure pattern.
  • Errors and timeouts: remain within the application’s existing SLO and show no meaningful increase from the baseline.
These percentages are practical internal acceptance criteria, not AWS service limits. Tighten or relax them according to your workload’s existing SLOs and operating margins. Purchase R8g RI coverage only after the target configuration passes the agreed thresholds. If latency, throughput, CPU, memory pressure, Database Load, or application errors fall outside the acceptance gate, continue testing or choose a different R8g size before committing. Do not automatically replace an r7g.xlarge with an r8g.large simply because AWS reports a generation-level performance improvement. A smaller instance changes both vCPU and memory capacity, so benchmark the exact target size you intend to reserve.  

R8g migration checklist

Confirm the target R8g size is available in the required Region.

Confirm the MySQL engine version is supported and review its support lifecycle.

Check all active R7g RI expiration dates and remaining commitment exposure.

Test the target R8g configuration with representative workload traffic.

Compare p95/p99 latency, CPU headroom, memory pressure, Database Load, connections, and throughput.

Modify the DB instance class during an appropriate maintenance window.

Recheck the stable post-migration baseline before purchasing new RI coverage.

Changing the DB instance class causes an outage or failover event depending on the deployment and change path. Do not rely on a fixed 60-to-90-second estimate. Plan the modification using AWS-documented behavior for your deployment.

How RDS RI size flexibility works

RDS size flexibility uses normalization factors to apply eligible RI benefits across sizes within the same instance class family. The important limitation is the generation boundary. An R7g RI does not become R8g coverage after an instance-class migration.

How Does Usage.ai Optimize Graviton MySQL Reserved Instances?

At Usage.ai, we focus on commitment management after you establish the correct RDS MySQL baseline. The migration and RI-timing process described in this guide helps determine which workload should be committed and when, while we can support the broader commitment-management process. Once the RDS architecture and stable eligible usage are established, we focus on the pricing and commitment layer. With Usage.ai, we analyze usage, evaluate commitment opportunities, execute approved commitment-management actions, and monitor outcomes as cloud usage changes. First choose the architecture based on availability, recovery, performance, and read-scaling requirements. Then optimize the cost of the stable usage that remains. Through our Flex Insured Commitment Program, teams can achieve up to 50% savings on covered cloud spend, on average, without taking on a three-year commitment risk. Our fee is a percentage of realized savings, and eligible commitments include cashback protection for underutilization. The cloud provider still controls the underlying commitment products, pricing, eligibility rules, and billing mechanics. We operate the optimization and management layer around eligible commitments.
REVIEW YOUR RDS COMMITMENT PLAN
Move to R8g With Confidence.

Test the new baseline, review R7g exposure, and reserve only stable usage.

Frequently asked questions

Is R8g always better than R7g for RDS MySQL?

For new supported memory-optimized deployments, R8g is generally the stronger default. Existing R7g RIs, Region availability, engine-version constraints, or workload-specific test results can justify staying on R7g temporarily.

Can an R7g RI cover R8g?

No. Size flexibility works within the applicable instance class family. R7g and R8g are different families, so an R7g reservation does not cover R8g usage.

Does R8g support 3-year RIs?

AWS lists All Upfront and Partial Upfront RDS Reserved Instances as available in one- or three-year terms, while No Upfront RIs are available only for one year. Confirm the current offering details for your Region, engine, deployment configuration, and instance class in the RDS console or API before purchasing.

Should a new RDS MySQL deployment use MySQL 8.0?

Evaluate MySQL 8.4 first for a new standard-support deployment. MySQL 8.0 entered RDS Extended Support on August 1, 2026, although compatible MySQL 8.0 versions can still run on R8g.

Should I reserve R8g before testing it?

No. Test the target size first, confirm that latency, throughput, CPU, memory, and Database Load remain within your agreed operational limits, then purchase coverage against the stable configuration.

Share
Facebook
X
LinkedIn
Reddit
Cut cloud cost with automation
Latest from our blogs