Two weeks ago, on July 6, 2026, MariaDB Community Server 10.6 reached end of life. The MariaDB Foundation announced this back in June and gave people several months to plan. Some planned. Many did not. If you are in the second group, here is what you need to know.

What “End of Life” Actually Means for a Database

End of life does not make your database stop working. Queries keep returning rows, your application keeps humming along, and nothing explodes on day one. What stops is the flow of security patches, bug fixes, and corrective releases from the MariaDB Foundation. The 10.6 branch is now frozen.

The danger arrives later, when a new vulnerability is found in MariaDB — and new ones are found regularly, as we have covered before. The supported branches (10.11, 11.4, 11.8, 12.3) will receive a fix. The 10.6 branch will not. Because patch releases are public, attackers can study exactly what code changed and work backwards to construct an exploit. EOL systems are sitting ducks for exactly this pattern.

A Brief History of the 10.6 LTS

MariaDB 10.6 launched on July 6, 2021, as a Long-Term Support release under MariaDB’s previous release model. It was a five-year window, by the numbers the longest 10.x series that actually ran its full course. It became a common default in hosting stacks precisely because it was stable and well-maintained over its run.

It has been a solid release. That does not keep it alive.

What Is Still Supported

The MariaDB Foundation currently maintains four community LTS branches:

  • 10.11 LTS — supported until February 16, 2028
  • 11.4 LTS — supported until May 29, 2029
  • 11.8 LTS — supported until June 4, 2028
  • 12.3 LTS — the newest LTS, released May 28, 2026, supported until approximately May 2029

Note that 10.4 and 10.5 crossed their EOL lines in 2024 and 2025 respectively, so the entire pre-10.11 lineup is now unsupported community software. If you are still running 10.5 anywhere, that conversation is already overdue.

The Upgrade Path

MariaDB does not support skipping too many major versions in a single jump, so the typical path from 10.6 is:

10.6 → 10.11, then optionally 10.11 → 11.4 or 11.4 → 12.3

The 10.6 → 10.11 hop is the most common first step. On a well-maintained server with no exotic stored procedures, it tends to go smoothly. The bigger jumps into the 11.x series require more care: MariaDB 11.0 introduced a new optimizer cost model, and some queries can produce different execution plans than what you got on 10.6. Test against a staging copy before you touch production.

Before any upgrade:

  1. Run a full backup with mariadb-backup (or mysqldump if that is what you have).
  2. Review release notes for the target version, looking for removed or renamed system variables.
  3. Test application behavior against the new version in a staging environment.
  4. Have a rollback plan that does not depend on hoping things were fine.

After the upgrade completes, run mariadb-upgrade to update system tables.

The official upgrade documentation covers this in detail.

If You Cannot Upgrade Right Now

Rushed database upgrades are expensive. An upgrade that cuts corners on testing and lands bad execution plans in production can cost more in incident response than a few extra months of planning would have. That is a real trade-off, not an excuse.

Options if you are not ready:

  • MariaDB Enterprise Server 10.6 — MariaDB plc’s commercial build extends support for 10.6 until August 23, 2029. It is a paid product but requires zero application-level changes since it stays on the 10.6 series.
  • TuxCare Endless Lifecycle Support — TuxCare offers patched 10.6 binaries as drop-in replacements through your existing package manager. This buys time without forcing a migration before you are ready.

Neither option replaces an actual upgrade. Both options are better than running unpatched 10.6 because the calendar said to upgrade and your team was not ready.

What This Means for kalfaoglu.net Customers

Shared hosting customers: Your database version is managed by us. We handle the MariaDB stack on shared servers, so you do not need to take any action. If your application uses SQL that was valid in 10.6 but is deprecated or removed in newer versions, we will contact you before we upgrade your hosting server — that kind of thing rarely causes issues, but we would rather give you advance notice.

VPS and dedicated server customers: This is on you. Check which version you are running:

mariadb --version

If it returns anything in the 10.6.x range, you are now running end-of-life software. Start planning the 10.11 upgrade now. If you need help with the upgrade procedure or want us to do it for you, open a support ticket and we will work through it together.

One thing worth noting: control panels (cPanel, Plesk, DirectAdmin) usually let you trigger a MariaDB upgrade from the panel UI. Check your panel documentation for the supported upgrade path — some panels may not support 11.x yet, which affects your target version selection.

The Bottom Line

MariaDB 10.6 had a good five-year run. The EOL date was known well in advance. If you are running it on a server you manage, now is a reasonable time to spend a weekend afternoon on the upgrade rather than a frantic evening after a disclosure. The supported targets are 10.11, 11.4, 11.8, and 12.3 — pick the one your environment can reach without heroics.