MySQL 8.4 vs 9.7 LTS: what hosting admins need to know

MySQL moved to a two-track release model in 2023: innovation releases every quarter with short support, and a long-term-support release roughly every two years. 8.4 was the first LTS under that model and 9.7, released on 21 April 2026, is the second. With 8.0 out of extended support since 30 April 2026, every MySQL server in a hosting fleet is heading for one of these two, and the choice is less obvious than “newest wins”. This guide compares them from a hosting operator’s point of view.

Short answer: For a hosting fleet in 2026, MySQL 8.4 LTS is the version to run: it is supported until April 2029, it is the only current LTS that cPanel and DirectAdmin offer, and it still allows mysql_native_password accounts. MySQL 9.7 LTS removes that plugin entirely and is not yet in the panel matrices, so plan the 8.4 to 9.7 hop for 2027 or 2028 once accounts are migrated to caching_sha2_password.

Support windows

8.4 LTS was released in April 2024 and is supported until April 2029 under premier support, with extended support to 2032. 9.7 LTS was released in April 2026 and follows the same eight-year shape, so its dates run roughly two years later than 8.4’s. Both receive quarterly maintenance releases with security fixes; check the current patch level on each server:

mysql -e "SELECT VERSION();"
dnf list installed | grep -iE 'mysql-(community-)?server'

The innovation releases between them (9.0 through 9.6) are not for production hosting; they are supported only until the next one ships.

Upgrade paths

Oracle supports in-place upgrades from one LTS to the next, and from any innovation release to the following LTS. So 8.0 goes to 8.4 in place, and 8.4 goes to 9.7 in place. A jump from 8.0 straight to 9.7 is not a supported path; you must land on 8.4 first. There are no downgrades at all in the 8.x and 9.x line, so the backup taken before each hop is the only way back.

On cPanel the panel handles the hop through WHM’s MySQL/MariaDB Upgrade. As of late September 2026 WHM offers MySQL 8.0 and 8.4 on AlmaLinux 8, 9 and Ubuntu 24.04, and 8.4 only on AlmaLinux 10; 9.7 is not in the WHM matrix yet. DirectAdmin’s CustomBuild tracks MySQL 8.0 and 8.4. That means, on either panel, 8.4 is the practical destination today and 9.7 is a decision for when the panel adds it.

Defaults and behaviour changes

8.4 tightened several defaults relative to 8.0. mysql_native_password is disabled by default (the plugin exists but must be enabled to create accounts with it), caching_sha2_password is the default, and several replication variables were renamed from the master/slave terminology to source/replica, with the old names removed. Old my.cnf files with log_slave_updates, slave_parallel_workers or similar fail to start. Also removed: default_authentication_plugin (use authentication_policy), and a handful of InnoDB variables that had been deprecated for years.

9.7 continues in the same direction. mysql_native_password is removed entirely in the 9.x line, which is the single most important fact for a hosting server: any account on the old plugin must be migrated before the upgrade, and any client that cannot speak caching_sha2_password stops working. The 9.x line also introduced a JavaScript stored-program runtime, vector support, and further changes to sql_mode defaults; read the release notes for the exact list at your target patch level.

Find accounts that would break under 9.x:

mysql -e "SELECT user, host, plugin FROM mysql.user WHERE plugin='mysql_native_password';"

On a shared server that list is usually long, because the panel created most accounts under 8.0 defaults. Migrating them is a per-account ALTER USER ... IDENTIFIED WITH caching_sha2_password BY ..., which requires knowing or resetting each password. That alone is a reason to stay on 8.4 until the panel provides an automated path.

Performance

For a typical shared-hosting workload there is no meaningful performance difference between the two; both are the same InnoDB engine with incremental improvements. 9.x has better optimizer handling for some analytic patterns and its vector support matters for the same AI-adjacent applications discussed in our MariaDB vector guide, but WordPress does not care.

Policy for a hosting fleet

• Servers on 8.0: move to 8.4 now, using the steps in our MySQL 8.0 end-of-life guide.
• Servers on 8.4: stay. Plan the 9.7 (or later LTS) hop for 2027 or 2028 once panels support it and the plugin migration is scripted.
• New builds: 8.4 on cPanel and DirectAdmin, because it is what the panels offer.
• Anything on a 9.0 to 9.6 innovation release: move to 9.7 immediately, since those releases are already unsupported.
• Consider MariaDB instead: its LTS choice is wider and its panel support deeper; see the MariaDB timeline guide for the comparison.

Common pitfall

Reading the release number as a security signal. 9.7.0 on release day is not more secure than 8.4’s current patch; what matters is whether the server is on the latest maintenance release of whichever LTS it runs. Keep both on the normal quarterly update cycle and record the patch level in your inventory.

Keep it running

Once a quarter, list every MySQL server with its version and plugin mix:

mysql -N -e "SELECT VERSION(), (SELECT COUNT(*) FROM mysql.user WHERE plugin='mysql_native_password');"

The second number is the size of the job ahead of any 9.x move. Start shrinking it now by creating new accounts on caching_sha2_password where the client stack allows, and the eventual upgrade becomes a package change rather than a project. The MySQL health snapshot script records both numbers so the trend is visible across the fleet.

MySQL 8.4 vs 9.7 at a glance

Official documentation: MySQL reference manual, Linux man pages.

Related guides: MariaDB support timeline 2026–2029: which LTS should your servers run? · A basic RMM monitoring policy for small-business endpoints: disk, patching and antivirus · Fix vCenter root password expired and VCSA disk full (/storage/log).

Frequently asked questions