MySQL End of Life

MySQL 8.0 end of life: upgrade to 8.4 LTS or migrate to MariaDB?

Oracle stopped maintaining MySQL 8.0 on April 30, 2026. It will get no more community security fixes. Here are the official dates, the realistic options, what breaks when moving to 8.4 LTS, and when MariaDB is the better choice.

Audit my database before migrating 15-min scoping

The dates that matter

Sources: MySQL documentation, Amazon RDS and endoflife.date, checked September 28, 2026.

Version	Released	End of support	Status
MySQL 8.0	April 2018	April 30, 2026 (last release: 8.0.46)	End of life
MySQL 8.4 LTS	April 30, 2024	April 30, 2029 (Premier), then Extended Support	Supported
MySQL 9.7 LTS	April 21, 2026	5 years Premier + 3 years Extended	Supported (current LTS)
Innovation (26.x)	Quarterly, e.g. 26.7 on July 28, 2026	Until the next Innovation or LTS release	Short-lived
Amazon RDS for MySQL 8.0	—	Standard support ended July 31, 2026; paid Extended Support until July 31, 2029	Paid extension

endoflife.date/mysql · Amazon RDS for MySQL versions · MySQL Releases: Innovation and LTS

What "end of life" actually changes

Oracle no longer ships 8.0 releases: 8.0.46 (April 2026) is the last one. Vulnerabilities found after that date won't be fixed in the community edition. This isn't theoretical: the 8.0 build Amazon RDS maintains under Extended Support, released in September 2026, lists more than 30 CVE fixes on its own. On a self-hosted 8.0 server, those fixes don't arrive unless you buy post-EOL support from a third party (Percona offers one).

Your database keeps running; nothing stops on the day. The risk lies elsewhere: compliance (security audits, NIS2, customer requirements), distro packages disappearing, and an upgrade that gets heavier as the gap widens.

On Amazon RDS, standard support for MySQL 8.0 ended on July 31, 2026: instances still on 8.0 move to RDS Extended Support, billed on top, until July 31, 2029 at the latest. Pricing goes up in year three (from August 1, 2028). It's an extension, not a solution.

LTS, Innovation, and the new version numbers

Since 2023, MySQL has followed two tracks. LTS releases (8.4, then 9.7) get 5 years of Premier and 3 years of Extended Support, and only receive fixes: nothing is removed within a series. Innovation releases ship every quarter and are supported only until the next one.

After 9.7 LTS, MySQL switched to calendar versioning: 26.7 (July 2026) is an Innovation release, not an LTS. For production, the two sensible targets are therefore 8.4 and 9.7.

Key point: an LTS series can't be skipped. From 8.0, the supported path is 8.0 → 8.4, then 8.4 → 9.7 if you want to go further. No direct 8.0 → 9.7.

Your options, straight talk

No option is free. The right one depends on your application, not on a vendor preference.

Option	Pros	Cons	Best for
Stay on 8.0	No project, no change	No more Oracle community security fixes; every new CVE stays open	Only as a short, documented transition
Paid extended support (RDS, or third parties such as Percona for self-hosted)	Buys time, security backports continue	Recurring cost, the upgrade is only postponed	Upgrade already scheduled but not ready
MySQL 8.4 LTS	Direct supported path from 8.0, supported until 2029, no removals within the series	Breaking changes to handle (auth, replication syntax, defaults)	Most MySQL 8.0 estates: the lowest-risk path
MySQL 9.7 LTS	Longest support horizon	Requires going through 8.4 first (LTS series can't be skipped)	Teams ready for two hops, or planning 8.4 then 9.7
Innovation releases (26.x)	Latest features	Supported only until the next Innovation or LTS release	Test and dev, rarely production
Percona Server for MySQL 8.4	MySQL-compatible, open source extras	Same 8.0 → 8.4 breaking changes	Teams wanting MySQL compatibility with a different vendor
MariaDB (11.8 / 12.3 LTS)	Open source, Galera built in, no Oracle dependency	Not a drop-in for MySQL 8: logical migration, JSON, GTID, accounts	When leaving Oracle's roadmap is a goal in itself

8.0 → 8.4: what actually breaks

8.4 was the first LTS, so it's where Oracle cleaned house. The official list is long; here are the points to check first.

Authentication: mysql_native_password is no longer enabled by default in 8.4 (re-enable with mysql_native_password=ON) and is gone in 9.x. Old PHP, Java or Python connectors that don't handle caching_sha2_password can't authenticate against accounts using it; re-enabling mysql_native_password is only a stopgap.
Replication syntax: CHANGE MASTER TO, SHOW SLAVE STATUS, START SLAVE, RESET MASTER, SHOW MASTER STATUS and the MASTER_* keywords are removed. Replace them with CHANGE REPLICATION SOURCE TO, SHOW REPLICA STATUS, START REPLICA, RESET BINARY LOGS AND GTIDS, SHOW BINARY LOG STATUS. Scripts, monitoring and failover tools are affected.
Removed variables: expire_logs_days (→ binlog_expire_logs_seconds), default_authentication_plugin (→ authentication_policy), binlog_transaction_dependency_tracking. A my.cnf that still sets them stops the server from starting.
Changed InnoDB defaults: innodb_adaptive_hash_index goes OFF, innodb_change_buffering to none, innodb_io_capacity from 200 to 10000, innodb_flush_method to O_DIRECT where supported (fsync otherwise). Performance can shift either way: measure.
Misc: FLUSH HOSTS removed, --skip-host-cache and --ssl dropped, keyring_file, keyring_encrypted_file and keyring_oci plugins replaced by their components.

What about MariaDB?

MariaDB is no longer a drop-in replacement for MySQL 8. The two projects have diverged, and MariaDB's own documentation lists the hard parts:

No in-place migration: MySQL 8 replaced .frm files with a data dictionary MariaDB can't read. Migration goes through a logical dump (see mariadb-dump vs mydumper) or replication.
JSON: binary in MySQL, an alias of LONGTEXT in MariaDB. JSON functions are close, but the -> and ->> operators, very common in MySQL code, don't exist in current MariaDB LTS releases (they arrive with 13.1): rewrite them with JSON_EXTRACT() / JSON_UNQUOTE(). Generated columns and indexes on JSON also need checking.
MySQL 8 → MariaDB replication: GTIDs are incompatible, so it runs on binlog positions, and only since MariaDB 10.6.21, 10.11.11 and 11.4.5, with three conditions on the MySQL side: JSON columns converted to TEXT, binlog_row_value_options='' and binlog_transaction_compression=0. With a lot of JSON, plan a dump-based cutover instead.
Passwords: since MariaDB 11.4.9 and 11.8.4, the caching_sha2_password plugin (library auth_mysql_sha2, which must be loaded: it isn't installed by default) lets you recreate accounts from their existing MySQL hash, without changing passwords. MariaDB presents it as a migration aid and recommends moving to PARSEC afterwards. Beware: the hash contains non-printable characters and can't be copied from a terminal.

MariaDB makes sense when you want to leave Oracle's roadmap, use built-in Galera Cluster, or consolidate on an engine already in your estate. The recommended LTS releases for a new deployment are 11.8 and 12.3 (12.3 has three years of community support, until June 2029); 10.11 and 11.4 are still maintained. If your only goal is to get back under support, 8.4 LTS is simpler: same engine, same tooling.

Upgrade checklist

1Inventory versions, sizes, replication topologies, connectors and client library versions.
2Run MySQL Shell's Upgrade Checker (util.checkForServerUpgrade()) against every server, with targetVersion set to 8.4 and configPath pointing to my.cnf. It doesn't catch everything: it doesn't replace application testing.
3Clean removed variables out of my.cnf and explicitly decide on the new InnoDB defaults.
4List accounts still on mysql_native_password and test application connectors with caching_sha2_password.
5Rewrite scripts, monitoring and failover tooling that use MASTER / SLAVE syntax.
6Build an 8.4 replica of an 8.0 primary, run it under real load, compare query times.
7Full backup, restore-tested, right before cutover, and a written rollback plan.
8Cut over by promoting the 8.4 replica rather than upgrading in place, when the topology allows: the downtime window is shorter.

What we support

We handle MySQL 5.7, 8.0 and 8.4 upgrades on standalone servers and classic replication, as well as MySQL to MariaDB migrations. MySQL InnoDB Cluster and Group Replication are outside our scope.

Before choosing between 8.4 and MariaDB, the MySQL / MariaDB audit reviews schema, connectors, replication and queries, to cost both paths on your database rather than on generalities. Once migrated, Remote DBA takes over minor updates.

Frequently asked questions

When did MySQL 8.0 reach end of life?

On April 30, 2026. The last community release is 8.0.46, published in April 2026. On Amazon RDS, standard support ended on July 31, 2026, with paid Extended Support available until July 31, 2029.

Can I upgrade directly from MySQL 8.0 to 9.7?

No. An LTS series can't be skipped: go from 8.0 to 8.4, then from 8.4 to 9.7. 26.7 is an Innovation release, supported only until the next Innovation or LTS release.

Will my application break on 8.4?

The first things to check are authentication (mysql_native_password disabled by default), removed MASTER/SLAVE replication syntax and variables dropped from my.cnf. MySQL Shell's Upgrade Checker and an 8.4 replica under real load surface most of them before cutover, without replacing application testing.

Is MariaDB compatible with MySQL 8?

Largely at the SQL level, but not at the file level: no in-place migration, JSON stored differently, incompatible GTIDs, accounts to recreate (passwords can be kept since MariaDB 11.4.9 / 11.8.4). Moving to MariaDB is a real project, mostly justified if you want to leave the Oracle ecosystem.

Still running MySQL 8.0 in production?

We inventory your estate, cost the move to 8.4 and the MariaDB option, and prepare a cutover with a rollback path.

See the audit 15-min scoping

Start your managed MariaDB project

Let's discuss your database needs. Our DBA team advises you on the optimal architecture for your use case.

Discovery Call15 min with a DBA expert 01 77 62 42 42Call us directly Emailcontact@rdem-systems.com

RDEM Systems SAS — SIREN 820 338 671 — 5 B rue des Noyers, 95300 Pontoise