MySQL End of Life (EOL): Dates, Risks, and Upgrade Checklist

1. What Is MySQL End of Life (EOL)? Why You Should Check It Now

What is MySQL EOL? A basic explanation

MySQL is an open-source relational database management system widely used around the world. It powers everything from web applications to business systems—but no version can be used forever.

MySQL also has an “End of Life (EOL)” point. This refers to the date when Oracle, the developer, ends support for that version—such as security updates and bug fixes.

For example, MySQL 5.7 reached end of support in October 2023. This kind of “EOL information” is extremely important because it directly impacts the safety and future maintainability of systems in production.

“It was EOL before we noticed” is extremely dangerous

Many developers and operators tend to be cautious about upgrading MySQL. It’s easy to think “it’s stable, so we can leave it as-is,” but continuing to run an EOL version comes with major risks.

Specifically, risks include:

• Security vulnerabilities are not patched
• Compatibility with the OS and other software is lost
• You can no longer get support from vendors
• New developers have a harder time maintaining it, increasing maintenance costs

To avoid these risks, it’s essential to regularly verify the support status of the MySQL version you’re using.

Knowing support status prevents “incidents”

Especially for companies using MySQL in business systems, a situation like “we unknowingly ran past EOL” can later lead to major outages or security incidents.

That’s why understanding the support lifecycle of your MySQL version—and performing planned upgrades or migrations before EOL—is the key to stable operations going forward.

In the next section, we’ll organize a clear list of which versions reached EOL and when, as a practical reference.

2. MySQL End-of-Support Timeline by Version (EOL Summary)

Know the major MySQL versions and their EOL dates

MySQL has been continuously updated over the years, and each major version has a clearly defined support period. Below is a summary of the officially published EOL (end-of-support dates) for major versions.

[EOL Table by Version]

*Dates are based on publicly available information from Oracle and major cloud providers.

MySQL 5.5 (support ended in 2018)

MySQL 5.5 was released in 2010 and adopted by many web applications. However, support ended on December 3, 2018. Since no security patches or bug fixes are provided anymore, any system still running it should migrate as soon as possible.

MySQL 5.6 (support ended in 2021)

MySQL 5.6 became popular due to performance improvements and new features, but it reached EOL on February 5, 2021. Environments still using it are already out of support and exposed to significant risk.

MySQL 5.7 (support ended in October 2023)

MySQL 5.7 was widely used in enterprise systems for many years, but support ended on October 21, 2023. Many systems are still running this version, and more organizations are rushing to migrate. Compatibility checks and data migration work are now major focus areas.

MySQL 8.0 (premium support planned to end in April 2025)

MySQL 8.0 is the current mainstream stable version, but premium support is planned to end in April 2025. After that, extended support or switching to an LTS (Long Term Support) release is recommended. Attention is growing around MySQL 8.4 LTS, introduced in 2024, and it’s worth considering if you want stable long-term operations.

EOL information is essential for future planning

As shown above, each MySQL version has a planned EOL, and you need migration preparation accordingly. Double-check the version your system uses and think not “we’re fine for now,” but “when will we migrate?”.

3. What Happens After Support Ends? EOL Risks Explained

The risks of continuing after end of support are huge

When a MySQL version reaches EOL (End of Life), official security updates, bug fixes, and improvements are completely stopped. In other words, you can no longer receive any support from Oracle.

Even if everything appears to run normally, serious risks can be lurking under the surface. This is especially critical for internet-facing web servers or core business systems.

Unpatched security vulnerabilities

The most severe issue is that newly discovered vulnerabilities will no longer be patched. Attackers use known vulnerability information to target EOL versions.

And because MySQL is widely used, it’s also an attractive target. Even if vulnerabilities are disclosed after EOL, your defense options become extremely limited if no fix will ever be released.

🔒 No patch available = you remain a target at all times.

Risk of violating laws and security standards

More companies and public institutions are required to comply with standards like ISMS or PCI DSS. These standards often explicitly prohibit using unsupported software.

That means continuing to run an EOL MySQL version can lead to audit findings or damage trust with business partners.

Operational issues caused by incompatibility with OS or other software

Because EOL versions are no longer tested for compatibility with newer OS releases or other software, they can cause unexpected failures or performance issues. Real-world cases include MySQL failing to start after an OS update or performance degrading significantly.

This can lead to emergency firefighting—or worst-case, service downtime.

It grows as technical debt

Keeping an EOL version alive accumulates technical debt. When you eventually must upgrade, migration costs can spike, and you may find large amounts of code dependent on old behavior.

In short, the longer you postpone it, the more cost and risk increase over time.

How to keep operations safe

To avoid EOL risks, you don’t necessarily have to upgrade immediately—but you should build a migration plan. By understanding your current version, the time remaining until EOL, and choosing a destination, you can maintain a stable environment with confidence.

In the next section, we’ll介绍 the main migration options and which cases they best fit.

4. Migration Options: Choose the Best Strategy for Your Goals

Your EOL response depends on your “migration strategy.”

When MySQL approaches EOL, the most important decision is “where to migrate”. It’s not enough to simply upgrade—choosing an option that matches your requirements and operational structure determines future stability.

Here are three common migration patterns and which types of users they fit best.

Upgrade to MySQL 8.0 or 8.4 LTS (conservative, stability-focused)

The simplest option is to upgrade to a newer MySQL version. Currently, MySQL 8.0 is standard, but since 2024, MySQL 8.4 LTS (Long Term Support) has been drawing attention.

• Pros:
• High compatibility with existing MySQL environments
• Can continue using open source
• Existing tools like MySQL Workbench can continue to be used
• Cons:
• Compatibility errors may occur due to syntax/spec changes
• You must pay attention to storage settings and character sets
• Best for:
• Small to mid-sized companies and developers who want stable operations without major system changes

Migrate to alternative RDBMS like MariaDB or TiDB (flexibility and future-proofing)

Switching to an RDBMS compatible with MySQL is also a strong candidate. Two popular options are MariaDB and TiDB.

• MariaDB:
• A fork of MySQL with similar syntax and administration
• Actively developed by the community
• Rich performance optimization features
• TiDB:
• A cloud-native, distributed SQL database
• Strong high availability and scalability
• Handles both OLAP and OLTP well, suitable for analytics too
• Best for:
• Organizations considering future cloud migration or large-scale data processing
• Teams that want to adopt advanced open-source technology

Managed cloud database services (reduced ops workload, scalable)

If you want to reduce on-prem operational overhead, consider managed cloud RDB services. Common examples include:

• Amazon RDS for MySQL
• A managed service by AWS
• Automatic backups and redundancy are standard
• Be aware of potential automatic upgrades over time
• Google Cloud SQL for MySQL
• A managed service by Google Cloud
• Scalable and integrates well with other GCP services
• Easy to manage via UI, beginner-friendly
• Pros:
• No OS or hardware maintenance
• Less infrastructure expertise required
• Cons:
• Ongoing cloud costs
• Fine-grained tuning may be harder
• Best for:
• Operating small to mid-sized web applications
• Startups and web businesses that want to streamline dev/ops resources

[Comparison Table] Options and characteristics

In the next section, we’ll break down the practical migration steps and key precautions in a clear, actionable way. Let’s go through the checklist to avoid mistakes.

5. MySQL Migration Steps and Checklist (How to Avoid Failure)

Migration success is “80% preparation”

Migrating due to MySQL EOL is different from a simple version bump—it requires careful steps and thorough preparation. Especially for production systems, ensuring data integrity and service continuity is the top priority.

Here we explain the key steps in five phases.

STEP1: Assess and inventory the current environment

First, identify your current MySQL version, configuration, and dependencies.
Check the following items:

• MySQL version and build number
• Character set in use (e.g., utf8mb4)
• Storage engine (InnoDB, MyISAM)
• SQL syntax and functions in use (may have version dependencies)
• Connected applications and external services

✅ Goal: understand all dependencies to prevent post-migration failures

STEP2: Verify compatibility

Validate whether your current environment is compatible with the target version. With major upgrades, pay special attention to:

• Removed syntax / reserved words you may be using
• Default setting changes (e.g., SQL mode)
• Differences in system variables and parameters

🔎 You can diagnose compatibility using the mysql_upgrade command or the MySQL Shell Upgrade Checker Utility.

STEP3: Take backups and build a test environment

Upgrading production directly is too risky.
First, take a full backup and use it to build a staging (test) environment.

• Dump backups using mysqldump or mysqlpump
• File-based backups (e.g., XtraBackup)
• Restore into staging and test application behavior

By finding post-migration issues and SQL errors in advance, you can minimize trouble during production cutover.

STEP4: Migrate data to production

After validation, migrate to production. If possible, do it at night or during low-traffic periods.

• Final backup right before migration
• Temporarily pause the service (use a maintenance page if possible)
• Import data into the new database version
• Adjust config files and environment variables

If you also need changes on the application side (like switching the MySQL endpoint), be especially careful about timing.

STEP5: Validate and optimize

Migration isn’t finished at cutover.
Check the following to confirm the new environment is stable:

• Connectivity from the application
• Query execution speed and any errors
• Log monitoring (error log, slow query log)
• Optimization of cache settings and index rebuilds

As needed, run ANALYZE TABLE or OPTIMIZE TABLE to recover performance regressions introduced by migration.

Checklist (final review)

✅ Confirm current version and configuration
✅ Run compatibility checks in advance
✅ Take a full backup
✅ Test in a staging environment
✅ Execute a planned production cutover
✅ Monitor errors and performance after migration

The key to success is execution planning. For EOL-driven migrations, steady preparation, testing, and careful cutover are the best risk-reduction strategy.

6. Handling EOL on Cloud Services (For AWS and GCP Users)

Even on the cloud, you can’t be complacent

Even if you use MySQL on cloud platforms like Amazon RDS or Google Cloud SQL, EOL (end-of-support) is still your problem. Cloud providers may implement automatic upgrades or even service retirement for unsupported versions, so proactive planning matters.

Below is an overview of EOL handling by major cloud services.

Amazon RDS for MySQL: watch out for automatic upgrades

With Amazon RDS for MySQL, AWS has performed version retirements and forced upgrades due to end of support multiple times.

• MySQL 5.5: ended in 2018 → automatically migrated to 5.6
• MySQL 5.6: ended in 2021 → automatic upgrades to 5.7 implemented after 2022

As a result, your MySQL version may switch at a time you didn’t intend, potentially causing application issues or performance regressions.

✅ Mitigation: plan and execute upgrades on your own schedule

AWS provides advance notice via email and console notifications, but if you ignore it, it may be applied automatically—so be careful.

Google Cloud SQL for MySQL: first-gen retirement and migration push

Cloud SQL for MySQL is also moving forward with the retirement of older versions and architectures.

• First-generation instances can no longer be newly created
• There are policies encouraging upgrades for versions approaching end of support

Google tends to respect user flexibility, but there are limits to long-term “life support,” so you should upgrade or rebuild earlier rather than later.

Cloud SQL also provides strong features like automatic backups and failover, but issues can still happen if you overlook differences such as default SQL mode settings or time zone behavior.

✅ Test cloud-specific settings and compatibility in advance

Cloud benefits—and EOL pitfalls

Cloud services have advantages, but weak EOL preparation can cause trouble.

Even in the cloud, the reality is the same: you are still responsible for dealing with EOL.

EOL checklist for cloud environments

✅ Check your current MySQL version and the EOL timeline
✅ Enable vendor notifications (email or other channels)
✅ Confirm whether you’re subject to automatic upgrades
✅ Test the new version in staging
✅ Plan application-side changes as needed

To get the most out of cloud convenience, don’t “set and forget.” Maintain active management and monitoring on your side. For MySQL EOL in particular, cloud environments still require solid preparation.

7. Frequently Asked Questions (FAQ)

Q1: Can I keep using MySQL after support ends?

A: Technically yes, but it’s not recommended.
EOL MySQL receives no security patches or bug fixes. This rapidly increases the risk of attacks exploiting vulnerabilities and may violate laws or security policies.

Even if the system looks fine, you’re still operating with serious hidden risk, so plan an upgrade or migration early.

Q2: What’s the difference between MySQL 8.0 and 8.4 LTS?

A: MySQL 8.4 LTS is a stable release supported for a longer period.
MySQL 8.0 follows the regular release cycle, and premium support is planned to end in April 2025. In contrast, MySQL 8.4 LTS (Long Term Support) was introduced as a stable release with roughly five years of long-term support.

If you prioritize long-term stability for business systems, migrating to MySQL 8.4 LTS is recommended.

Q3: How much does migration cost?

A: It depends heavily on scale and the migration path.
For example, a version upgrade on the same server may be possible at no direct cost. But migrating to cloud services or switching products (MariaDB/TiDB) can require effort and expenses for design, build, testing, and technical support.

You should also consider costs for downtime mitigation and preparing a staging environment.

Q4: What should I watch out for when migrating production systems?

A: Pre-testing and phased migration are key.
In production, you must do compatibility checks, backups, and staging tests. Using read replicas or blue-green deployment (running old and new environments side-by-side and switching gradually) can reduce downtime.

It’s safest to perform the work at night or on weekends when traffic is low.

Q5: Can I stop automatic upgrades in the cloud?

A: You can control some parts, but you ultimately must follow vendor policy.
RDS and Cloud SQL allow some control such as delaying or adjusting automatic upgrade schedules, but forced upgrades may still occur after EOL.

Because long-term avoidance is difficult, the most reliable approach is planned upgrades driven by you.

Q6: How should I choose an alternative database?

A: Use these three criteria.

1. Compatibility: how much of your existing app and SQL will work as-is
2. Scalability / future-proofing: whether it can handle growth in data and traffic
3. Operational capability: whether you can maintain it in-house or need vendor support

For business systems, selection should be based on your realistic operational capacity rather than trends.

8. Summary: The Best Move You Can Make Before Support Ends

EOL isn’t “far away”—it’s right around the corner

MySQL EOL (end of support) isn’t only relevant to IT staff. It affects the entire organization across security, performance, availability, and cost management.

MySQL 5.7 already reached end of support in October 2023, and MySQL 8.0 is planned to reach end of premium support in April 2025. If you think “it still runs, so it’s fine,” you may end up operating with critical risk before you realize it.

Planned migration is the best risk-avoidance strategy

As shown in this article, migration isn’t hard when done step by step:

• Identify the current version
• Check compatibility and choose a migration destination
• Test in a staging environment
• Perform phased migration and final cutover

By following these steps, you can complete migration safely while avoiding downtime and data loss.

Even when using cloud services, don’t leave everything to the vendor—understand your situation and proactively build an upgrade plan.

“I didn’t know” is no longer an excuse

In modern system operations, what’s required is not only technical knowledge but also ongoing maintenance awareness. Knowing end-of-support timelines, evaluating risk, and choosing the best migration option are essential skills for all operators and developers.

Finally: three actions to take right now

1. Check the MySQL version used in your system
2. Confirm the EOL date and put it on your calendar
3. Discuss your migration approach (upgrade vs. switching databases) with your team

Even doing just these will make your next step clear.

Handling MySQL EOL is an “insurance policy” against future incidents.
Use this article as a trigger to review your operations and build a safer, sustainable environment.