What to do about the RDS MySQL 8.0 end of standard support email

If you run a MySQL database on Amazon RDS, an email with this subject line has probably been arriving in your inbox for months, with reminders every few weeks:

[Action Required] Amazon RDS MySQL 8.0 will reach end of standard support on July 31, 2026

The short version: nothing is going to break. Your database will keep running and keep receiving critical security fixes well past the date in the subject line. What changes on 1 August is that doing nothing stops being free - you'll either be paying Amazon's Extended Support charges by the hour, or AWS will pick a maintenance window and upgrade your database for you, on its schedule rather than yours. The answer is a planned major version upgrade: rehearsed on a copy of your data first, timed around your business, and checked afterwards. That's routine work when it's planned properly, and I've spent a good part of this year doing exactly that with clients. This is the process.

What the email actually means

MySQL 8.0 - the database engine underneath your RDS instance - reaches the end of its supported life with the MySQL community in April 2026, and AWS follows suit on 31 July. Extended Support is AWS's paid safety net: your 8.0 database keeps receiving critical security patches for up to three years past the community end of life, charged per vCPU per hour on top of your normal instance cost. The rate roughly doubles in later years, so it's priced to be a bridge, not a destination. If you never opted out, you're enrolled automatically and the charges start on 1 August 2026 regardless of which 8.0 minor version you're on.

If you did opt out, the alternative isn't the status quo: AWS will upgrade your instance to a newer major version for you, during a scheduled maintenance window, on their timetable. A major version upgrade performed without compatibility testing is not something I'd choose for a production database.

There's a quieter catch worth knowing too: from 1 August, restoring an 8.0 snapshot automatically lands the restored database on an Extended Support version, with the charges to match. You can't sidestep the billing by keeping old snapshots around.

Establishing the impact

The first job is building a picture of what's actually affected. That means an inventory of every RDS instance across every account - production, staging, the forgotten dev instance that's been quietly running since 2023 - because Extended Support bills each of them. Then, for each application on those databases, the compatibility question: does anything in the application depend on behaviour that changes between 8.0 and the target version? That's a question your developers or IT partner can answer against the release notes, and it's the difference between an upgrade that's a non-event and one that breaks something on a Tuesday morning.

The business questions matter as much as the technical ones. How much downtime can this system tolerate, and when? A few minutes at 2am is nothing for some businesses and unacceptable for others running around the clock. Where downtime is genuinely expensive, RDS Blue/Green Deployments can shrink it to a brief switchover by upgrading a synchronised copy alongside the live database - more moving parts, but minutes of impact rather than the length of the upgrade.

Planning the upgrade

The single most useful step is a rehearsal: restore a recent snapshot to a temporary instance and run the upgrade there. That tells you the two things the email can't - whether the upgrade succeeds cleanly against your actual data, and how long it really takes, which depends on the number of objects in the database rather than its size on disk. The rehearsal instance is also where the application gets pointed for compatibility testing before any production date is booked.

With the duration known, the timing becomes a business conversation rather than a guess: which maintenance window, on which day, avoiding month-end billing runs, seasonal peaks and anything else in the client's calendar. Then the communications - the client's own users and customers told what's happening and when, in their language rather than AWS's, with a rollback plan agreed in advance so nobody is inventing one at midnight.

Backing up, executing and reviewing

On the night, nothing is touched until there's a fresh snapshot to fall back on. The upgrade itself is the anticlimax if the rehearsal did its job - the instance restarts a few times, the version number changes, and the application comes back. The work that matters is afterwards: testing that the application behaves, watching the logs, and keeping an eye on performance over the following days for the problems that only show up under real use. Only then does the rehearsal instance get deleted and the job called done.

Done this way, the upgrades I've run this year have been non-events for the businesses involved - which is the point. The database version is not something a business should ever be excited about.

If the email is still in your inbox

Whether the deadline is days away or has already passed by the time you read this, the position is the same: the Extended Support window gives you up to three years, and the process above is a few weeks of calendar time and a modest amount of work for most systems - considerably less than years of per-vCPU charges. The same applies to the next round, because this cycle repeats: MySQL 8.4 and every version after it will get the same email eventually, and a business that treats database upgrades as part of the regular maintenance that keeps an application secure stops receiving frightening deadlines altogether. If you'd like a hand establishing what the email means for your systems and getting the upgrade done quietly, get in touch.

Also in this series: the Lambda Node.js 20 end-of-life email and the Elastic Beanstalk PHP 8.2 platform retirement email.