MySQL 8.0 End of Life and MySQL 5.7 EOL: Dates and Options

MySQL 8.0 reached end of life on 21 April 2026, when Oracle moved it to Sustaining Support. MySQL 5.7 reached end of life on 25 October 2023. Neither receives new bug fixes or security patches from Oracle, and Oracle's advice is to upgrade to MySQL 8.4 LTS or 9.7 LTS. The dates below are from Oracle's MySQL end-of-life notice and the MySQL reference manual, checked on 9 October 2026, with the AWS, Azure and Google Cloud schedules for managed MySQL.

MySQL end of life dates by version

Source: MySQL end of life notice. AWS and Azure publish slightly different community EOL dates in their own calendars: 30 April 2026 for 8.0 and 31 October 2023 for 5.7. Oracle's notice is the authoritative date. Sustaining Support under the Oracle Lifetime Support policy keeps technical support, the knowledge base and pre-existing fixes available to Enterprise customers, but no new software updates, security alerts or critical patch updates are produced. For MySQL Community Edition users, end of life simply means the security patches stop.

How MySQL's LTS and Innovation release model works

MySQL 8.0 was the last series released the old way: its patch releases also carried new features. With MySQL 8.1.0, the first Innovation release, 8.0.34 and later became bug-fix only until end of life, and MySQL now ships on two tracks. LTS releases, such as 8.4 and 9.7, follow the Oracle Lifetime Support policy with 5 years of Premier Support and 3 years of Extended Support. Features can be added or removed only in the first release of an LTS series, so later 8.4.x releases contain only necessary fixes. Innovation releases carry new features and behavior changes and are supported only until the next Innovation release. They are production quality, but they suit teams with heavy test automation and a fast upgrade cadence. For most production databases the choice is an LTS series.

The upgrade rules follow from that. You can upgrade from one LTS series to the next, 8.0 to 8.4 or 8.4 to 9.7, but you cannot skip an LTS series. From MySQL 5.7 there is no direct route to 8.4: the reference manual says to upgrade 5.7 to 8.0 first, then 8.0 to 8.4.

What the cloud providers do with MySQL 8.0 and 5.7

Every large cloud now keeps an EOL MySQL running for a fee, then upgrades it for you.

• Amazon RDS for MySQL. Standard support for 8.0 ended on 31 July 2026, and RDS Extended Support has been billed from 1 August 2026, per vCPU per hour, with a new rate from 1 August 2028. It ends on 31 July 2029. For 5.7, standard support ended on 29 February 2024 and Extended Support runs to 30 June 2029. AWS now offers 5.7 and 8.0 only under Extended Support. When it ends, RDS upgrades the database to a supported major version automatically.
• Amazon Aurora MySQL. Aurora MySQL version 3, which is MySQL 8.0 compatible, keeps standard support until 30 April 2028, then Extended Support to 31 July 2029. Aurora MySQL version 2 (5.7 compatible) left standard support on 31 October 2024.
• Azure Database for MySQL flexible server. Standard support for 5.7 ended on 30 September 2026 and paid extended support runs from 1 October 2026 to 31 March 2029. For 8.0, standard support lasts until 31 January 2027, with extended support from 1 February 2027 to 31 May 2029. Enrollment and billing are automatic; upgrading is the only way out.
• Google Cloud SQL for MySQL. MySQL 8.0 enters paid extended support on 1 January 2027 and is deprecated on 1 July 2029, after which Cloud SQL upgrades instances to the default major version, currently 8.4. MySQL 5.7 has been in extended support, billed since 1 May 2025, and is deprecated on 1 February 2028.
• Oracle MySQL HeatWave. Oracle extended support for MySQL 8.0 instances in HeatWave until April 2027, with essential security patches only.

Cloud extended support patches critical and high-severity CVEs. It does not tune your queries, and it is a bridge with a toll on it, not a destination.

Upgrading from MySQL 5.7 to 8.0: the gotchas

The 5.7 to 8.0 step is the large one. Run MySQL Shell's Upgrade Checker utility against a copy of production first; it reports most of the items below before they become outages.

• Authentication. caching_sha2_password became the default authentication plugin in 8.0, replacing mysql_native_password. Clients and connectors that do not know the plugin cannot connect to accounts that use it, and may have trouble connecting at all, so update drivers before the server.
• Character set. The server default changed from latin1 to utf8mb4, with utf8mb4_0900_ai_ci as the default collation. New objects created without an explicit character set and collation therefore differ from the ones you already have, which is worth settling deliberately rather than by accident.
• Query cache removed. The query cache, its query_cache_* variables and the SQL_CACHE modifier are gone. Remove those settings from my.cnf before the upgrade, and expect workloads that leaned on the cache to need better indexes or an application-side cache.
• Reserved words. Some keywords are reserved in 8.0 that were not in 5.7, so identifiers that used to be legal now need quoting. Queries that put ASC or DESC on a GROUP BY clause must be rewritten too.
• Data dictionary. 8.0 keeps metadata in a global data dictionary in transactional tables instead of metadata files. The upgrade is one way: downgrading from 8.0 to 5.7 is not supported, so the rollback plan is a backup taken before the upgrade.

Upgrading from MySQL 8.0 to 8.4 LTS

The 8.0 to 8.4 step is smaller, and you can do it in place, by logical dump and load, or through replication. The main trap is authentication again: from MySQL 8.4.0 the deprecated mysql_native_password plugin is no longer enabled by default. Accounts that still use it fail to log in unless you start the server with --mysql-native-password=ON, and that is a stopgap, not a fix. Move those accounts to caching_sha2_password and update the drivers. The safe pattern is the usual one: build an 8.4 replica, run real traffic against it, promote it, and keep the old source until you are sure. A replication lag problem on that replica is worth fixing before cutover, not after.

Options if you are still on MySQL 8.0 or 5.7

If you run self-managed MySQL Community, Oracle no longer patches 8.0 or 5.7, and the cloud options above only apply to managed services. Two things cover the gap while the upgrade is planned. OSSeva, AceMQ's extended support platform, ships signed patched builds of MySQL 5.7 and 8.0 Community Edition after Oracle stops fixing them, so the binaries and licence you run today stay in place. And you need people who know MySQL. AceMQ provides 24/7 MySQL support for Community, Enterprise, Percona Server and cloud-hosted MySQL on any version, covering incident response, performance and the upgrade path to 8.4 or 9.7. For how the support market works, Oracle, community, cloud and independent, see MySQL support options, and for how MySQL's support window compares with PostgreSQL and other databases, see support windows compared.

• MySQL: End of life notice
• Oracle: Lifetime Support Policy
• MySQL 8.4 Reference Manual: MySQL releases, Innovation and LTS
• MySQL 8.4 Reference Manual: Upgrade paths
• MySQL 8.4 Reference Manual: What is new in MySQL 8.4 since 8.0
• MySQL 8.0 Reference Manual: Changes in MySQL 8.0
• MySQL 8.0 Reference Manual: What is new in MySQL 8.0
• MySQL 8.0 Reference Manual: Downgrading MySQL
• MySQL blog: Introducing MySQL Innovation and LTS versions
• AWS: Amazon RDS for MySQL versions and release calendar
• AWS: Aurora MySQL release calendars
• AWS: Amazon RDS Extended Support
• Microsoft Learn: Azure Database for MySQL version policy
• Google Cloud: Extended support for Cloud SQL for MySQL
• Google Cloud: Database versions and version policies
• Oracle blog: Extending MySQL 8.0 support in MySQL HeatWave