MySQL Support Options After MySQL 8.0 End of Life

MySQL support comes from Oracle for MySQL Enterprise Edition customers on a supported release, from the community for MySQL Community Edition, from cloud providers for their managed MySQL services, and from independent providers for everything else, which now includes every MySQL 8.0 and 5.7 database still in production. MySQL 8.0 reached end of life in April 2026, so this is a live question for most MySQL users.

What Oracle supports, and for how long

Oracle owns MySQL and sells technical support as part of MySQL Enterprise Edition, which also adds management tools such as MySQL Enterprise Backup, MySQL Enterprise Audit and monitoring. Support follows Oracle Lifetime Support: a period of Premier Support with new releases and fixes, a period of Extended Support, and then Sustaining Support, under which you keep access to existing fixes and the knowledge base and receive no new error correction for new issues.

Oracle's MySQL end of life notice lists MySQL 5.7 as end of life on 25 October 2023 and MySQL 8.0 as end of life on 21 April 2026, both now covered under Sustaining Support only, and encourages users to upgrade to MySQL 8.4 LTS or 9.7 LTS. Since 2023 MySQL releases come in two tracks: Innovation releases, supported only until the next one ships, and long-term support releases intended for production.

MySQL Community Edition is the same open source database under the GPL, with no support contract. Help comes from the documentation, the MySQL forums and the bugs database.

Managed MySQL services

Amazon RDS and Aurora, Azure Database for MySQL, Google Cloud SQL and Oracle's own MySQL HeatWave run the MySQL server for you and support the service: instances, storage, automated backup, failover and uptime. Each keeps its own end-of-life calendar for MySQL versions, in some cases with a paid extended support option, and will eventually force an upgrade. None of them supports your schema, your queries or your application's use of the database.

The MySQL incidents that actually page people

• Replication lag. A replica falls minutes or hours behind because of a long transaction on the source, single-threaded apply, a table with no primary key, or a replica on slower storage. Reads go stale and failover becomes unsafe. Parallel replication settings and schema fixes solve most cases.
• InnoDB lock contention and deadlocks. Transactions queue behind row locks or gap locks, connections pile up, and the application times out. The cause is usually transaction design or a missing index that turns a row lock into a range lock.
• A query that changed plans. The optimizer picks a different index after statistics change, and a fast query becomes a full scan. Histograms, index hints and the slow query log are the tools. Restarting is not.
• Connection storms. An application deploy or a retry loop opens thousands of connections, max_connections is reached and everything fails at once. A proxy such as ProxySQL or connection pooling in the application is the durable fix.
• Schema changes on large tables. An ALTER TABLE that was instant in testing locks or rebuilds a multi-hundred-gigabyte table in production. Online DDL has rules, and tools such as gh-ost or pt-online-schema-change exist because those rules are easy to break.
• Backups that were never restored. A logical dump of a large MySQL database can take a day to restore. Physical backups and a rehearsed point-in-time recovery are what high availability plans quietly depend on.

Upgrading from MySQL 5.7 or 8.0

From 5.7, the path goes through 8.0 before 8.4. The 8.0 upgrade is the larger step: the data dictionary moved into InnoDB, the default authentication plugin and character set changed, reserved words were added, and some SQL modes and features were removed. MySQL Shell's upgrade checker utility reports most of these in advance and should be run against a copy of production. From 8.0 to 8.4 LTS the step is smaller, though 8.4 removed items that 8.0 had deprecated, including the old authentication plugin being disabled by default, so client libraries need checking. The safe pattern is the usual one: upgrade a replica first, run the real workload against it, promote it, and keep the old source available until you are sure.

Some teams use the moment to consider a fork. Percona Server for MySQL tracks Oracle's releases with added instrumentation, and MariaDB has diverged enough to be a migration, not an upgrade.

Where independent MySQL support fits

• MySQL 8.0 and 5.7 estates, which no longer receive fixes from Oracle, while the upgrade is planned.
• MySQL Community Edition in production, where there is no vendor to call.
• Cloud-hosted MySQL, where the provider covers the service and nobody covers query performance, reliability of replication or scalability limits.
• Teams without DBAs. Expert MySQL support engineers on call are cheaper than an outage and easier to find than a hire.

AceMQ provides 24/7 MySQL support for Community, Enterprise, Percona Server and cloud-hosted MySQL on any version, with a 15-minute emergency SLA and named senior engineers. Examples: a replication lag remediation and InnoDB lock contention support. For how MySQL's window compares with PostgreSQL and others, see support windows compared.