MySQL, PostgreSQL, Redis, and MongoDB End-of-Life Dates in 2026

There's a particular kind of denial that sets into engineering teams around end-of-life dates. Nobody argues the date is wrong. Nobody says the risk isn't real. They just quietly decide it's a problem for six months from now, and six months from now they decide it's a problem for six months after that. Meanwhile the debt keeps compounding — not financial debt, data debt, the kind that shows up as a CVE nobody can patch, or a compliance auditor asking why you're running something Oracle stopped supporting over a year ago.

2026 is the year that math stops working for a lot of teams. Four of the most widely deployed open source databases on the planet are hitting end-of-life milestones this year, and by the time you're reading this, at least one of those deadlines has already passed. This isn't a warning about something distant. Some of it already happened.

Here's where things actually stand, and what to do about it, with the commands you'll actually need.

The Dates, As They Stand Today

MySQL 8.0 reached end of life on April 30, 2026. That date has passed. As of this writing, MySQL 8.0 no longer receives community security patches, bug fixes, or vendor-backed support from Oracle. Extended and cloud-provider support windows exist — AWS RDS extended support runs into 2028, Google Cloud has pushed its own cutoff out further, Oracle Cloud has extended HeatWave coverage into 2027 — but the community edition's clock has already run out. If you're still running 8.0 on self-managed infrastructure, every day since April 30 has added exposure, not subtracted it.

Redis 7.2 went end of life in February 2026 — also already behind us. Redis 7.4 follows in November 2026.

MongoDB 6.0 reaches end of life in June 2026.

PostgreSQL 14 doesn't have a fixed calendar date in the same way — it goes end of life when PostgreSQL 19 ships, expected around September 2026. PostgreSQL 13 is already end of life as of this writing.

None of these dates mean the database stops running the day after. What they mean is the safety net disappears: no more security patches, no more bug fixes, no more official support. The database keeps executing queries right up until the moment a zero-day shows up that nobody's going to fix for you.

Step One: Find Out What You're Actually Running

Before any migration conversation is useful, you need an honest inventory — not what you think is deployed, what's actually deployed, across production, staging, and every forgotten dev instance that's been running since 2022. This sounds obvious and gets skipped constantly, because it's tedious and nobody wants to be the one who finds the surprise.

Here's a quick version-check for each engine:

SELECT VERSION(), @@version_comment, @@version_compile_os;

-- PostgreSQL: check version
SELECT version();
-- or from the shell
psql -c "SHOW server_version;"

redis-cli INFO server | grep redis_version

db.version()

If you're managing more than a handful of instances, script the audit instead of doing it by hand. A simple loop against a host list gets you most of the way there:

#!/usr/bin/env bash

while read -r host; do
  echo -n "$host: "
  mysql -h "$host" -u audit_user -p"$MYSQL_AUDIT_PW" \
    -N -e "SELECT VERSION();" 2>/dev/null || echo "unreachable"
done < hosts.txt

Run the equivalent for each engine you operate, dump the results into a spreadsheet or a tracking issue, and you've got the artifact every migration plan actually starts from: a real list, not a remembered one.

MySQL 8.0 → 8.4 LTS

For most teams still on 8.0, the recommended landing spot is MySQL 8.4 LTS rather than jumping onto an Innovation release — LTS trades bleeding-edge features for a multi-year support runway, which is what you want after just clawing your way off an unsupported version.

Back up before touching anything:

mysqldump --single-transaction --routines --triggers \
  --all-databases -u root -p > full_backup_$(date +%F).sql

For anything beyond a small instance, mysqldump alone isn't a serious backup strategy — pair it with binary log retention so you can do point-in-time recovery, and consider physical backup tools like Percona XtraBackup for larger datasets where a logical dump would take too long to restore under pressure.

The upgrade path itself, in broad strokes:

mysql -u root -p -e "SET GLOBAL binlog_format = 'ROW';"
 
mysqlsh -- util check-for-server-upgrade
 
sudo apt-get install mysql-server-8.4   # Debian/Ubuntu example
 
mysql_upgrade -u root -p

mysqlsh util check-for-server-upgrade is worth running early and often — it flags deprecated syntax, removed features, and configuration options that behave differently on the target version, before those surprises show up in production.

PostgreSQL: Watch the 14 → 19 Window

PostgreSQL's versioning means you're less likely to hit a hard wall overnight, but the same principle applies: plan the move before the version you're on stops receiving fixes.

psql -U postgres -c "SHOW server_version;"
 
pg_dump -U postgres -Fc mydb > mydb_backup_$(date +%F).dump

The in-place upgrade tool for PostgreSQL is pg_upgrade, which avoids a full dump-and-reload cycle for large databases:

pg_upgrade \
  --old-datadir=/var/lib/postgresql/14/main \
  --new-datadir=/var/lib/postgresql/17/main \
  --old-bindir=/usr/lib/postgresql/14/bin \
  --new-bindir=/usr/lib/postgresql/17/bin \
  --check   # run with --check first, drop it once the dry run is clean

Always run --check first. It validates compatibility without touching data, and it will catch extension mismatches, encoding issues, or custom collation problems before they turn into a failed cutover at 2 a.m.

Redis 7.2/7.4: Check Persistence Before You Touch Anything

Redis upgrades are usually less invasive than a relational database migration, but the persistence layer needs attention — an interrupted upgrade mid-RDB-save is a bad way to lose data you didn't back up first.

redis-cli INFO server | grep -E "redis_version|rdb_"
 
redis-cli SAVE
 
cp /var/lib/redis/dump.rdb /backup/redis_dump_$(date +%F).rdb

For clustered or replicated Redis deployments, upgrade replicas first, verify they rejoin the cluster cleanly and serve reads correctly, then fail over and upgrade the former primary — never upgrade a lone primary in a live cluster as your first move.

MongoDB 6.0: Mind the Feature Compatibility Version

MongoDB's upgrade process has a specific gate worth knowing about: the feature compatibility version (FCV), which controls which on-disk format and features are active. Skipping this step is a common way to strand yourself between versions.

db.version()
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

mongodump --uri="mongodb://localhost:27017" --out=/backup/mongo_$(date +%F)

db.adminCommand({ setFeatureCompatibilityVersion: "7.0" })

Only raise the FCV once you're confident you won't need to roll back — once you're on the new feature compatibility version, downgrading the binaries without complications is much harder.

Benchmark Before and After, Or You're Guessing

The original case for these migrations isn't just "avoid the EOL cliff" — it's that a properly executed upgrade usually comes with a real performance return, and you can't claim that return if you never measured the baseline.

sysbench oltp_read_write --db-driver=mysql \
  --mysql-host=localhost --mysql-user=root --mysql-password=$PW \
  --tables=10 --table-size=100000 prepare
 
sysbench oltp_read_write --db-driver=mysql \
  --mysql-host=localhost --mysql-user=root --mysql-password=$PW \
  --tables=10 --table-size=100000 --time=60 --threads=8 run

pgbench -i -s 50 mydb
pgbench -c 8 -T 60 mydb

redis-benchmark -q -n 100000

Run these before the migration, keep the output, run the identical commands after cutover, and you've got a real before-and-after instead of a vague sense that things feel faster.

Building an Actual Timeline

The pattern that works across all four engines is roughly the same, and it maps directly to what teams like Percona's community leadership have been advising for this exact wave of EOL dates: don't treat this as a single cutover event, treat it as a staged project with real internal deadlines.

• Inventory everything first. You cannot plan a migration for systems you don't know you're running.
• Move test and development instances early. They're lower risk and give you real signal before production is on the line.
• Benchmark before you touch production. No baseline, no way to prove the upgrade delivered anything.
• Stage production behind a compatibility check. mysqlsh util check-for-server-upgrade, pg_upgrade --check, and MongoDB's FCV gate all exist specifically to catch problems before they're expensive.
• Budget for the unexpected. Every migration turns up at least one edge case that wasn't in the plan — deprecated syntax nobody remembered was in use, a driver version that doesn't support the new protocol, a monitoring agent that breaks silently. Build slack into both the timeline and the budget.
• For mission-critical systems, give yourself up to twelve months, not six — sharded databases, clustered deployments, and anything with strict service-level commitments take longer to move safely than a single-server instance.

The Actual Risk of Doing Nothing

MySQL 8.0's EOL date has already passed as of this writing. Every unpatched CVE discovered against it from here forward is a permanent exposure for anyone still running it in production without an extended-support contract. That's not hypothetical risk anymore — it's active. Redis 7.2 is in the same position. PostgreSQL 14 and MongoDB 6.0 still have a runway, but it's shorter than it looks once you account for testing, staging rollouts, and the inevitable slippage every real project experiences.

None of this requires panic. It requires a list, a backup, a staging environment, and a date on the calendar that isn't "eventually." The teams that treat 2026's EOL wave as a normal, plannable engineering project will get through it with a performance bump and a clean audit trail. The teams that treat it as next quarter's problem are the ones who'll be restoring from backup at the worst possible time, for reasons that were entirely foreseeable today.