MySQL 8.0 is end of life: upgrading to MySQL 8.4 LTS

MySQL 8.0 had its last release in April 2026. Here's what changes in MySQL 8.4, how to check your database before upgrading, what your platform needs, and what it means if you're on AWS RDS.

As of 28 October 2026. Dates are from Oracle, MySQL's documentation and AWS's own pages, linked at the bottom.

In 30 seconds

What happened: "As of April 2026, with version 8.0.46, MySQL 8.0 reaches End of Life", in MySQL's own words. There are no more community releases, so no more security fixes.
On AWS RDS: standard support for MySQL 8.0 ended on 31 July 2026, and RDS Extended Support charges started on 1 August 2026. AWS doesn't upgrade the major version for you.
What to do: move to MySQL 8.4 LTS, supported until 2029 (premier) and 2032 (extended). Run MySQL's upgrade checker first: a few things that worked on 8.0 stop the 8.4 server from starting.

1. The dates

Version	Status
MySQL 8.0	End of life since April 2026 (last release 8.0.46)
MySQL 8.4 LTS	Premier support until April 2029, extended support until April 2032
MySQL 9.7 LTS	Premier support until April 2031, extended support until April 2034

MySQL 9.7 is the newer LTS, but MySQL doesn't let you skip an LTS series: from 8.0 the supported step is 8.4. Sites still on MySQL 5.7 need two steps, 5.7 → 8.0 → 8.4.

2. If you're on AWS RDS

MySQL 8.0 on RDS	Date
Community end of life	30 April 2026
RDS end of standard support	31 July 2026
RDS Extended Support charges start	1 August 2026
RDS Extended Support year-3 pricing starts	1 August 2028
RDS end of Extended Support	31 July 2029

AWS says MySQL 8.0 is "now only available under RDS Extended Support", and you pay for it from the day after standard support ends until you upgrade. Check the current rate on AWS's RDS for MySQL pricing page.
Major version upgrades "do not occur automatically; you must make a request to modify the DB instance". RDS supports going from 8.0 straight to 8.4.
AWS's own advice for testing: restore a snapshot to a new instance, upgrade that copy, and test your application against it before touching production.

3. What your platform needs

Platform	Database
WordPress	Recommends MySQL 8.0 or greater, or MariaDB 10.11 or greater
WooCommerce	MySQL 8.0 or greater, or MariaDB 10.6 or greater
Drupal 11	MySQL 8.0 or greater, or MariaDB 10.6 or greater
Magento 2.4.8 and 2.4.9	MySQL 8.4 (or MariaDB)
Magento 2.4.4 – 2.4.7	No MySQL after 8.0: Adobe recommends moving to MariaDB

WordPress, WooCommerce and Drupal ask for "8.0 or greater" and don't name 8.4 specifically, so test your own site on 8.4 before switching.
Magento is the exception: 2.4.4 to 2.4.7 don't support MySQL versions after 8.0, and Adobe "strongly recommends migrating your database servers to a compatible MariaDB version". Either move to MariaDB, or upgrade Magento to 2.4.8 or later first; see our Magento 2.4.6 guide.
MariaDB instead? Its long-term releases get three years of community binaries plus two of source fixes; 11.4 is supported until 29 May 2029. Note that MariaDB 10.6, the minimum for WooCommerce and Drupal 11, reached its community end of life on 6 July 2026.

4. What breaks going from 8.0 to 8.4

These are from MySQL's "What Is New in MySQL 8.4" and its upgrade prerequisites:

Old-style passwords: the mysql_native_password authentication plugin "is no longer enabled by default". Database users created with it can't log in until you move them to caching_sha2_password or switch the plugin back on with mysql_native_password=ON in your server configuration. Older apps and PHP setups are the usual victims.
Removed settings stop the server: default_authentication_plugin (now authentication_policy) and expire_logs_days (now binlog_expire_logs_seconds) are gone. Leave them in my.cnf and 8.4 won't start.
Replication commands renamed: CHANGE MASTER TO, SHOW MASTER STATUS, RESET MASTER and the SLAVE statements now give a syntax error. Their replacements are CHANGE REPLICATION SOURCE TO, SHOW BINARY LOG STATUS, RESET BINARY LOGS AND GTIDS and the REPLICA statements. Backup and replication scripts need updating.
Foreign keys on non-unique or partial keys: 8.4 rejects new ones by default. Existing ones survive the upgrade, and the server logs a warning naming each of them.
AUTO_INCREMENT on FLOAT or DOUBLE columns must be fixed before upgrading: "Otherwise, the upgrade fails."
Changed InnoDB defaults (adaptive hash index off, change buffering off, higher I/O capacity, O_DIRECT on Linux). Usually fine, but re-check a hand-tuned configuration and compare performance on staging.
Removed tools: mysql_upgrade (the server now upgrades itself when it starts), mysqlpump and mysql_ssl_rsa_setup.

5. Step by step

Update to the last 8.0 release (8.0.46) first. That's our recommendation; MySQL's docs don't require a minimum.
Run the upgrade checker from MySQL Shell 8.4: util.checkForServerUpgrade({"targetVersion":"8.4.0"}), and fix every error it reports.
Clean up the configuration file: remove the settings 8.4 no longer knows.
Take a full backup. There's no in-place way back: downgrading to 8.0 only works by dump-and-reload or replication, and only "for rollback purposes".
Upgrade a copy first, either in place (the 8.4 server converts the data directory when it starts) or by dumping and loading into a fresh 8.4 server.
Test your application: logins, checkout, imports, reports and anything with custom SQL.
Upgrade production at a quiet moment and watch the error log.

6. Tools that help

MySQL Shell upgrade checker (free, official): around 50 checks, including removed settings, authentication plugins, reserved words and the foreign-key and AUTO_INCREMENT problems above. It doesn't see your application code, and MySQL notes that "the server can be upgraded with warnings still present", so read the warnings, not just the errors.
MySQL Shell dump and load (util.dumpInstance() and util.loadDump(), free): faster parallel dumps for a dump-and-reload upgrade. mysqldump still works; mysqlpump is gone.
RDS snapshot restore (AWS): the cheapest way to get a realistic test copy if you're on RDS.