If you manage a MySQL database, you’ve probably heard the news: MySQL 8.0 is heading for its End of Life (EOL), and taking center stage is MySQL 8.4, the first-ever Long-Term Support (LTS) release. This is great news for all of us who value stability, as it means a more predictable, enterprise-ready platform for the long haul.
Honestly, though, upgrades are never just about getting new features. They’re also about what gets left behind.
Think of it as paying off technical debt. All those “deprecated” warnings you might have seen in your 8.0 logs? The bill is coming due. What used to be a friendly heads-up is now a potential roadblock.
We’re here to walk you through it. No surprises, no “gotchas.” Let’s talk about what’s changing, what’s gone for good, and how you can prepare for a smooth, successful upgrade.
First, let’s get the lingo straight: Deprecated vs. removed
This part is crucial because it dictates how urgently you need to act.
Removed: This means the feature is gone. Vanished. If your application code or a script tries to use it in MySQL 8.4, you will get an error. These are the things that will break your upgrade, and you need to fix them before you start.
Deprecated: This is MySQL’s way of giving you a friendly warning. The feature still works in 8.4, but it’s officially on the chopping block for a future version (like 9.0). It’s your chance to get ahead of the curve and plan for the next upgrade.
How to find MySQL 8.0 deprecated features in your environment
Not sure if your setup is affected? Most teams don’t know until an upgrade fails or tests start throwing errors. Luckily, MySQL Shell includes tools like util.checkForServerUpgrade() to help you scan for deprecated features and upgrade blockers ahead of time.
The upgrade blockers: Features GONE in MySQL 8.4
These are the most urgent items on your checklist. If you’re moving from any 8.0.x version, you need to find and fix these first.
PASSWORD() function
Remember this old thing? For years, people used SET PASSWORD = PASSWORD(…). It’s tied to an older, less secure hashing method and is now completely gone.
What to do: Switch all your user management scripts to use CREATE USER … IDENTIFIED BY ‘password’ and ALTER USER … IDENTIFIED BY ‘password’.
The tx_isolation system variable
This was just an old alias for transaction_isolation. After years of being deprecated, the alias has finally been removed.
What to do: Do a simple search-and-replace in your application code and config files from tx_isolation to transaction_isolation.
Expire_logs_days
This was the old way to set your binary log retention. It’s been replaced by the much more granular binlog_expire_logs_seconds.
What to do: Update your MySQL configuration to use binlog_expire_logs_seconds instead.
The road ahead: What’s newly deprecated in 8.4
Once you’re running on MySQL 8.4, these are the new warnings you’ll see. You should start planning to address them now to make your next upgrade even easier.
Mysql_native_password
This was the default authentication plugin before 8.0. It’s less secure than the current caching_sha2_password default, so it’s officially on its way out. Start auditing your users and older applications to make sure they can handle the modern authentication plugin.
FLUSH HOSTS
This command isn’t as useful in modern, containerized setups. It’s being retired, so it’s best to remove it from any maintenance scripts.
–skip-grant-tables
We’ve all used this “break-glass” option to reset a lost root password, but it’s a huge security hole. Its deprecation encourages using the much safer init-file method for password recovery.
FLOAT(M,D) and DOUBLE(M,D) syntax
A lot of us used this non-standard syntax to define the size of our decimals. The SQL standard is just FLOAT or DOUBLE, so MySQL has removed this confusing alternative.
You should now use the simple FLOAT or DOUBLE types in your schema definitions. It is recommended to handle any specific rounding or formatting within your application logic. While this syntax is currently deprecated, you should expect it to be removed in a future version of MySQL.
Default_authentication_plugin
A simple name change for clarity. This variable is now called default_authentication_policy.
Managing the MySQL lifecycle
Understanding this constant cycle of removed and deprecated features makes one thing clear: managing your MySQL environment is an ongoing process, not a one-time fix. MySQL 8.0’s End of Life is a real deadline, but it’s also a chance to take control of your database strategy, avoid hidden risks, and plan for the future.
So, what’s next? Choose your path for MySQL 8.0 EOL
With MySQL 8.0’s End of Life approaching in April 2026, you face a critical decision. The list of removed features shows that upgrading isn’t always a simple step; it can impact your entire application stack.
At Percona, we believe you should control your own MySQL strategy. Whether you’re ready to upgrade now or need more time to prepare, we have a path to support your business needs.
Path 1: Upgrade to Percona Server for MySQL 8.4
If you’re ready to move to a modern, stable, and more performant platform, this is the path for you. Upgrading ensures you benefit from security enhancements, improved usability, and database performance gains.
But you don’t have to navigate the complexities alone. The Percona team can help you:
- Identify and address deprecated features before they cause issues.
- Assess your full stack to ensure applications, libraries, and your OS work seamlessly.
- Plan and execute the upgrade with minimal disruption and downtime.
- Tune your database post-upgrade for long-term success.
Path 2: Get Post-EOL Support for MySQL 8.0
Maybe an immediate upgrade isn’t feasible. Perhaps you have legacy applications that need more time for migration, or you lack the internal resources for a large-scale upgrade project right now.
This is where Post-EOL support from Percona becomes a strategic advantage. It’s not about ignoring the issue; it’s about buying yourself time, safely. We can keep your MySQL 8.0 databases secure and stable for up to three years past the EOL date, giving you the breathing room to plan your next move without taking on the risks of an unsupported database. This includes:
- Expert-engineered fixes for newly discovered security vulnerabilities (CVEs).
- Hands-on, 24/7 support for issue resolution.
- Guaranteed SLAs for critical issues.
Upgrade or stay on 8.0. We’ll support you either way
Managing the MySQL lifecycle on your terms is crucial. Whether you need a trusted partner to execute a seamless upgrade to Percona Server for MySQL 8.4 or expert support to keep your 8.0 instances secure while you plan, Percona has you covered.
Upgrade to 8.4 or Get Post-EOL Support
