AWS Aurora and RDS Graviton5 R9g Instances (November 2026): What Startups Need to Know

What did the vendor release?

On 12 November 2026, AWS announced general availability of Graviton5-based R9g database instances for Amazon Aurora and Amazon RDS. Aurora supports R9g with PostgreSQL compatibility and MySQL compatibility. Amazon RDS supports R9g for PostgreSQL, MySQL, and MariaDB.

AWS reports up to a 30% performance improvement and up to a 22% price-performance improvement for on-demand pricing compared with equivalent Graviton4 instance sizes on Amazon Aurora. AWS qualifies these figures by database engine, version, and workload. They are not guaranteed improvements for every database.

R9g instances are built on the AWS Nitro System. AWS offers nine instance sizes, ranging from large to 48xlarge. The family supports up to 192 vCPUs, an 8:1 memory-to-vCPU ratio, up to 100 Gbps of networking bandwidth, and up to 72 Gbps of Amazon EBS bandwidth. These are family-level specifications, not specifications for every instance size.

The initial availability covers US East (N. Virginia and Ohio), US West (Oregon), and Europe (Frankfurt). AWS directs customers to the Aurora and RDS documentation for supported database engine versions. Pricing is covered separately by the Aurora and RDS pricing resources.

Our recommendation: Treat this release as a new infrastructure option, not an automatic upgrade requirement. The published improvements justify testing, but they do not replace measurements from your own application.

Which startups are affected?

The release is relevant to teams using supported Aurora or RDS database engines in the announced regions. It is especially worth evaluating when database performance or infrastructure spending is already under review.

A startup using Aurora PostgreSQL or Aurora MySQL can compare R9g with its current instance family. A startup using RDS PostgreSQL, MySQL, or MariaDB can investigate the same new instance family. However, the announcement gives its quantified performance and price-performance comparisons specifically for Amazon Aurora. It does not establish identical gains for RDS workloads.

Teams outside the listed regions should not assume R9g is available locally. The announcement does not list an Asia Pacific region. Teams should also verify the exact database engine version before making migration plans.

Our recommendation: Prioritise an evaluation if your database is already approaching a performance limit, if instance costs are material, or if you have a planned infrastructure review. If the current database meets its requirements at an acceptable cost, there is no reason to change it solely because a newer instance family exists.

Adopt it or keep the existing approach?

There is a credible reason to test R9g. AWS reports improved performance and price-performance against equivalent Graviton4 instance sizes on Aurora. The published qualification matters: actual results depend on the engine, version, and workload.

That makes the choice conditional. A production database needs predictable query performance, sufficient resources, acceptable operating cost, and a controlled change process. A vendor performance headline cannot establish all four for an individual application.

Our recommendation: Benchmark R9g against the existing instance configuration using representative application traffic. Compare query latency, throughput, CPU utilisation, memory pressure, and total database cost. Record both normal operation and peak demand.

Our recommendation: Adopt R9g when testing demonstrates a meaningful improvement without unacceptable operational risk. Retain the existing instance when the benchmark shows little benefit, the supported engine version is unsuitable, or the required region is unavailable.

For startups with limited engineering capacity, a measured improvement should justify the work involved in changing the database infrastructure. A newer processor generation is not sufficient justification by itself.

What to check before enabling it?

Start with eligibility. Confirm that your database engine is one of the supported Aurora or RDS options. Check the specific engine version against AWS documentation. Confirm that the target deployment region is among the announced locations.

Next, select a candidate R9g instance size. AWS offers nine sizes from large through 48xlarge, but the maximum family specifications should not be treated as the capacity of smaller sizes. Choose a comparison based on actual memory, CPU, network, and storage requirements.

Then examine pricing. AWS states that its price-performance comparison uses on-demand pricing and depends on workload characteristics. The announcement does not provide a universal monthly saving or an individual instance price.

Our recommendation: Use the relevant AWS pricing information to estimate monthly costs before testing. Include any architecture-specific cost considerations in the comparison rather than relying on the percentage in the announcement.

Our recommendation: Run a non-production performance test, capture a baseline, and prepare a documented rollback approach. Check application behaviour during the change before considering production adoption.

AWS identifies the Amazon RDS Management Console and AWS CLI as ways to get started with R9g instances. Use the supported management path after confirming eligibility.

Our recommendation: Make the final decision using measured workload performance, supported versions, regional availability, and total cost. If any of these remain uncertain, keep the existing deployment while completing the evaluation.