MySQL 8.0 End of Life: Plan Your Move Before Support Runs Out

As of April 2026, MySQL 8.0 has reached End of Life (EOL), marking a critical security and operational milestone. When a database reaches EOL, the safety net is pulled away. Oracle will no longer release security patches, bug fixes, or performance improvements for the community edition. If a vulnerability is discovered tomorrow, your 8.0 instances will remain exposed.

In this post, we’ll explore what this means and how cloud platforms are responding to it.

What does EOL mean?

MySQL 8.0 was first released in 2018 under the traditional "Continuous Delivery" model where new features are added in minor releases alongside any bug fixes or security patches. This has amounted to 46 minor releases in the last 8 years.

In 2023, MySQL began the shift to a dual-track release cycle:

• LTS (Long-Term Support): Focused on stability and security.
• Innovation Releases: Focused on rapid feature delivery.

MySQL 8.0 doesn't fit into this new architecture, and its retirement is necessary to clear the technical debt of the old release model. By retiring 8.0 and declaring it "End of Life", there will be no more security patches or bug fixes for this version, and all users should upgrade to a supported version to avoid the inherent risks:

1. Security Risk: No more patches for CVEs. A single Zero-Day vulnerability could expose your entire dataset.
2. Compliance Failure: Standards like PCI-DSS, HIPAA, and SOC2 generally mandate that you run software receiving active security updates.
3. The "Cloud Tax": Most cloud providers will now charge you significantly more to keep 8.0 running.

How the Cloud Providers are Responding

Cloud providers know you might not be ready to upgrade or may have missed the deadline, so they’ve added safety nets.

AWS moves 8.0 into RDS Extended Support and will officially end support for 8.0 by the end of July 2026. Starting in August 2026, those continuing to run MySQL 8.0 will be auto-enrolled into a paid support tier with an additional fee per vCPU-hour.

Google Cloud has advertised a longer timeline, with paid extended support beginning in January 2027 and a mandatory auto-upgrade to MySQL 8.4 LTS by July 2029.

Oracle Cloud has extended 8.0 support in HeatWave until April 2027. After that, all remaining instances will be force-upgraded to 8.4 LTS.

Checking Your Version

You can check if you're running MySQL 8.0 via the CLI or a simple SQL query:

CLI

mysql --version

SQL

-- Check your current version and architecture
SELECT VERSION(), @@version_comment, @@version_compile_os;

If the result starts with 8.0.x, then we have some work to do.

Long-Term Support vs. Innovation Releases

From version 8.0, you can choose to upgrade to the next LTS release or the next Innovation release depending on your needs.

LTS suits operators who want predictable upgrades. Within an LTS line, minor releases emphasize fixes and security hardening rather than new features, so you spend less time guessing whether a patch will change how you work.

Innovation suits teams that prioritize access to new capabilities on a shorter cycle. New work lands in Innovation releases first, so you do not wait years for the next LTS to experiment. You accept a faster upgrade rhythm and stronger automation around testing.

General Comparison

	LTS	Innovation
Focus	Stability & Longevity	New Features & Fast Iteration
Updates	Security and bug fixes only	Features, security, and bugs
Support	5 years Premier + 3 years Extended	Until the next release (~3 months)
Best For	Enterprise Production	Developers / Early Adopters

Upgrading Your Environment

Upgrading your environment can be a complex process when considering the risks of application downtime during the transition and incompatibility with the new version.

To minimize these risks, follow the blue-green deployment process.

Blue-Green Deployment

Blue-green deployment is a technique that allows you to deploy a new version of your application while keeping the old version running. This is done by creating two environments, one with the new version and one with the old version. Once it is confirmed that the application can successfully run on the new version, you can upgrade the original environment and slowly redirect traffic back to it.

This process maintains the original environment as a backup in case of any issues with the new version.

Let's break it down into steps, specifically for upgrading to MySQL 8.4 LTS on AWS. For other cloud providers, the process will be similar, but follow their guides for platform-specific solutions.

Step 0: Pre-requisites

Before you begin, ensure your Blue (Production) instance meets these criteria:

• Automated backups are enabled (this is required for RDS to create the staging environment).
• The instance must be a standalone primary or Multi-AZ cluster; it cannot be an existing Read Replica.
• Associate the cluster with a custom DB cluster parameter group that has binary logging enabled and a binlog_format set. While any binlog format works, AWS recommends ROW to reduce the risk of replication inconsistencies.
• After enabling binary logging, reboot the DB cluster so the writer is in sync with the cluster parameter group.
• Set a binary log retention period to something other than NULL so binlog files aren’t purged during the provisioning/sync window.
• If you use Amazon RDS Proxy, the Blue cluster must already be a target of the proxy before you create the blue/green deployment.

Changing binlog_format to ROW

If you are switching binlog_format from STATEMENT or MIXED to ROW, MySQL does not rewrite old binlog files. Events already written keep their original format; only new events written after the change takes effect are logged as ROW.

Since binlog_format is set via the cluster parameter group, AWS will roll the change out across the cluster, but it may require a restart depending on how the parameter is applied. Plan a short rollout window and reconnect your applications as part of that window.

After switching to ROW, watch replication lag and binlog/disk growth. ROW logging is often larger than statement-based formats for the same workload.

Step 1: Environment Preparation

Create a Green environment that is a mirror of your Blue environment, but running the new engine version.

In the AWS Console, navigate to your RDS database and select Actions > Create Blue/Green Deployment.

• Identifier: Give the deployment a name like 'upgrade-mysql-8-to-8-4'
• Engine Version: Select the same engine version as the Blue environment.
• Parameter Group: You can choose to use a new parameter group for the Green environment to test different performance settings.
• Creation: AWS will now:
  • Copy the Blue environment’s topology and configured features into a staging area
  • Take a snapshot and create the new Green environment from it
  • Configure replication from Blue to Green (and if Blue has read replicas, copy them as replicas of Green)
• Once the Green environment is created, upgrade it to the new engine version.

Step 2: Smoke Testing & Performance Validation

Using the Green endpoint and a test version of your application, run regression tests to ensure the application is working as expected. Then, prepare for switchover using AWS’s recommendations and guardrails.

1. Test the Green environment thoroughly

   • Run your application test suite against the Green endpoint.
   • Validate authentication: MySQL 8.4 disables the legacy mysql_native_password plugin by default, so confirm your drivers and connection settings work with the new defaults.
   • Check performance: run EXPLAIN (or your normal profiling workflow) for your most expensive queries and confirm plans and indexes are reasonable on 8.4.

2. Verify readiness for switchover

   • Green must be healthy, replicating, and have no active writes.
   • Blue must not have long-running active writes or long-running DDL, because they can increase replica lag.

3. Monitor replica lag and connection pressure

   • For Aurora MySQL, AWS recommends watching the AuroraBinlogReplicaLag CloudWatch metric in the Green environment and keeping lag close to zero to reduce downtime.
   • Check CloudWatch DatabaseConnections (and DBLoad in Performance Insights if enabled). If you run very high connection counts, consider reducing them before switchover to shorten the cutover window.

4. Validate schema drift and cutover assumptions

   • Use Atlas to diff Blue and Green schemas so you don’t discover last-minute drift during cutover.
   • Make sure your client and network configuration doesn’t extend DNS cache TTL beyond 5 seconds (Aurora’s default), so your app doesn’t keep sending traffic to the old writer after switchover.

note

Switchover runs guardrail checks (replication health, replica lag, and write activity) and will block or roll back if conditions aren’t met.

Step 3: Re-route Traffic

When you are ready to make 8.4 your new production version, select the deployment and choose Actions > Switch over.

• Set Timeout: Specify a timeout (e.g., 300 seconds). If the switchover takes longer than this (usually due to high replication lag), AWS will abort and keep your Blue instance as the primary.
• The Cutover Process:
  1. AWS stops writes on the Blue instance.
  2. It waits for the Green instance to finish applying any remaining logs from Blue.
  3. AWS renames the endpoints. The old Blue endpoint now points to the Green instance, and vice versa.
• Downtime: Your application may experience a brief connection drop (usually 2–5 seconds) while the DNS records update, but it should be virtually unnoticeable.

Step 4: Post-Migration Monitoring & Cleanup

After the switchover is complete, the environment labels swap:

• Green is now Production: It has the original production DNS endpoint.
• Blue is now "Old": It is renamed (e.g., db-instance-old-1) and is still running, but no longer receives traffic.

Important Actions:

• Verify traffic: Monitor your application logs to ensure successful connections to the 8.4 instance.
• Delete the Blue instance: Once you are 100% satisfied, manually delete the old 8.0 instance to prevent incurring costs and "RDS Extended Support" fees. You can also keep this database instance running for future use or as a backup.

Conclusion

MySQL 8.0 is EOL, meaning no security or bug fixes will be released for this version and cloud providers will slowly stop supporting it.

Cloud providers can sell you time or force the upgrade for you, but they can’t validate your app. If you want control, move on your schedule. Choose a supported track and cut over with a proven workflow like blue/green so the upgrade is a planned event, not an emergency.