MySQL LTS vs Innovation releases: which version to run

For a production database in late 2026 the answer is an LTS release: MySQL 8.4 or MySQL 9.7. Both get bug and security fixes for years, neither changes behaviour inside its series, and either is a safe target for an application you want to leave alone. MySQL 8.0 is finished - its last release, 8.0.46, shipped in April 2026 and Oracle publishes no more fixes for it. Innovation releases (8.1 to 8.3, 9.0 to 9.6, and now the calendar-numbered 26.7) are production-quality but supported only until the next one, roughly three months, so running one means upgrading four times a year through releases that are allowed to remove things.

The rest of this guide explains the two tracks, the support dates that matter, the new calendar version numbers that started in July 2026, the upgrade paths you are and are not allowed to take, and how the version you actually get depends on where it comes from: your Linux distribution, Oracle's repositories, or a Docker tag that may move under you.

The two release tracks#

Until 8.0, MySQL had one long-lived series per major version, and new features landed in patch releases. 8.0.18 brought hash joins and EXPLAIN ANALYZE; 8.0.30 brought innodb_redo_log_capacity. Two servers both called "8.0" could behave quite differently. Starting with 8.1 in July 2023, Oracle split releases into two tracks.

Oracle's manual describes both tracks as "production-grade quality". The difference is not quality, it is change. An LTS series is frozen in behaviour: 8.4.1 to 8.4.11 contain fixes, not new features or different defaults. That freeze is also why in-place downgrades work inside an LTS series - the data format does not change, so you can step from 8.4.11 back to 8.4.10 if a patch misbehaves.

An Innovation release is the opposite. Each one may deprecate or remove features, change reserved words, change optimiser behaviour, and change defaults. The manual warns these changes "can have a big impact", especially on SQL syntax and query performance. Features removed during an Innovation cycle are removed for good in the LTS that closes it, which is why 8.0 to 8.4 broke more than the version number suggested - every removal from 8.1, 8.2 and 8.3 arrived at once. MySQL 8.4 LTS: what changed lists those.

The pattern so far: a run of Innovation releases, then an LTS that freezes the result.

Support dates that matter#

These are the dates to put in a calendar. Oracle's Lifetime Support Policy gives an LTS series five years of premier support and three of extended support, counted from its first GA release. For Community Edition users the practical meaning is simple: patch releases keep coming until the end of the window.

The 9.7 dates follow from the five-plus-three rule applied to an April 2026 GA; Oracle's lifetime support document is where to confirm the exact month. Either way, 8.4 is supported for years yet - there is no rush to leave it, and an application that moved to 8.4 in 2025 does not need to move again until the end of the decade.

On 8.0: "end of life" means no more fixes from Oracle, including for security vulnerabilities found after April 2026. Some distributions and cloud providers carry their own packages a while longer - Ubuntu 22.04 and 24.04 received 8.0.46 in June 2026, and Oracle extended 8.0 on its own HeatWave service to April 2027 - but those are the last patches of a line nobody is developing. A server still on 8.0 is the one to schedule first.

Calendar version numbers from 26.7#

In July 2026 MySQL changed its numbering. 9.7 is the last release line with sequential version numbers; everything after uses calendar versions in the form YY.M.P - two-digit year, release month, patch number. The July 2026 Innovation release is 26.7.0, and Oracle has named the following Innovation releases as 26.10, 27.1, 27.4 and 27.7.

Two things trip people up here.

First, the number no longer tells you the track. 26.7 is an Innovation release because Oracle says so, not because of its digits, and a future LTS will also have a calendar number. Always check the release notes or the repository you installed from rather than inferring from the version string. On a running server:

SELECT @@version, @@version_comment;

@@version_comment shows the build, for example MySQL Community Server - GPL; distribution builds add their own text.

Second, the patch numbers inside an LTS series now follow the quarterly security cycle. Each quarterly Critical Patch Update (CPU) bumps the third number: 8.4.11, then 8.4.12. If a serious vulnerability needs a fix between quarters, Oracle issues a targeted patch (CSPU) with a fourth number - 8.4.11.1, 8.4.11.2 - and the next quarterly release goes back to three numbers. On Innovation releases the third number stays at 0, because the fix for a quarter is simply the next Innovation release. Windows MSI packages encode four-part versions differently (8.4.11.1 shows as 8.4.1101 in installer metadata), which is cosmetic.

Scripts that parse mysql --version or SELECT VERSION() and assume a single-digit major version will misread 26.7.0. Compare versions numerically per component, not as strings, and check monitoring dashboards and Ansible or Puppet facts that branch on "major version 8 or 9".

Upgrade and downgrade paths#

The track model comes with strict rules about which jumps the server supports in place. The short version: LTS to the next LTS, never skipping one.

The rules, as the reference manual states them:

• Within an LTS series, upgrades and downgrades in place are both supported. 8.4.3 to 8.4.11 and back is fine.
• From one LTS to the next, an in-place upgrade is supported: 8.4.x to 9.7.x. Skipping an LTS is not - you cannot go from 8.4 straight to whatever LTS follows 9.7.
• An Innovation release upgrades in place to a later Innovation release in the same cycle, or into the LTS that closes it: 9.1 to 9.2, or 9.5 to 9.7.
• An Innovation release cannot cross into the next cycle directly. 8.3 goes to 9.0 through 8.4.
• Only 9.7 LTS can upgrade in place into the first calendar-versioned cycle that 26.7 starts.
• Downgrading an Innovation release always needs a logical dump and load.

8.0 sits before the model, but the same principle applies: 8.0 to 8.4 in place is supported from a recent 8.0 patch; 8.0 to 9.7 goes through 8.4. 5.7 has to reach 8.0 first.

A logical dump and load sidesteps most of this. A mysqldump or MySQL Shell dump from 8.0 or 8.4 loads into 9.7 in nearly all cases, because it is just SQL; what can fail is the content - accounts on removed authentication plugins, reserved words used as identifiers, definers that do not exist. That is also the route on any hosted database, where you cannot swap binaries on the provider's server. mysqldump backup and restore covers the flags, and migrating MySQL to a new host the cut-over.

Before any jump, run MySQL Shell's upgrade checker against the old server with the target version you intend:

$ mysqlsh root@db.example.com:3306 -- util check-for-server-upgrade \    --target-version=9.7.2

Use a MySQL Shell at least as new as the target, since the checker only knows about versions released before it.

Which version to run in production#

For most people the decision is between the two supported LTS series.

Stay on or move to 8.4 if your application already works on it, if your hosting provider offers it, or if your ORM, driver or tooling has not caught up with 9.x. 8.4 has premier support until 2029; nothing forces a move before then. It is also the conservative target from 8.0, because 8.0 to 8.4 is the well-trodden path and 8.4 still lets you switch mysql_native_password back on as a stopgap.

Choose 9.7 for a new project with no history, or if you want what arrived in 9.0 to 9.6: the VECTOR data type, newer optimiser work, and several features Oracle moved from Enterprise into Community Edition with 9.7, including replication applier metrics and Group Replication flow-control statistics. Know the cost: mysql_native_password was removed entirely in 9.0, so any account or client still depending on it fails with no switch to turn it back on. Every driver must speak caching_sha2_password.

Use an Innovation release for testing, for development environments that track what is coming, or if you have a specific feature you need now and a team prepared to upgrade every quarter. Running 26.x in production is legitimate - Oracle supports it - but only if someone owns that quarterly upgrade and the application's test suite runs against each new release.

A rule of thumb that holds up: production on an LTS, one staging or CI database on the newest Innovation release. When the next LTS arrives, the Innovation-era removals have already shown up in CI, and the production upgrade is planned rather than discovered.

Distribution packages#

What apt install mysql-server or dnf install mysql-server gives you depends on the distribution release, not on what Oracle currently recommends. Distributions pick a version when they freeze and carry it for the life of the release.

On Ubuntu 24.04 the mysql-server package is still mysql-server-8.0. Ubuntu shipped 8.0.46 to it in June 2026, but there is no 8.0.47 coming from Oracle, so an Ubuntu 24.04 server running the distribution's MySQL is on a line that has stopped. The fixes are to upgrade the operating system to 26.04, or install 8.4 from Oracle's repository.

Debian deserves a note because it surprises people: apt install default-mysql-server on Debian installs MariaDB, and the mysql command is MariaDB's client. MariaDB forked from MySQL 5.5 and has diverged since - it is not a MySQL version, has its own release and support schedule, and does not read a MySQL 8.4 data directory. If you need MySQL itself on Debian, it comes from Oracle's APT repository or Docker.

To see what you have on any of them:

$ mysqld --version$ apt-cache policy mysql-server      # Debian and Ubuntu$ dnf info mysql-server              # RHEL family

Oracle's own repositories#

Oracle publishes APT and Yum repositories at repo.mysql.com, and these are where the track is chosen explicitly. The repository setup package (mysql-apt-config on Debian and Ubuntu, mysql84-community-release and similar on the RHEL family) installs a configuration in which you pick one series: an 8.4 LTS repository, a 9.7 LTS repository, or the Innovation repository.

On the Yum side each track is a separately named repository, and you enable exactly one. The manual's example uses mysql-innovation-community for Innovation and mysql-9.7-lts-community for 9.7 LTS:

$ dnf repolist all | grep mysql$ sudo dnf config-manager --disable mysql-innovation-community$ sudo dnf config-manager --enable mysql-9.7-lts-community

On Debian and Ubuntu the choice is made in a dialog when mysql-apt-config is installed, and can be changed later:

$ sudo dpkg-reconfigure mysql-apt-config$ sudo apt update

The point of picking a track rather than a version is what happens on apt upgrade. An LTS repository moves you from 8.4.10 to 8.4.11 and never to 9.7. The Innovation repository moves you from one Innovation release to the next, which is what Innovation means, and an unattended-upgrades job pointed at it will do a feature upgrade of your database whenever Oracle ships one. On a production server, enable an LTS repository and nothing else. Also check that Oracle publishes a repository for your distribution release before relying on it - new distribution releases are sometimes added months after they ship.

Docker image tags#

The official mysql image on Docker Hub maps tags to tracks, and some of those tags move. As of October 2026 the supported tags are:

Each has -oracle or -oraclelinux9 variants; all current images are built on Oracle Linux 9. The Debian-based image variants belonged to 8.0 and are gone with it, and mysql:8.0 is no longer in the supported list - the tag still pulls, but nothing will rebuild it.

Three tags cause most of the accidents.

latest is an Innovation release. A Compose file with image: mysql or image: mysql:latest will, on the next docker compose pull, upgrade the database to whatever Innovation release is current - and since Innovation downgrades need a dump and load, there is no stepping back by changing the tag.

lts moved. Until 9.7 shipped in April 2026, mysql:lts was 8.4. Anyone who pinned to lts thinking it meant "stable" got an in-place upgrade from 8.4 to 9.7 on their next pull - a supported upgrade, but one that removed mysql_native_password and could not be reversed by retagging. lts will move again when the next LTS arrives.

8 moved too. It pointed at 8.0 during 8.0's life and now points at 8.4.

The safe pattern is to pin to the series you have chosen, and let patches arrive:

services:  db:    image: mysql:8.4    environment:      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/mysql_root      MYSQL_DATABASE: app    volumes:      - db-data:/var/lib/mysql

mysql:8.4 takes 8.4 patches and never jumps series. If you want each patch to be a decision as well, pin the full version (mysql:8.4.11) and bump it yourself. In both cases, the data directory in the volume is what carries the version forward: a container started from a newer series upgrades it on first start, and an older series refuses to start on it. Docker Compose for small stacks covers volumes and secrets in more depth.

Checking and planning your version#

A short audit for any MySQL you are responsible for:

1. Find the exact version with SELECT @@version; and where it came from: distribution package, Oracle repository, Docker tag, or a hosting provider.
2. Map it to a track and a support date using the tables above. Anything on 8.0, 5.7, or an Innovation release that is not the latest one is unsupported now.
3. Check how it updates. A distribution package follows the distribution; an Oracle repository follows the track you enabled; a Docker tag follows whatever the tag points to; a hosted database follows the provider.
4. If you need to move, choose the target LTS, run the upgrade checker, move authentication off mysql_native_password (see MySQL users and privileges), and rehearse on a copy.
5. Put the end-of-support date for the series you land on in a calendar, a year ahead of when it falls.

FAQ#

Is MySQL 9.7 an LTS release?

Yes. MySQL 9.7.0 shipped in April 2026 as the second LTS series after 8.4, and it closes the 9.x Innovation cycle that began with 9.0. It is also the last release line with sequential version numbers; later releases use calendar versions such as 26.7.

Is it safe to run an Innovation release in production?

Oracle supports it and calls it production quality, so it is not reckless. The catch is the support window: each Innovation release is patched only until the next one, so staying supported means a feature upgrade roughly every three months, each of which may remove something. Without the time to test each one, use an LTS.

Can I upgrade from MySQL 8.0 directly to 9.7?

Not in place. The supported in-place route is 8.0 to 8.4, then 8.4 to 9.7. A logical dump from 8.0 loaded into a fresh 9.7 server usually works, provided no accounts depend on mysql_native_password and the upgrade checker reports nothing serious.

What does mysql:latest give me in Docker?

The current Innovation release - 26.7 as of October 2026. It changes every quarter. For a database you care about, pin to mysql:8.4 or mysql:9.7, not latest and not lts, since lts will move to the next LTS when it ships.

Do I have to leave MySQL 8.4 for 9.7?

No. 8.4 has premier support until April 2029 and extended support until April 2032, and it keeps getting quarterly patch releases. Moving to 9.7 is worth planning before 2029, but there is no deadline before then.

Is MariaDB a version of MySQL?

No. MariaDB began as a fork of MySQL 5.5 and is now a separate database with its own versions and support schedule. Debian installs it when you ask for default-mysql-server. It speaks the same protocol for most clients, but its data files and newer features are not interchangeable with MySQL 8.4 or 9.7.