MySQL 9.3

MySQL 9.3 was an Innovation release following MySQL 9.2, not a maintenance update for the MySQL 8.4 LTS line. Its notable addition was support for JavaScript stored programs, enabling stored procedures and functions to be written in JavaScript through MySQL's JavaScript language component, alongside conventional SQL stored routines. The cycle also incorporated the usual server, optimizer, InnoDB, replication, client, and security fixes accumulated since the preceding Innovation release. Teams using stored routines should treat the JavaScript facility as an optional feature: it expands implementation choices, but introduces a component and runtime dependency that must be managed consistently across environments.

MySQL 9.3 has reached end of life. Remaining on it means there are no further vendor fixes for newly discovered security issues, correctness defects, crashes, replication failures, or upgrade problems in this release line. This is particularly material for an Innovation release, where later cycles can contain compatibility corrections and operational fixes as well as new features. A team that stays on 9.3 also increases the chance that an eventual upgrade crosses more release boundaries at once, making changed defaults, removed functionality, SQL behavior changes, authentication and TLS compatibility, and connector interoperability harder to isolate. Any JavaScript stored programs created specifically for 9.3 should be included in the migration scope, rather than being treated as ordinary SQL routines.

Choose a supported target based on the required support horizon and feature needs; for most production estates, evaluate the current MySQL LTS line as well as the current Innovation line if its newer capabilities are required. Inventory every MySQL server, replication topology member, connector, client utility, authentication plugin, TLS setting, SQL mode, and installed component. Identify JavaScript stored programs and test their deployment, execution, privileges, backup and restore behavior on the target version. Build a representative non-production upgrade environment, restore a current production backup, and rehearse the vendor-supported upgrade path rather than assuming any version jump is valid. Review all intervening release notes and upgrade prerequisites, run application and workload regression tests, validate replication and failover, and measure performance for critical queries and write paths. Take verified backups and document rollback or recovery procedures before scheduling the production migration.