MySQL 8.0 Is Reaching End of Life. Here Are Your Options.

MySQL 8.0 reaches end of life (EOL) in April 2026. Oracle will stop issuing security patches, bug fixes, and official support on that date. Most production workloads likely already have a plan in place, but just in case, we thought it might be useful to do a recap of your options. This isn't a post designed to make you panic. EOL events are normal. The MySQL ecosystem has valid upgrade paths. The right choice depends on your situation. This post tries to lay them out honestly.

What EOL actually means

EOL means security patches, bug fixes, and official support stop. While your data remains safe and the database keeps running, any new vulnerabilities are permanent. Running unsupported is only advisable for air-gapped systems with a firm upgrade timeline and formal risk acceptance. For teams subject to compliance requirements (PCI DSS, HIPAA, GDPR), running an unsupported database engine isn't just a security risk — it's an audit finding.

Option 1: Stay on 8.0, run unsupported

This is the "throw caution to the wind and do nothing" path. Your database keeps running, you get no patches, and you own every security issue that emerges after April 2026.

For most production systems, this is not a real option. There's a narrow exception if you're running a genuinely air-gapped system with no external attack surface and a concrete upgrade timeline underway. In this case, a short grace period post-EOL might be acceptable. But "short" means weeks, not months, and "acceptable" means documented and risk-accepted at the right level.

If you're considering this path, you should also be budgeting for the compensating controls that make it even marginally safe: network isolation, strict privilege management, TLS everywhere, proactive monitoring, and a tested disaster recovery plan.

Option 2: Stay on 8.0 with a safety net (bridge options)

Several options let you keep running 8.0 past EOL while you complete your upgrade. These are bridges — legitimate ones — but not destinations.

Managed cloud PaaS

If you're running MySQL on a managed cloud database service, your provider has likely already extended your effective support window. Here's what each actually offers:

Treat these as an 18-to-24-month upgrade runway, not a long-term solution. Check to make sure dates haven’t changed while planning.

Third-party support contracts

For teams running MySQL on their own infrastructure (physical servers or VMs), third-party support vendors offer post-EOL coverage through backported patches and expert support SLAs.

Percona offers up to three years of extended support for MySQL 8.0 beyond Oracle's EOL date, including custom-backported security patches, 24/7 monitoring, and guaranteed SLAs. It's worth noting that Percona's natural endpoint for this engagement is Percona Server for MySQL — their own MySQL tracking fork (see below). If you engage them for EOL support, expect that conversation to be part of the relationship.

OpenLogic (now part of Perforce) provides vendor-neutral extended support for MySQL 8.0 and other open source components, and will support whichever distribution you're running.

Option 3: Stay in MySQL, upgrade your version

For most teams, this is the right answer. MySQL's upgrade paths within the ecosystem are well-tested, the SQL compatibility story is strong, and you stay in familiar territory.

MySQL 8.4 LTS

MySQL 8.4 is Oracle's designated Long-Term Support release for the 8.x generation. Premier support runs through approximately April 2029, with extended support running through April 2032. It is the intended upgrade target for 8.0 users, and Oracle has explicitly designed the upgrade path to be as smooth as possible.

That said, 8.4 is not a drop-in upgrade. A few changes require attention:

• mysql_native_password is disabled by default. Audit your users and migrate to caching_sha2_password or manually re-enable the legacy plugin before upgrading. This is a common source of application “connection refused” errors after an upgrade.
• Some deprecated features have been removed. Run MySQL's mysqlcheck and review your schema for deprecated syntax, particularly around AUTO_INCREMENT on float/double columns and non-standard foreign key constraints.
• Test in staging first. Snapshot your production database, restore it to a test environment, upgrade there, and run your full regression suite before touching production.

For most teams, 8.4 LTS is the right move. The upgrade is medium effort, the support window is long, and you stay on the database you already know how to operate.

MySQL 9.x (Innovation track)

MySQL 9.x follows Oracle's new "innovation release" model — quarterly releases with new features, supported only until the next release. This is not an LTS release. It's appropriate for teams that want access to the latest MySQL features and run sophisticated upgrade pipelines with short cycles. It is not the right choice if your priority is stability and a long support window.

If you're curious about what's in 9.x, it's worth evaluating — but for most production workloads, 8.4 LTS is the better landing spot.

Tracking forks: Percona Server and others

A tracking fork is a MySQL distribution that stays closely synchronized with upstream MySQL while adding its own improvements — think of it as MySQL with extra features, not a departure from MySQL. Your applications continue to work without modification.

Percona Server for MySQL is the most established of these. It's a drop-in replacement for Oracle MySQL with performance enhancements, extended observability tooling, and improved security defaults. If you're already engaging Percona for EOL support, migrating to Percona Server for MySQL 8.4 is the natural continuation of that relationship. It's a legitimate upgrade path, not just a sales upsell.

VillageSQL fits in this category but is still in alpha and not suited for production yet.

How to decide

A few questions that will clarify the right path:

Are you on managed cloud PaaS? If you're on AWS Aurora (MySQL-compatible), you have until April 2028 before standard support ends — use that time to plan a proper 8.4 upgrade. If you're on RDS, your window closes July 31, 2026.

Do you have compliance requirements? If yes, the "run unsupported" option is effectively off the table. Extended support (cloud or third-party) is your bridge while you migrate.

How complex is your schema and application layer? A simple application with a clean schema can upgrade to 8.4 in days. A complex multi-application system with heavy use of deprecated features may take months. The time to find out is now, not in March.

For most teams reading this: upgrade to MySQL 8.4 LTS. It's the lowest-risk path, it buys you six-plus years of support, and the upgrade from 8.0 is as smooth as Oracle could reasonably make it. Start with an audit of deprecated features, stand up a staging environment, test your applications against 8.4, and schedule the cutover before the EOL date, not after.

Editor's note: We're writing this from the perspective of a MySQL community participant. We're building VillageSQL — a MySQL tracking fork that's currently in alpha and not yet recommended for production workloads. We're not the right choice for your immediate EOL upgrade…yet. Give us a bit more time to get to general availability. What we are is a team that cares about the MySQL ecosystem continuing to thrive.