MariaDB 10.6 End of Life: The Honest Upgrade Guide

If you run MariaDB in production, there’s a decent chance you’re on 10.6 right now and don’t know it. It’s the default in Ubuntu 22.04’s repos, it ships with Debian 12, it’s in the RHEL 9 AppStream, and it’s been a popular pick on managed RDS for years. It’s been the boring, reliable choice since 2021.

That run ends July 6, 2026. After that date, MariaDB 10.6 Community stops getting security patches. No more CVE fixes, no more bug backports. The binary keeps running — nothing dramatic happens at midnight — but every vulnerability disclosed after that date stays open on your database forever.

And here’s the part that turns “I’ll get to it eventually” into “I need to schedule this”: if you’re under SOC 2, PCI-DSS, or HIPAA, an end-of-life database is an audit finding. Your auditor doesn’t care that it still works. They care that it’s unsupported. So this is worth doing on your own timeline instead of three days before an audit.

Where you’re probably running 10.6 without realizing

The annoying thing about 10.6 is that it crept into a lot of stacks as a default, not a decision. A few places to check:

• Ubuntu 22.04 LTS — apt install mariadb-server gives you the 10.6 line.
• Debian 12 (Bookworm) — same story, 10.6 is the packaged version.
• RHEL 9 / Rocky / Alma AppStream — the default MariaDB module is 10.5 or 10.6 depending on when the stream was cut.
• Amazon RDS and Aurora — plenty of instances were spun up on 10.6 when it was the newest LTS, and nobody’s touched the engine version since.
• Bitnami / Docker images — older mariadb:10.6 tags are pinned in more Compose files than anyone wants to admit.

Quick check: mysql --version or SELECT VERSION();. If it starts with 10.6, you’re on the clock.

The version that confused everyone: 10.6 is a 5-year LTS

Before picking a target, one thing worth understanding because it explains the whole mess. MariaDB used to give LTS releases five years of community support. 10.6 came out July 6, 2021, so it gets patches until July 6, 2026 — a clean five years.

But MariaDB quietly changed that policy. Newer LTS releases only get three years of community support. This matters more than it sounds, and I’ll come back to it, because it means the newest version is not automatically the one with the longest runway.

Pick your target: 10.11 vs 11.4 vs 11.8

Three LTS releases are realistic landing spots. Here’s how their support windows actually shake out at the community level:

Look at that table for a second, because the obvious move is wrong. You’d assume 11.8 — the newest — buys you the most time. It doesn’t. Because the support policy dropped to three years, 11.8 expires in June 2028. 11.4 runs to May 2029, a full year longer than the newer release. If your goal is the longest stretch before you have to do this dance again, 11.4 is the answer, not 11.8.

So how I’d actually choose:

10.11 if you want the smallest possible jump. It’s the next LTS after 10.6, still inside the 10.x series, and the upgrade is about as low-drama as a major version bump gets. The catch is the short runway — you’d be back here in early 2028. I’d only pick this if you’re risk-averse, on a tight maintenance window, and fine repeating the upgrade in under two years.

11.4 if you want to do this once and forget about it. It crosses into the 11.x series, which means you inherit the rewritten optimizer (more on that next), but you get the longest community support of any current LTS. For most teams, this is the right call. One bigger jump now, no upgrade pressure until 2029.

11.8 only if you specifically need a feature that landed after 11.4. Vector search and some replication improvements arrived in the 11.5–11.8 range. If you’re building something that needs them, fine. Otherwise you’re taking a newer, less-battle-tested release and a shorter support window. Hard to justify for a plain production database.

My default recommendation: 11.4. Bite the optimizer bullet once and get the longest runway.

The thing nobody warns you about: the optimizer rewrite

Here’s where upgrading from 10.6 to anything 11.x gets interesting. MariaDB 11.0 shipped a rewritten query optimizer with a new cost model. This is the single biggest reason a “just bump the version” upgrade can blow up in staging.

The short version: the old optimizer used a mix of rule-based and cost-based logic, and a lot of its cost estimates were rough. In 11.0, the cost model was rebuilt so that storage-engine operations are pinned to a real unit (roughly 1ms), and decisions that used to be rule-based — like whether to use an index or a filesort for ORDER BY and GROUP BY — are now cost-based.

In aggregate, this makes query plans smarter. But “smarter on average” is not “better for every query.” Some of your queries will get faster. A few might get slower, because the optimizer now picks a different index, or switches from an index scan to a filesort, or reorders a join in a way that happened to be worse for your specific data distribution.

This is not a reason to avoid 11.x. It’s a reason to test like you mean it:

1. Capture your real query workload before you upgrade — slow query log, or better, a representative set of your heaviest production queries.
2. Run EXPLAIN (or ANALYZE) on a 10.6 copy and an 11.4 copy and diff the plans. Plan changes are where regressions hide.
3. Run ANALYZE TABLE on your big tables right after upgrading. The new cost model leans harder on accurate statistics, and stale stats from the old version will steer it wrong.
4. Watch p95/p99 latency, not just averages, for a week after cutover. A regression on one hot query won’t move the mean but will absolutely show up in your tail.

If you go to 10.11 instead, you mostly sidestep this — the big optimizer rewrite is a 11.0 thing. That’s a legitimate point in 10.11’s favor if your workload is full of hand-tuned queries you’re scared to disturb. Just remember you’re trading that safety for a 2028 expiry.

The actual upgrade: in-place vs dump-and-restore

Two paths, and the right one depends on how far you’re jumping and how much you trust your backups.

In-place upgrade is the standard route for self-managed servers. Roughly:

1. Take a full backup. Then take another one. (mariabackup or mysqldump — I’ll trust you here, but do not skip this.)
2. Stop the application traffic or put the DB in maintenance.
3. Upgrade the packages — but one major version at a time. Going 10.6 → 10.11 → 11.4 is the supported, sane path. Jumping straight 10.6 → 11.4 by swapping repos and praying is how you find undocumented system-table issues at 2am.
4. Start the new server and run mariadb-upgrade (the binary that fixes system tables, the mysql/performance_schema schema, and privilege tables for the new version). This step is not optional and is the one people forget.
5. Run ANALYZE TABLE on major tables, smoke-test the app, watch the logs.

Dump-and-restore — export with mysqldump/mariadb-dump, spin up a fresh new-version server, import — is slower and means more downtime, but it gives you the cleanest result and a trivially obvious rollback (the old server is untouched). I lean toward this when crossing multiple major versions or when the dataset is small enough that the import time isn’t painful.

Things that actually bite people during the jump:

• Authentication plugins. If you’ve got users on older auth methods, check they’re still valid on the target. The mysql_native_password situation has been shifting across versions.
• Deprecated SQL modes and removed variables. Config options that were warnings in 10.6 can be hard errors later. Start the new server with your old my.cnf in staging and read every line of the error log before you trust it.
• Replication topology. Upgrade replicas before the primary, and never replicate from a newer primary to an older replica across a major version.

The managed angle: RDS and Aurora MariaDB

If you’re on Amazon RDS for MariaDB, the calendar is slightly different and the escape hatch you might be counting on isn’t there.

RDS end of standard support for MariaDB 10.6 lands at the end of July 2026, give or take, tracking close to the community date. The wrinkle: RDS Extended Support — the paid “keep running the old version for up to three more years” program — is documented for MySQL and PostgreSQL, not MariaDB. AWS’s own Extended Support pages reference the MySQL and PostgreSQL release calendars and leave MariaDB out.

What that means in practice: on MySQL or Postgres, blowing the deadline just means a surprise per-vCPU-hour surcharge while you keep limping along. On MariaDB, there’s no paid grace period to fall into — when standard support ends, RDS will automatically upgrade your engine version for you. An auto-upgrade on AWS’s schedule, not yours, is exactly the kind of thing you want to get ahead of. Check your specific instance’s support dates in the RDS console (the “Viewing support dates” page), don’t take my word for the exact day, and plan a controlled upgrade well before it.

The escape hatches (and when they’re worth it)

Say you genuinely can’t upgrade in time — a vendor app certified only against 10.6, a frozen system you can’t touch. You’ve got two real options:

MariaDB Enterprise Server 10.6. The Enterprise build of 10.6 is supported all the way to August 2029. Same engine, same major version, your app doesn’t change — you’re just paying for three more years of backported security fixes. If a certification freeze is your blocker, this is the cleanest answer, assuming the licensing cost is less painful than the upgrade.

Third-party extended support, e.g. TuxCare. TuxCare announced “Endless Lifecycle Support” for MariaDB Community 10.6, delivering security patches past the July 2026 EOL without an Enterprise license or a version change. It’s the budget version of the same idea — keep getting CVE fixes while you buy time. Worth a look if Enterprise pricing doesn’t fit.

Both of these are time-buying, not solutions. They keep you patched; they don’t move you forward. Use them to schedule the real upgrade, not to avoid it.

A pre-flight checklist

Before you touch production:

• Confirm you’re actually on 10.6 (SELECT VERSION();) and inventory every instance — the forgotten replica is the one that bites.
• Pick your target (probably 11.4 for the runway, 10.11 if you can’t risk the optimizer change).
• Capture a representative query workload from 10.6.
• Stand up a staging copy on the target version; diff EXPLAIN plans against 10.6.
• Start it with your real config and read the full error log.
• Verify two independent, restorable backups.
• Write the rollback steps down before you start, not during the incident.
• Schedule the window. Upgrade replicas first, primary last.

The honest takeaway: this is a routine upgrade with two real traps — skipping mariadb-upgrade, and assuming the optimizer behaves like it did on 10.6. Handle those two and the rest is mechanical. Pull a copy of your top twenty slowest queries onto an 11.4 instance this week and diff the plans. Whatever you learn there tells you exactly how big a deal this upgrade is for your workload — which is the only version of the answer that matters.

Sources worth bookmarking: endoflife.date/mariadb for the version calendar, MariaDB’s own EOL notice for 10.6, the 11.0 optimizer cost model docs, and AWS’s RDS Extended Support page.