MySQL 8.0 has reached end of life: planning the move to 8.4

MySQL 8.0 reached the end of its community life in April 2026. Oracle has moved it to Sustaining Support, which means no new security patches or bug fixes from Oracle. If you run MySQL 8.0 yourself, any vulnerability found from now on stays open unless you upgrade. If you run it on a managed service, you may have a little longer, but probably at a price.

Many systems still run on 8.0 because it worked and nobody needed to touch it. This article covers what end of life means in practice, why MySQL 8.4 LTS is the usual target, what to check before upgrading, the managed service dates on AWS, and how to test and roll back safely.

What end of life means

Oracle’s end-of-life notice states that, as of 21 April 2026, MySQL 8.0 is covered under Oracle Sustaining Support and recommends upgrading to MySQL 8.4 LTS or 9.7 LTS. Your database will keep running. What stops is the supply of fixes.

The practical consequences build up over time:

• new vulnerabilities in 8.0 are not patched by Oracle;
• client libraries, drivers and tools gradually drop 8.0 from their test matrices;
• security questionnaires and audits start flagging an unsupported database;
• managed services move 8.0 to paid extended support, then retire it.

None of this forces an upgrade next week. It does mean the upgrade should be planned rather than left until a deadline or an incident makes the decision.

Why 8.4 LTS

MySQL now has two release tracks: Long-Term Support (LTS) releases, which receive fixes for years with few behaviour changes, and Innovation releases, which add features quickly and are supported briefly. MySQL 8.4 is the LTS release that follows 8.0, and both Amazon RDS for MySQL and Aurora MySQL offer it. For most production systems, 8.4 is the natural target. Even if you want 9.7 LTS eventually, MySQL’s upgrade rules do not allow an LTS series to be skipped, so 8.0 has to go to 8.4 first.

Breaking changes to check

8.4 removes a good deal that 8.0 only deprecated. Before upgrading, check at least these:

• mysql_native_password is disabled by default. Accounts that still use it will fail to authenticate unless you turn the plugin back on with mysql_native_password=ON. The better fix is moving those accounts to caching_sha2_password, but older client libraries and some third-party tools may not support it, so test every application and integration that connects.
• Removed server options and variables. default_authentication_plugin is gone (use authentication_policy), as is expire_logs_days (use binlog_expire_logs_seconds). Others removed include --skip-host-cache, --ssl and binlog_transaction_dependency_tracking. A server will not start if its configuration file names a removed option.
• Replication syntax. CHANGE MASTER TO, START SLAVE, SHOW SLAVE STATUS, SHOW MASTER STATUS and the MASTER_* options are removed in favour of the SOURCE and REPLICA forms. Scripts, monitoring checks and runbooks that use the old forms will break.
• Foreign keys on non-unique or partial keys are now restricted by default through restrict_fk_on_non_standard_key.
• Changed InnoDB defaults. Several defaults changed, including innodb_adaptive_hash_index (now off), innodb_change_buffering (now none) and innodb_io_capacity. Performance may shift even when nothing breaks.
• Removed tools. mysql_upgrade and mysqlpump are gone. Backup jobs that use mysqlpump need replacing.

Run MySQL Shell’s upgrade checker, util.checkForServerUpgrade(), against a copy of your database with 8.4 as the target. It reports errors that block the upgrade and warnings to review. Then read the full list of changes in the 8.4 manual: the checker cannot see your application code, cron jobs or deployment scripts.

Managed service timelines on AWS

Managed services set their own dates, separate from Oracle’s. On AWS, the dates published in the release calendars are:

• Amazon RDS for MySQL 8.0 reached end of standard support on 31 July 2026. Instances still on 8.0 are now on RDS Extended Support, a paid offering, with charges from 1 August 2026, a higher pricing tier from 1 August 2028 and the end of Extended Support on 31 July 2029.
• Amazon Aurora MySQL version 3, which is compatible with MySQL 8.0, remains in standard support until 30 April 2028. Extended Support pricing starts on 1 May 2028 and Extended Support ends on 31 July 2029. Aurora MySQL now offers a version compatible with MySQL 8.4.
• RDS for MySQL 8.4 has standard support until 31 July 2029.

If you are on RDS for MySQL 8.0, you are probably already paying Extended Support charges. Check your bill. If you run on another provider, look up its own calendar: the dates differ from AWS and from Oracle.

Test on a copy, then on a replica

Never let the production upgrade be the first time the upgrade runs.

1. Restore a recent snapshot to a new instance and upgrade that to 8.4. This shows whether the upgrade completes, how long it takes and what the checker missed.
2. Point a test environment at the upgraded copy and run your application’s test suite, your heaviest reports and your scheduled jobs. Compare query plans and timings for the slowest queries, because changed defaults and optimiser behaviour can alter them.
3. Set up an 8.4 replica of production, replicating from the 8.0 primary, and let it run with real write traffic for a while. Send some read-only traffic to it if you can. Problems with real data and real load show up here, not in tests.
4. Rehearse the cut-over on the copy, including connection string changes, application restarts and monitoring checks.

On RDS, blue/green deployments package much of this: a green copy is created and upgraded alongside production, kept in sync, and switched over when you are ready, with a short interruption at switchover.

Plan the rollback before you start

The MySQL manual is clear that an in-place downgrade from 8.4 to 8.0 is not supported. Going back means a logical dump and load, or replication, and is only supported for rollback, before new 8.4 features have been used on the data.

So the rollback plan has to exist before the cut-over:

• Keep the old 8.0 environment and, if you can, replicate from the new 8.4 primary back to it after switchover. AWS describes how to set this up after an RDS blue/green switchover. If something goes wrong, you can switch back without losing writes made since the upgrade.
• Agree a decision window, such as the first few days, during which rollback is possible and nobody uses 8.4-only features.
• Take a final backup immediately before cut-over and confirm it restores.
• Write down who decides to roll back and what would trigger it.

The trade-offs

Paying for extended support is a legitimate choice if a system is about to be retired or replaced, or if an upgrade carries more risk than the remaining exposure. It buys time, not safety, and the cost rises the longer you stay.

An upgrade is also a chance to fix what has built up around the database: old authentication methods, scripts using removed syntax, undocumented configuration. That work is often larger than the upgrade itself, and it is better done deliberately than discovered on the night.

When to bring in help

If you have MySQL 8.0 systems and are not sure what depends on them, or an upgrade that keeps being postponed because nobody is confident about rollback, an assessment against the 8.4 changes is a sensible first step. We can run the checks, test on copies and replicas, plan the cut-over and rollback, and write the runbook your team will use.

Sources

• MySQL: Product Support EOL Announcements
• MySQL 8.4 Reference Manual: What is new in MySQL 8.4 since MySQL 8.0
• MySQL 8.4 Reference Manual: Upgrade paths
• MySQL 8.4 Reference Manual: Downgrading MySQL
• MySQL Shell: Upgrade checker utility
• AWS: MySQL on Amazon RDS versions
• AWS: Release calendars for Amazon Aurora MySQL
• AWS Database Blog: Upgrading Amazon RDS for MySQL 8.0 to 8.4 with prechecks, blue/green and rollback