MySQL End-of-Life Dates —
Official EOL Schedule for Every Version

MySQL 8.0 reached end of life on April 30, 2026. That is the date that matters most right now, because 8.0 has been the default MySQL release since 2018 — the version sitting underneath an enormous share of the world's production databases. The moment it went unsupported, every one of those installs stopped receiving security patches from Oracle. If you are running mysql:8.0 anywhere, you are now on borrowed time.

MySQL 5.7 has been past EOL since October 2023 and is still everywhere. And the release model changed with the introduction of Innovation and LTS tracks — which is the single most misunderstood thing about MySQL versioning today, and the reason many teams are running a "newer" version that is actually less supported than the LTS they skipped.

This page is the single reference for MySQL end-of-life dates across every version — with EOL Risk Scores™, the Innovation vs LTS model explained, and a plain-English upgrade guide.

Complete MySQL EOL Schedule

The versions below are the ones that actually appear in production. MySQL 8.0 and the 5.x series predate the current release model; MySQL 8.4 is the first LTS release under the new model and the recommended migration target. The short-lived Innovation releases (8.1, 8.2, 8.3, and the 9.x series) are covered separately below.

Innovation vs LTS Releases — What Changed

Starting in 2023, Oracle split MySQL into two release tracks, and understanding the difference is essential for EOL planning. The version number alone no longer tells you how long a release is supported.

LTS (Long-Term Support) releases — currently MySQL 8.4, with a new LTS roughly every two years — receive around eight years of support (premier plus extended). These are the versions you should run in production. MySQL 8.4, released April 2024, is supported through April 2032.

Innovation releases — MySQL 8.1, 8.2, 8.3, and the entire 9.x series — ship on a quarterly cadence with new features, but each one is supported only until the next release arrives, a window of roughly three months. They are intended for teams that want early access to new functionality and are prepared to upgrade every quarter. Running an Innovation release in a database you don't upgrade quarterly is a trap: MySQL 9.2 looks newer than 8.4, but 8.4 is supported into 2032 while 9.2 went EOL within months of release.

MySQL 8.0 — EOL April 30, 2026

MySQL 5.7 — Long Past EOL, Still Everywhere

MySQL 8.4 LTS — Supported Until 2032

MySQL 9.x Innovation — Months, Not Years

The MySQL 9.x series (9.0 through 9.7 and counting) is the Innovation track. Each release ships quarterly with new features and is supported only until the following release lands. In practice that means a support window of around three months per version. MySQL 9.0 reached EOL in October 2024; 9.1, 9.2, 9.3, 9.4, 9.5, and 9.6 followed in turn, each superseded by the next.

These releases exist so teams can preview where MySQL is heading and test upcoming features early. They are not meant for long-lived production databases. If you adopt an Innovation release, you are signing up to upgrade every quarter, indefinitely — the moment you stop, you are running unsupported software with a Critical-tier risk profile. Unless that quarterly cadence is genuinely part of your operating model, stay on 8.4 LTS and let the Innovation features arrive in the next LTS.

MySQL vs MariaDB — EOL Implications

MariaDB began as a MySQL fork in 2009 after Oracle's acquisition of MySQL, and the two have diverged substantially since. Many teams run one on infrastructure originally provisioned for the other, so the MySQL vs MariaDB EOL question comes up constantly in upgrade planning. See the full MariaDB EOL guide for that side of the picture.

They are not interchangeable at EOL. A MySQL 8.0 EOL date tells you nothing about MariaDB 10.6, and vice versa. Different release schedules, different LTS policies, different vendor support structures. If your documentation says "MySQL compatible" but you are actually running MariaDB, you need to track MariaDB dates specifically — and the reverse.

Switching engines at EOL is a migration, not an upgrade. Treating a MySQL-to-MariaDB swap (or the reverse) as a quick fix for an EOL deadline is high risk. Authentication plugins, JSON handling, system tables, replication formats, and optimizer behavior all differ in ways that surface under production load. Plan it as a full database migration project with its own testing cycle.

Managed MySQL has its own EOL schedule. Amazon RDS for MySQL, Aurora MySQL, Azure Database for MySQL, and Google Cloud SQL each track community EOL dates differently — some extend support past Oracle's community dates, some don't. If you run managed MySQL, confirm your provider's specific dates with the EOL Checker rather than assuming they match Oracle's.

How to Upgrade Safely

• 01
  Confirm your current version and release type Run SELECT VERSION(); on your database. Cross-reference against the table above and confirm whether you are on a legacy series (5.x, 8.0), the current LTS (8.4), or an Innovation release (8.1–8.3, 9.x). An Innovation release that looks "newer" than 8.4 may already be EOL.
• 02
  Target MySQL 8.4 LTS For nearly every production system, 8.4 LTS is the destination. From 8.0 it is a supported in-place upgrade. From 5.7 it is a larger project — validate through 8.0 as a compatibility checkpoint, then move to 8.4. Avoid landing on an Innovation release unless quarterly upgrades are part of your operating model.
• 03
  Run the upgrade check before you commit Use mysqlsh (MySQL Shell) util.checkForServerUpgrade() against a staging copy to surface incompatibilities — deprecated syntax, removed features, character-set and collation changes, and reserved-word conflicts. Resolve every flagged item in staging first.
• 04
  Watch authentication and SQL mode changes The default authentication plugin and several SQL mode defaults shifted across 5.7 → 8.0 → 8.4. Applications using older client libraries or relying on mysql_native_password may need driver updates or connection-string changes. Test application logins explicitly, not just server startup.
• 05
  Upgrade replicas first and back up before every step In a replication topology, upgrade replicas before the primary and keep the mixed-version window short. Take a full, tested backup (mysqldump or a snapshot) before each stage and confirm it restores. This step gets skipped under deadline pressure — don't.
• 06
  Consider extended support only as a bridge Oracle offers paid Extended Support for some versions past their community EOL, and third-party vendors provide security patches for legacy MySQL. Treat either as a bridge that buys migration time — not a destination. Run your 8.4 migration in parallel rather than letting paid support become a reason to defer it indefinitely.