If you run Amazon RDS for MySQL, you’ve probably gotten the email by now. RDS for MySQL 8.0 reaches end of standard support on July 31, 2026, and the day after, AWS starts charging you Extended Support fees on any instance still running 8.0. It’s not a shutdown — your database keeps working — but it’s a meter that starts spinning on August 1, and it runs for three years.
I’ve watched a few of these deprecation cycles go by (5.7 did the exact same thing), and the pattern is always the same: teams see the email, file it under “deal with later,” and then get surprised by a line item on the September bill. Let’s make sure that’s not you. Here’s what auto-enrollment actually costs, what the upgrade to 8.4 breaks, and how to do the upgrade without a 2am rollback.
What “end of standard support” actually means
First, the good news: nothing gets deleted, nothing gets shut off. Your 8.0 instance keeps running exactly as before. AWS doesn’t force an upgrade or terminate anything.
The catch is billing. Starting August 1, 2026, every RDS instance still on MySQL 8.0 gets auto-enrolled into Extended Support, and Extended Support isn’t free. You don’t opt in — you opt out, and the only way to opt out is to upgrade off 8.0 before the deadline. If you do nothing, the charges just appear.
Extended Support does buy you something real: AWS keeps shipping critical security patches (CVEs) and bug fixes for 8.0 until July 31, 2029. Without it, you’d be running an unpatched database engine, which is its own kind of problem. So it’s not a scam — it’s a paid grace period. The question is whether you want to pay for that grace period or just get current.
The bill: per-vCPU math that adds up fast
Extended Support is priced per vCPU, per hour — not per instance, not per GB. That detail matters, because it means the cost scales with how beefy your instances are, and it stacks on top of your normal RDS charges.
In US East, the pricing is:
- $0.100 per vCPU-hour for years 1 and 2 (Aug 2026 – Jul 2028)
- $0.200 per vCPU-hour for year 3 (Aug 2028 – Jul 2029)
Let’s put real numbers on it. Say you’re running a db.m6i.xlarge — that’s 4 vCPUs. Assume ~730 hours in a month.
- Years 1–2: 4 vCPU × $0.100 × 730 hrs = ~$292/month in extra charges
- Year 3: 4 vCPU × $0.200 × 730 hrs = ~$584/month
And here’s the part people miss: if that instance is Multi-AZ, you’re paying for both the primary and the standby. Double it. A single Multi-AZ 4-vCPU database is looking at roughly $584/month in years 1–2, climbing to ~$1,168/month in year 3 — purely for the privilege of not upgrading.
Now scale that mentally across a fleet. Ten mid-sized instances, a couple of them Multi-AZ, and you’re staring at five figures a year of pure overhead. For a database engine you could upgrade in an afternoon. That’s the math that makes the upgrade worth prioritizing.
Two things worth checking before you panic-budget:
- Aurora MySQL has its own timeline. This deadline is specifically RDS for MySQL. Aurora versions deprecate on a separate schedule, so don’t assume the dates line up.
- The charge is region-specific. The $0.100/$0.200 figures are US East (Ohio/N. Virginia). Other regions differ — check the RDS for MySQL pricing page for yours before you do the math.
Why 8.4 is a real upgrade, not a point release
The obvious escape hatch is to upgrade to MySQL 8.4, which is the current LTS (long-term support) version on RDS and now generally available. But don’t let the version number fool you — going from 8.0 to 8.4 is a major version upgrade, not a patch. MySQL changed its versioning model, so 8.4 behaves like what used to be a “9.0” would have.
That means breaking changes, and a few of them will bite real applications:
mysql_native_password is disabled by default. This is the big one. In 8.4, the old mysql_native_password authentication plugin is off by default. Any database user still authenticating with it will simply fail to log in after the upgrade — your app throws auth errors and you’re scrambling. Older client libraries, legacy ORMs, and anything that hasn’t switched to caching_sha2_password are the usual victims. Audit your user accounts before you upgrade, not after.
Reserved words and deprecated syntax. MySQL 8.4 adds reserved keywords and removes syntax that was deprecated in 8.0. If you’ve got a column named rank or a stored procedure using something that got cut, queries that worked yesterday will error out. The RDS prechecks catch a lot of this on the schema side — but they explicitly do not validate your application code. A reserved word buried in a query string inside your app is your problem to find.
Removed and changed system variables. Some server variables and defaults changed. If your parameter group leans on anything deprecated in 8.0, expect it to be gone or renamed in 8.4. The restrict_fk_on_non_standard_key parameter is one of the new behaviors to be aware of.
None of this is catastrophic, but all of it is the kind of thing that turns a “quick upgrade” into an incident if you skip testing. Which brings us to how to actually do it safely.
The safe upgrade playbook
The core idea: never upgrade production in place and hope. Test the upgrade on a copy first, then do the real thing with a rollback path already in place. AWS’s own guidance lands on a three-phase approach, and it’s the right one.
Phase 1 — Run the prechecks
Before touching anything, run the pre-upgrade compatibility checks. RDS runs these automatically when you initiate a major version upgrade, but you want to see the results early, not at cutover. The prechecks scan your schema for incompatibilities — reserved words in procedure definitions, deprecated data types, orphaned objects, that sort of thing.
Read the output carefully. Fix every flagged item in a staging environment first. And remember the limitation: prechecks look at the database, not your application. So pair the automated check with a manual audit of your app’s auth config and any raw SQL you control.
Phase 2 — Test on a clone
Don’t let production be the first place you run this upgrade. Two solid ways to rehearse:
- Snapshot restore: take a snapshot of production, restore it to a throwaway instance, upgrade that to 8.4, and point a staging copy of your app at it. Run your test suite. Watch for auth failures and query errors.
- Blue/Green Deployment: spin one up, which creates a synced green (8.4) copy alongside your live blue (8.0), and validate against the green environment before you ever cut over.
Either way, the goal is to hit every breaking change in a place where breaking it costs nothing.
Phase 3 — Cut over with Blue/Green
For the production upgrade itself, RDS Blue/Green Deployments are the move for anything you can’t afford to break. Here’s why it beats an in-place upgrade:
Your blue (8.0) environment stays live and serving traffic the entire time. AWS builds a green (8.4) environment kept in sync via replication. You test the green side thoroughly, and when you’re ready, the switchover takes seconds — RDS redirects traffic from blue to green in one quick, managed step. Downtime is measured in seconds, not the minutes-to-hours an in-place upgrade can take.
And the rollback is the real selling point. Because blue stays intact through the switchover, if something goes wrong you flip back fast. The stronger setups add reverse replication so the old blue environment keeps receiving writes made to green after cutover — meaning even a delayed “oh no, roll it back” doesn’t lose the transactions that landed in the meantime. An in-place upgrade gives you none of that; if it goes sideways, you’re restoring from a snapshot and eating the data written since.
One honest caveat: Blue/Green isn’t zero-effort. It spins up a full duplicate environment (so you’re briefly paying for two), and you have to manage the cutover window and clean up the old environment afterward. But for a production database facing a hard deadline, that’s cheap insurance.
Upgrade now, pay Extended Support, or leave RDS entirely?
Not every team should just rush the upgrade. Here’s how I’d think about the three paths.
Upgrade to 8.4 now. This is the default answer for most people. You dodge every Extended Support charge, you’re on the current LTS with support through at least 2032, and you get the newer engine’s improvements. The cost is the engineering time to handle the breaking changes and test properly. If your app is reasonably modern and you have a staging environment, this is a few days of work, not a quarter.
Pay Extended Support and buy time. Sometimes the calendar just doesn’t cooperate — a feature freeze, a compliance audit, an app you can’t safely touch this quarter. Extended Support exists exactly for this. You keep getting security patches through July 2029, and you upgrade on your own schedule. Just go in with eyes open: it’s real money per vCPU-hour, it escalates in year 3, and “we’ll upgrade next quarter” has a way of becoming “we paid three years of Extended Support.” Treat it as a deliberate, budgeted decision, not a default.
Migrate off RDS. If this deadline has you rethinking the whole setup, it’s a natural forcing function. Maybe you move to Aurora MySQL for the storage and failover model, or to a serverless Postgres option if MySQL was never a hard requirement. This is the biggest lift and only worth it if you were already leaning that way — don’t let a version deadline stampede you into a database migration you hadn’t planned.
My rough rule: if you can handle the breaking changes in the next few weeks, upgrade to 8.4 and be done. If you genuinely can’t touch the database before August, budget for Extended Support deliberately and set a real internal deadline to upgrade — don’t drift into year 3 pricing by accident.
Where to start this week
Pull a list of every RDS for MySQL 8.0 instance in your account (the RDS console flags versions approaching end of support, or query it with the CLI). For each one, note the vCPU count and whether it’s Multi-AZ — that’s your Extended Support exposure in plain numbers. Then run the prechecks on your most important database and see how much actually flags.
Odds are the upgrade is smaller than the bill you’d otherwise pay to avoid it. But you won’t know until you run the checks — so run them before the July 31 clock runs out.
Sources: