MySQL 8.4

MySQL 8.4 is the Long-Term Support (LTS) line that succeeds the 8.0 LTS line. It consolidates the changes introduced across the intervening Innovation releases while retaining the MySQL 8.0 upgrade path. The cycle emphasizes a stable feature baseline rather than continual feature delivery. It also carries forward removals and behavioral changes for functionality deprecated in earlier releases. A notable authentication change is that the mysql_native_password server plugin is disabled by default; deployments that still use accounts authenticated through that plugin must explicitly enable it or, preferably, migrate those accounts and clients to a supported authentication method such as caching_sha2_password. As with any major MySQL line upgrade, changed defaults, removed deprecated options, SQL and replication behavior, client-library compatibility, and plugin availability must be reviewed against the actual workload.

MySQL 8.4 remains in its supported window, so staying on it is a valid choice for teams that prioritize a stable LTS baseline. It continues to receive maintenance releases, including relevant bug and security fixes, but it is not where MySQL introduces its newest capabilities. The practical cost of remaining on 8.4 is therefore primarily deferred access to functionality and improvements available only in newer release lines. Over time, the larger risk is compatibility debt: applications may remain dependent on old authentication settings, deprecated SQL or server configuration, particular connector versions, operating-system packages, or replication topologies that make a later move more complex. Delaying upgrade assessment also concentrates testing and remediation into a future migration rather than spreading it across normal maintenance work.

Treat MySQL 8.4 as a stable operating target, but keep an upgrade-readiness process in place. Run MySQL Shell's upgrade checker against representative production configuration and schema metadata for the intended target release, and resolve every reported error or incompatibility before scheduling an upgrade. Inventory user accounts, client drivers, connection pools, plugins, and automation, with particular attention to any use of mysql_native_password and to clients that cannot use caching_sha2_password. Test the upgrade on a restored production-like copy, including application queries, stored programs, replication or Group Replication behavior, backups and restores, failover procedures, monitoring, and performance-sensitive workloads. Take verified backups and document a recovery approach before production work; do not assume an in-place major-version upgrade can simply be reversed. Continue applying 8.4 maintenance updates, and periodically test a newer MySQL line so that a future move is planned rather than urgent.