MySQL 8.4 LTS, 9.7 LTS or 26.7 Innovation: choosing a version and upgrading

MySQL's version numbers changed meaning twice in three years. First Oracle split releases into Long-Term Support (LTS) and Innovation tracks, with 8.4 as the first LTS. Then, after 9.7, it moved to calendar versions: the July 2026 release is MySQL 26.7, not 9.8. If you run an application on MySQL 8.0 or 8.4 and are wondering what to upgrade to, and how, the version list on the downloads page is no longer self-explanatory.

This article compares the release lines available in October 2026, recommends which one most application teams should run, and gives a step-by-step checklist for upgrading from 8.4 LTS to 9.7 LTS, including the changes most likely to break an application. All facts come from Oracle's MySQL downloads page, release notes and the MySQL 9.7 Reference Manual, checked on 7 October 2026.

How MySQL releases work now

The MySQL 9.7 manual describes two tracks, and states that all LTS and Innovation releases include bug and security fixes and are considered production-grade quality.

• LTS releases follow Oracle's Lifetime Support policy: five years of premier support and three years of extended support. Within an LTS series there are only necessary fixes and no removals; features can be added or removed only in the first release of the series (such as 8.4.0). Because functionality and data format stay the same, in-place upgrades and downgrades work within the series.
• Innovation releases are supported only until the next Innovation release. They bring new features early, and behaviour changes, removals and refactoring are expected between them.

The manual also explains the new numbering: MySQL 9.7 is the final release line using sequential versions. Later releases use calendar versioning in a YY.M format, where 26.7 is the July 2026 release and 27.7 would be July 2027. An LTS release keeps its YY.M number for its whole support life.

The release lines available today

Series	Track	Latest in release notes	Suits
8.0	Bugfix series (pre-LTS model)	8.0.46, 21 April 2026	Legacy systems only; plan to move to 8.4
8.4	LTS	8.4.12, 18 August 2026	Applications that value stability and a long support window
9.7	LTS (9.7.0 released 21 April 2026)	9.7.3, 18 August 2026	New projects and teams ready for a planned LTS-to-LTS upgrade
26.7	Innovation (26.7.0 released 28 July 2026)	26.7.1, 18 August 2026	Teams that want the newest features and can upgrade every release

When we checked, the downloads page offered 26.7.0 as the Innovation release and 9.7.2 and 8.4.11 as LTS builds, slightly behind the newest release notes, so confirm the exact build available for your platform before you plan.

Which version should you run?

For most application teams, the answer is an LTS release. You get security fixes for years without behaviour changes, and you plan one larger upgrade every LTS cycle instead of a small one every quarter.

• New project in late 2026: start on 9.7 LTS. It is the newer LTS, so its support window runs longest, and it avoids a 8.4-to-9.7 upgrade later.
• Existing 8.4 LTS application: there is no urgency, but schedule the move to 9.7 LTS within your next year of planned work, so you are not upgrading under deadline pressure.
• Still on 8.0: upgrade to 8.4 LTS first. The upgrade-path table does not allow skipping a bugfix or LTS series, so 8.0 cannot go straight to 9.7.
• Innovation releases make sense for development and test environments that want early sight of new features, or for teams with automated upgrade pipelines. Remember that an Innovation release stops receiving fixes as soon as the next one ships.

If you use a managed service (Amazon RDS, Google Cloud SQL, Azure Database for MySQL, DigitalOcean and others), check which major versions your provider offers and its own end-of-support dates; they set their own schedules.

Supported upgrade and downgrade paths

The 9.7 manual lists these paths:

From	To	Supported?	Methods
8.4.x LTS	later 8.4.x	Yes	In-place, dump and load, replication, MySQL Clone
8.0.x	8.4.x LTS	Yes	In-place, dump and load, replication
8.4.x LTS	9.7.x LTS	Yes (next LTS)	In-place, dump and load, replication
8.0.x	9.7.x	No: go through 8.4 first	—
8.4.x LTS	a later LTS, skipping 9.7	No	—
5.7	8.4	No: go 5.7 to 8.0, then 8.0 to 8.4	—

Downgrades are more restricted. Within an LTS series, in-place downgrade works. Going back from an LTS series to the previous one (for example 9.7 to 8.4) is supported only by logical dump and load or replication, and only for rollback purposes, meaning no new server functionality has been applied to the data. In practice, your rollback plan for an 8.4-to-9.7 upgrade is a backup or a still-running 8.4 replica, not an in-place downgrade.

Changes most likely to affect your application

Read the "What Is New" pages and release notes for every version between yours and the target. For a typical web application moving from 8.4 to 9.7, these are the items to check first:

• mysql_native_password is gone from the server. It was deprecated in 8.0.34, disabled by default in 8.4 and removed in 9.0.0, along with the default_authentication_plugin variable. Accounts still using it cannot log in after the upgrade. Migrate them to caching_sha2_password (the default) while still on 8.4, and confirm your drivers support it.
• Mixed-engine transactions warn. Since 9.0.0, a transaction that updates both InnoDB and a non-transactional table such as MyISAM writes a deprecation warning.
• IGNORE no longer hides multi-row scalar subqueries. Since 9.0.0, an INSERT, UPDATE or DELETE ... IGNORE containing a scalar subquery that returns more than one row raises an error instead of being silently ignored.
• binlog_format is deprecated. Row-based logging is the default and the only format the manual recommends for new replication setups.
• Removed variables. 9.7 removes replica_parallel_type and group_replication_allow_local_lower_version_join; a configuration file that sets a removed variable stops the server starting.
• Changed defaults. 9.7 changes the default of innodb_log_writer_threads (now dependent on binary logging and CPU count) and raises binlog_transaction_dependency_history_size. Neither should break an application, but note them for performance comparisons.

9.7 also brings features into the Community edition that were previously Enterprise-only, including the hypergraph optimizer (off unless enabled through optimizer_switch) and DML on JSON duality views. Treat these as opportunities to evaluate after the upgrade, not part of it.

Upgrade checklist: 8.4 LTS to 9.7 LTS

Prepare

1. Upgrade to the latest 8.4.x first; in-place upgrades within the LTS series are low risk.
2. Install the current MySQL Shell and run the upgrade checker against production (it needs the PROCESS and SELECT privileges): mysqlsh -- util check-for-server-upgrade { --user=admin --host=db1 --port=3306 } --target-version=9.7.3 --output-format=JSON --config-path=/etc/mysql/my.cnf. Fix every error and review every warning.
3. List accounts still on the old plugin and migrate them: SELECT user, host FROM mysql.user WHERE plugin = 'mysql_native_password';
4. Remove removed or obsolete options and SQL modes from configuration files.
5. Check that your connectors, ORM and tools state support for 9.7, and upgrade them first.

Test

1. Restore a recent production backup onto a 9.7 test server, using the same configuration.
2. Run the full automated test suite and any integration tests against it.
3. Replay your most expensive queries (from sys.statement_analysis on production) and compare EXPLAIN plans and timings on both versions.
4. Watch the error log and client warnings for deprecation messages.

Cut over

1. Take a fresh full backup and confirm binary logs are being copied.
2. Prefer a replication-based switch for anything customer-facing: build a 9.7 replica of the 8.4 source, let it catch up, stop writes briefly, promote the replica and repoint the application. The old 8.4 server stays available as your rollback.
3. For an in-place upgrade instead, shut the server down cleanly (the manual recommends a slow shutdown with innodb_fast_shutdown=0 if there was an unexpected shutdown before), replace the binaries and start 9.7. The server performs the upgrade at startup; if it fails, the manual says the server reverts its changes, and you can remove the redo log files, restart the old version on the same data directory, fix the problem and try again.
4. Monitor errors, latency and replication for at least a full business cycle before decommissioning the 8.4 server.

Rehearse the timing

Run the whole cut-over at least once on the test environment with a production-sized copy, and time each step: the backup, the replica build or in-place start, the application switch and the smoke tests. That rehearsal gives you a realistic maintenance window to announce, shows whether the replication-based route keeps downtime to the brief write pause you expect, and produces a written runbook with the exact commands. Keep that runbook with your rollback steps, so the person on call can reverse the change without improvising if monitoring shows a problem after the switch.

Next steps

Pick an LTS line unless you have a reason not to, and do not skip one. If you are on 8.4, start with the upgrade checker and the authentication-plugin query above; together they usually reveal most of the work. If you are still on 8.0, the first project is 8.4. And whichever path you take, make sure you have a tested backup and a rollback route before you touch production.