MySQL 8.0 End of Life: Upgrade Options and Risks You Need to Know

So here’s the thing. April 2026 is right around the corner, and that’s when Oracle’s gonna pull the plug on MySQL 8.0. If you’re running 8.0 in production right now, you got like a month left before the security patches stop coming. Your database is just gonna be sitting there on software that nobody’s watching anymore. Cool, right?

I know what some of you are probably thinking. “We’ve been running 8.0 for freaking ever. It’s solid. Why fix what ain’t broke?” And honestly? I’ve totally thought the same thing more times than I can count. Like, why fix something that’s working, right?

But here’s my take on it—and I’ve learned this the hard way—it’s only NOT broken until it IS broken. And when something goes sideways on unsupported software? You’re TOTALLY on your own. Nobody to call. No patches coming. Just you and a lot of late-night Googling and praying.

So let’s actually talk about what your options are, what staying on 8.0 is gonna cost you, and how to make this switch without losing your entire mind.

What’s Actually Going Down

So here’s the deal. Oracle announced MySQL 8.0 hits End of Life on April 30, 2026. After that? Gone. Kaput. No more security patches—and look, I know that sounds like I’m being dramatic, but I’m really, really not. No more bug fixes. No more performance improvements. And forget about opening any official support tickets. Not gonna happen.

Now here’s the thing that trips people up: your 8.0 installation isn’t gonna magically explode on May 1st. It’ll keep running fine, honestly. It might run fine for months or even years. But here’s the thing—and this is the part I really want you to hear—every single month that passes after April, you’re basically playing with fire. New vulnerabilities get found every day. They don’t get fixed. That’s just how it goes with old software nobody’s maintaining anymore. And your database? It’s sitting right there on the internet, basically waving at hackers going “hey, I’m here, I’m outdated, and nobody’s protecting me.”

Your Upgrade Options

Alright, let’s get into it. Here’s what you’re looking at.

MySQL 8.4 LTS – The Smart Pick

Okay, I’ll be honest with you, if I were running production right now—and I actually was in this exact situation back in December—this is exactly what I’d do. MySQL 8.4 LTS. No hesitation.

Here’s why. Oracle released 8.4 as their official long-term support version, and they’re committed to maintaining it until 2033. That’s eight years of security patches, people. You basically get the best of both worlds: the rock-solid foundation that 8.0 built over the years, plus the peace of mind that comes with knowing you’ve got over half a decade of updates coming.

The really nice part? It’s basically 8.0.40 with a longer support contract. Your queries, your stored procedures, your configs—all that stuff just works. No rewrites, no refactoring, no pulling your hair out. I helped a buddy migrate their entire e-commerce platform last month, and you know what broke? Nothing. Literally nothing. They were shocked.

One thing to keep in mind though—and this applies to any MySQL upgrade really—you’re still in the Oracle ecosystem. Their Enterprise edition gets you official support, but it can get pricey. The community edition works fine for most use cases, just understand what you’re giving up.

Anyway, if you want the path of least resistance and maximum stability? This is it.

MySQL 9.0 – The New Kid on the Block

So Oracle’s pushing 9.0 pretty hard right now. And look, it’s not bad. The JSON improvements are actually pretty legit if you work with JSON data a lot, and the replication stuff is smoother. IPv6 support is there if you need it.

The thing is though—and this is just my opinion—9.0 feels a little more “let’s see what sticks” compared to 8.4. It’s newer, it’s got some experimental features that might change, and honestly? Most places I know are sticking with 8.4 for now. Why be the guinea pig when 8.4 does exactly what you need?

If you’re starting fresh or you’ve got a really simple setup and you want the latest and greatest? Sure, 9.0 is fine. But for existing production systems? I’d sleep better at night with 8.4.

MySQL 8.0.40+ – Kicking the Can

Oh, you can also pay Oracle for extended support. If you’ve got an Enterprise contract, you might squeeze patches through April 2028.

But honestly? I wouldn’t want to be the one explaining that decision to my boss. “Hey, let’s pay extra to stay on software that’s basically dead, and then we’ll do this all over again in two years.” Nah. Hard pass. This only makes sense as maybe a three-month bridge if you’re seriously under a rock and can’t upgrade in time.

MariaDB – The Open Source Way

Okay, this is where things get actually interesting. MariaDB 11.x—and I know, the versioning is weird, just roll with it—is basically a drop-in replacement for most MySQL users. The original MySQL founders built it after they left Oracle, long story, you can Google it if you want the drama. And guess what? It’s completely free. Like, totally free. No licensing headaches whatsoever.

Here’s the wild part. The compatibility honestly blows my mind every time. Most MySQL applications work with MariaDB without ANY changes. I’ve personally helped three different companies make this switch in the past year alone. Know how many had to modify a stored procedure? Just ONE. That’s literally it.

The community behind MariaDB is super active too. Patches come out regularly, the documentation is solid, and there’s none of that “well, that’s an Enterprise-only feature” nonsense. You get what everyone gets.

Now here’s where people hesitate. If you need Oracle support for compliance reasons—and some industries absolutely require it—MariaDB might be a tough sell. Also, some MySQL-specific stuff behaves slightly different. Nothing major, but worth testing. And occasionally some third-party tools act up, though that’s gotten way better recently.

But honestly? For a lot of teams, this is the move. Free forever, solid performance, active development. What’s not to like?

PostgreSQL – The Big Switch

Alright, this one’s not for everyone. I’ll just put that out there.

But here’s the thing. Some shops use MySQL EOL as a reason to finally check out PostgreSQL. And honestly? I get it. PostgreSQL’s SQL standards compliance is way better, the JSON support is fantastic, and the open-source community behind it is incredible. Like, genuinely world-class.

The catch? This is a bigger undertaking. If you’re considering this, you need to plan for 2-4 weeks minimum of testing. Your queries might need some tweaking. Your ORM might need adjustments. Your team’s gonna have a learning curve.

But if your team already has PostgreSQL skills, or you’ve been wanting to make the switch for a while? The EOL deadline gives you PERFECT cover for why you’re making the change. Sometimes you need permission to make the leap, and this is it.

The Real Risks of Staying on 8.0

I want to be straight with you about what happens when you stay on unsupported software, because I think people tend to bury their heads in the sand on this one.

Security vulnerabilities pile up. After EOL, any new vulnerabilities found in MySQL 8.0 won’t get patched. EVER. Zero-day exploits targeting unpatched MySQL installations will literally exist. Your database sitting on the internet? It becomes a target. Bad actors scan for this stuff CONSTANTLY. Like, it’s literally their job. They’re making money finding these holes. And yours will be sitting there, unpatched, waving hello.

Compliance nightmares. If you’re in healthcare, finance, or handling any regulated data at all, running unsupported software might violate compliance requirements. HIPAA, PCI-DSS, SOC 2, they ALL expect you to maintain supported systems. This isn’t optional. You can get in SERIOUS trouble. Like, I’m talking potential fines, audits, maybe worse. Is that really worth the “convenience” of not upgrading?

No help when things break. Call Oracle support with an 8.0 problem after April? They’ll basically tell you to get lost and hang up. That critical production issue at 2 AM? You’re stuck Googling forums and Stack Overflow, hoping someone else had the same problem. By yourself. Alone. Fun times.

Talent drain. Here’s one thing people don’t really think about. Your younger DBAs have been learning MySQL 9.0 and PostgreSQL. They look at your 8.0 production servers and wonder what planet you’ve been living on. Good people leave shops that don’t invest in their systems. It’s just reality, unfortunately.

I worked at a company that stayed on MySQL 5.7 for THREE WHOLE YEARS after EOL. Wanna know what happened? They had ONE breach, ONE ransomware attempt, and COUNTLESS nights where nobody slept. The “savings” from not upgrading? They spent way more on incident response and lost business than an upgrade would’ve cost them. It was an absolute mess. Like, seriously bad.

How to Actually Upgrade

Alright, let’s walk through how teams actually do this. Here’s what works.

Step 1: Know What You’re Working With

Don’t touch ANYTHING until you know your landscape:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
-- Check all your databases and their sizes
SELECT table_schema AS 'Database',
 ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Size (MB)'
FROM information_schema.tables
GROUP BY table_schema;

-- List all stored procedures and functions
SELECT routine_name, routine_type
FROM information_schema.routines
WHERE routine_schema = 'your_database';

-- Check your MySQL version
mysql> SHOW VARIABLES LIKE '%version%';

Write all this down somewhere. This is your baseline. You’ll literally thank me later.

Step 2: Test in Staging

NEVER, EVER upgrade production first. I CANNOT stress this enough. Set up a staging environment that mirrors production as closely as you can.

Dump your production database
Restore it on a staging server running MySQL 8.4 LTS, 9.0, or MariaDB
Run your full test suite
Check slow query logs
Test any custom stored procedures or scheduled jobs

Expect some friction. Plan for 1-2 weeks of testing minimum. I’m serious.

Step 3: Backup Everything

I SHOULDN’T have to say this, but I’ve literally seen shops skip this step. DON’T be that person. I’ve seen it happen and it wasn’t pretty. At all.

1
2
3
4
5
6
7
# Full MySQL backup before upgrade
mysqldump -u root -p --all-databases --single-transaction \
 --routines --triggers --events \
 > full_backup_$(date +%Y%m%d).sql

# Verify the backup is readable
head -5 full_backup_20260401.sql

Test restoring that backup somewhere. I mean it. Actually test it. Please.

Step 4: The Upgrade

If you’re sticking with MySQL, the actual upgrade’s pretty straightforward:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# Stop MySQL
sudo systemctl stop mysql

# Update the package
sudo apt update
sudo apt install mysql-server

# Start MySQL
sudo systemctl start mysql

# Run the upgrade checker
mysql_upgrade -u root -p

# Verify
mysql> SELECT VERSION();

Step 5: Watch Everything After

First 72 hours after upgrade, keep a close eye on things:

Slow queries (check slow query log)
Connection issues (watch max_connections)
Replication lag if you’ve got replicas

1
2
3
4
5
-- Check for post-upgrade errors
SHOW WARNINGS;

-- Monitor active connections
SHOW STATUS LIKE 'Threads_connected';

My Honest Take

Here’s where I’m gonna be straight with you: if you’re running MySQL 8.0 in production, you NEED a plan by end of March 2026. PERIOD. Whether you go to 8.4 LTS, 9.0, MariaDB, or use this as a reason to check out PostgreSQL depends entirely on your situation.

If I had to pick one right now? 8.4 LTS. No brainer. Best stability, best support, least amount of headache. You can call me in six months and tell me I was right.

But seriously, whatever you do, DON’T wait until April 30th. Migrations under time pressure ALWAYS go worse than they should. I’ve seen it happen a dozen times. I’m telling you, it’s not worth it.