Most mature AWS accounts have a database that nobody wants to touch - because it works. It was sized by someone who left two years ago, it runs quietly at 50-70% CPU, and the only time anyone searches its name is during password rotation or an audit.
This is the kind of database we look for first in RDS fleet reviews. The platform lead sees p99 latency creeping up and starts thinking about an upsize. The FinOps owner sees a renewal calendar, an old instance family, and a line item that looks normal only because nobody has compared it with what newer hardware buys.
The database in this example is a db.m5.xlarge running Postgres. Lets keep that name in mind, because the useful part of the story is hiding inside the instance class.
Reading the License Plate
An RDS instance class is like a license plate. db.m5.xlarge. The letter is the family, the number is the hardware generation, and the end is the size. If you can read that plate, you can tell whether the database is on modern hardware before opening a single dashboard.
This one says 5. The current widely available generations are 7 & 8, with 9 already appearing for some engines. A fifth-generation database may still be fine, but it is old enough to deserve a deliberate decision.
On newer classes, there may be a processor suffix after the generation number: g, i, or a. For example, m8g means M family, generation 8, Graviton. r7i means R family, generation 7, Intel. m7a means M family, generation 7, AMD. Older/default classes like m5 often omit it. The g is Graviton, AWS's own ARM chip - usually the best price-performance option in the lineup, but according to AWS's support matrix it only runs MySQL, PostgreSQL, MariaDB, and Aurora. The i is Intel, which runs everything including SQL Server and Oracle. The a is AMD.
Because this example runs Postgres, Graviton is on the table. If the database were running SQL Server or Oracle, the decision would be simpler. You would stay on Intel-backed classes, watch the license math, and avoid the ARM move.
Decoding the License Plate
| Segment | Example | Meaning |
|---|---|---|
| Family | m | General purpose (m), memory-optimized (r), burstable (t), etc. |
| Generation | 5 | Hardware generation - latest is 7, 8, with 9 emerging |
| Processor suffix | g / i / a / omitted | Graviton (ARM), Intel (x86), AMD (x86), or older/default naming |
| Size | xlarge | Compute and memory capacity tier |
Finding the Cost Gap
The first useful question is simple: what does the current instance cost, and what does the newer instance cost?
On the public RDS pricing page, a db.r8g.large costs $0.239 an hour on-demand in us-east-1. A db.r7g.large costs the same. The newer class may give you more work for the same hourly rate.
This example uses the memory-optimized r family because it gives a clean public comparison. The database in our opening example is an m family instance, so a real review should compare the exact current class and target class in the same region, with the same engine and license model.
After price, the next question is performance. In AWS's own benchmark on RDS Postgres, Graviton4 handled 41% more queries per second than Graviton2 in a read-write OLTP test, with 29% lower latency. AWS translates that into 34% more queries per dollar. Compared with Graviton3, it still showed 23% more throughput.
The takeaway is simple: an old instance can be expensive even when the hourly rate looks normal. The waste shows up in the gap between what one dollar bought on older hardware and what the same dollar can buy on newer hardware.
This is also where engineering and cost meet. If a database is hitting high CPU during peak hours, the usual reaction is to move to a larger size. Before doing that, it is worth asking whether the same size on a newer generation would solve the problem. If it does, you get scale without a larger bill.
Before Changing the Instance Class
- The review should confirm that CPU is actually the problem. If the database is waiting on disk, locks, or bad queries, a newer generation processor would not solve the problem.
- The normal CloudWatch signals still matter: CPU, memory, storage latency, and what happens during peak traffic.
- The engine version has to support the target instance class. For example, an older Postgres 12 database cannot move directly to an m8g class.
- The reservation calendar matters too, because the right technical move can still be the wrong financial timing.
What This Means for the m5 Example
For the db.m5.xlarge Postgres database, the next question is whether the database is CPU-bound and whether the application stack is safe on ARM. The class change comes after that.
A sensible path is to test the target class in staging, confirm extensions and monitoring agents work, understand when any RI expires, and then migrate at the right time. After production has run for a while on the new class, the commitment should be based on measured usage.
Why m5 → m8g Needs a Test
Moving from m5 to m8g skips several generations and moves from Intel to Graviton, so the upside can be meaningful. AWS reported up to 40% better price-performance for Graviton2 over m5 at launch. A CPU-heavy Postgres workload may see a strong improvement. A workload waiting on storage, locks, or one slow query may see very little. The staging test tells you which story you are in before the production change.
| Comparison | Throughput Gain | Economic Takeaway |
|---|---|---|
| Graviton4 vs Graviton2 (2 gen back) | +41% QPS | AWS benchmark: +34% queries per dollar |
| Graviton4 vs Graviton3 (1 gen back) | +23% throughput | More throughput in AWS's OLTP test |
| m5 → m8g (Intel to ARM, 3 gen skip) | Strong candidate when CPU is the top wait and the app is clean on ARM | Test extensions, agents, and peak-hour queries before counting the savings |
When Waiting Is Better
This is where a good review slows down. A newer instance class helps when the database is limited by CPU or memory headroom. Sometimes another problem needs attention first.
1. CPU May Be the Wrong Bottleneck
First look at what the database is waiting for. If the top waits are CPU, newer hardware may help. If the top waits are disk, locks, or one bad query, the instance class is probably the wrong place to start. AWS says results vary by workload, and that warning matters here. A bad query plan is usually cheaper to fix than a migration.
2. Reserved Instances Make the Clock Matter More Than the Chip
This is the expensive trap. RDS reservations are standard only. Per the RI docs the discount stays inside one instance family. A db.r7g reservation leaves a db.r8g instance uncovered. If you migrate with eight months left on the old reservation, you may pay for the old reservation and the new on-demand database at the same time.
The cleaner answer is to time the migration around the reservation expiry. Size flexibility can still help inside the same family. For example, a large is 4 units and an xlarge is 8, so one xlarge RI can cover two larges. The flexibility stops when you cross the generation line. SQL Server and Oracle License-Included instances lose that size flexibility too.
3. Old Instance Often Means Old Engine
Newer instance classes often require newer database versions. For Graviton4, AWS lists minimum versions such as Postgres 13.8+, MySQL 8.0.32+, and MariaDB 11.4.3+. If your database is on an older version, the work is bigger than an instance class change. You are also planning an engine upgrade.
That upgrade can still be worth doing. If the old version has moved into Extended Support, AWS charges extra for every vCPU-hour. On a small 2-vCPU m5.large, that can mean about $292 a month in year three. Moving to a supported version removes that fee.
4. x86 to ARM Is a Real Crossing
Most standard Postgres and MySQL applications move to Graviton cleanly. AWS says they can work on Graviton without application code changes. The risky parts are usually around the edges: compiled extensions, old monitoring agents, backup tools, or anything that depends on an x86 build. Those checks belong in staging.
5. The Quiet One
Some databases are too small to be worth the migration effort right now. A tiny dev database that idles all day may be fine where it is. The important part is that someone made that decision after looking at the numbers.
Cutover Night
The savings case is only half the story. Before changing an old RDS class, the team needs a clear answer to a practical question: what happens to production when we make the change?
For a simple instance class change, RDS does a Modify operation. In a Multi-AZ setup, AWS modifies the standby first, then fails over to the updated instance. The interruption is usually the failover, often around 60 to 120 seconds. A Single-AZ database is different because the database is unavailable during the modification, so it needs a real maintenance window.
The bigger project may be the engine upgrade from the previous chapter. If the database is already on a supported engine version, the class change itself is usually a smaller and more predictable event.
What a Multi-AZ Change Usually Feels Like
The cold-cache moment is the part engineers need to expect. The buffer cache is cleared during an instance change because the new instance starts with empty memory. It has to read data from storage until the cache warms again. That can create a short latency spike even when the migration worked. This is why the team should watch wait metrics as well as latency, brief the on-call engineer in advance, and keep the snapshot ready.
The Bill, One Month Later
The cleanest outcome is simple: same size, newer generation, lower or similar rate, more headroom, and a planned upsize cancelled. That cancellation is often the biggest number in the exercise.
Then comes the commitment decision, and the order matters. It is better to right-size and migrate first, then commit. A reservation bought on the old fleet can lock old-generation waste in place for years.
During commitment planning, there is one more reason the sequence matters. In December 2025, AWS launched Database Savings Plans - a flexible 1-year commitment worth up to 20% on provisioned databases and 35% on serverless across eligible database usage.
This is a big change from RDS Reserved Instances. An RI is tied to a narrow shape: service, family, region, and generation all matter. A Database Savings Plan works more like a database spend commitment. AWS applies it across supported services such as Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, and DMS. It can also follow usage across regions, sizes, engines, and deployment types, including provisioned and serverless. For teams that are modernizing databases, that flexibility is the game changer. You can move the workload first and then commit to the database spend, instead of locking money to yesterday's instance family.
There is one important eligibility detail: Database Savings Plans cover 7th-generation instances and newer. AWS publishes the eligible-family list in AWS's raw rate data for anyone who wants to check it. An old m5 or m6 is outside that list. A new m7g or m8g is inside it.
A migration makes sense when the workload, version, reservation calendar, and operational risk all line up. The discount layer is what you check after the fleet has landed on hardware worth committing to.
The database nobody wanted to touch can keep humming. The difference is that someone finally looked at whether the old instance class still deserves to be there.
Every linked claim points to AWS's own docs, blogs, or public pricing data. Rates quoted are us-east-1, checked June 2026 - they drift, so your region should be verified before moving real money. Benchmark figures are AWS's, from one OLTP test; your workload is the benchmark that matters.
Review Your RDS Fleet Before the Next Commitment
isaga reviews RDS generation age, engine version floors, RI expiry, Savings Plan eligibility, and performance headroom together - helping you avoid stranded commitments and unnecessary upsizes.
Talk Through an RDS Review