MariaDB 12.2 is dead, 10.11 lives until 2028: which MariaDB version belongs on a server

MariaDB 12.2 has had no fix since 28/05/2026. MariaDB 10.11 keeps getting them until 16/02/2028. The lower number is the one maintained longer, and with MariaDB that is not an accident, it is the model. Pick a version by the height of its number and you reliably land on the branch with the shortest remaining life.

Two kinds of release, one series of numbers

MariaDB ships quarterly. Once a year one of those releases is a long-term release (LTS), the rest are rolling releases — and the number does not tell you which kind you have. The maintenance policy spells out the three positions: a is the major series and grows yearly from MariaDB 12 on, b is the functional level and grows quarterly, c is the bug-fix level. Then comes the sentence everything hangs on: within a major series, the minor version with the largest b is the LTS branch. From MariaDB 12 that means the .3 is the LTS — 12.0, 12.1 and 12.2 were rolling, 12.3 is the long-term one. The LTS sits at the end of a series, not at its start.

The two kinds carry different promises. An LTS gets community binaries for three years after its GA date (up to and including 11.4 it was five); afterwards critical and security fixes continue for two more years, but only as source. A rolling release gets no promise in years at all — it ends when the next one arrives. The cycle data shows exactly that: 12.1 ended on 13/02/2026, the release day of 12.2, and 12.2 ended on 28/05/2026, when 12.3 came out.

What runs how long

The third row is worth reading twice. 11.8 is a year younger than 11.4 and still ends a year earlier, because up to and including 11.4 the binaries were built for five years and since then for three. So an estate on 11.4 has nothing to do until 2029, while one that dutifully moved to 11.8 must act in 2028.

What is actually running

Only the first two positions answer the support question. The third tells you how current your bug-fix level is inside the branch — a different question, and the one that comes up far more often.

• On the server: mariadbd --version. In the vendor’s own container the output begins mariadbd Ver 11.8.8-MariaDB-ubu2404.
• With only an SQL login: SELECT VERSION();
• Where the package came from: apt policy mariadb-server or rpm -q mariadb-server. A suffix such as 0+deb12u1 means a distribution build, not a vendor package — and then the next section applies.
• In a container, ask the binary rather than the tag: docker exec <name> mariadbd --version. Per the official image description, latest is the latest stable version and lts the last long-term release — two different things that happen to point at the same number today.

The distribution trap

Most installations never chose their branch, they inherited it. Debian 13 (trixie) ships 11.8.6, Debian 12 (bookworm) 10.11.18; Ubuntu 24.04 LTS ships 10.11 from universe; AlmaLinux 10 ships 10.11 as well. And apt upgrade never changes the branch: between two bug-fix levels of the same branch lies a security fix, between 10.11 and 11.4 lies a distribution upgrade or a third-party repository.

That leaves two clocks. Debian 12 fell out of regular maintenance on 11/07/2026 and is carried by the LTS team to 30/06/2028, while its 10.11 ends upstream on 16/02/2028 — a good four months earlier. Debian 13 runs to 09/08/2028, its 11.8 ends upstream on 04/06/2028. Distributions pick a branch that roughly matches their own lifetime; roughly is not identical, and in the gap you depend on what the distribution’s security team still backports.

Ubuntu adds a second catch: Canonical’s free five-year commitment covers packages in main, and MariaDB sits in universe, which is covered through Ubuntu Pro. Anyone relying on “24.04 is supported for five years” is relying, for this database, on a promise made about a different set of packages.

Which version belongs on the server

• Free choice on a fresh install: the newest long-term release. That is 12.3, community support to 12/06/2029.
• Using distribution packages — easier, and right for most estates: keep their branch and remember its two end dates instead of its version number.
• Rolling releases belong on test systems. They are not unstable; they commit you to changing branch every quarter.
• When upgrading, compare end dates, not numbers. From 10.11 to 11.8 buys three and a half months. From 10.11 to 11.4 — the older release — buys fifteen.

What an LTS actually needs from you

A long-term release is not software that stands still for three years. It lives on its patch releases, the third position, and those keep coming quarterly: the 10.11 from 2023 is 10.11.18 today. So the date that concerns you is rarely the end of support three years out — it is the day the next bug-fix level of your branch appears. That is the part patchletter watches. The MariaDB product page lists the tracked cycles with their end dates, the newest recorded version being 12.3.2 from 28/05/2026; tick the product and you get an email when a new one appears — free, no account, one-click unsubscribe. For what runs out first across everything you operate, there is the end-of-life overview.

The honest limitation

The dates above are what the MariaDB Foundation publicly commits to, and the same page says they are not legally binding. The period has already been shortened once, from five years to three; that can happen again, in either direction. The “.3 is the LTS” rule applies from series 12 onwards and is an announcement about series still to come, not evidence: the vendor’s own downloads interface still lists 13.0 as a release candidate, and a date for 13.3 exists only in the cadence chart. That same interface also gives 11.8 an end date of 13/02/2030 while the maintenance policy says 04/06/2028; for every other branch the two agree. When planning, take the earlier date.

And what patchletter explicitly does not do: it reports new releases, not end-of-support dates. The cycles are there to read, but nothing rings on 16/02/2028. Our own dataset also holds only the branches from 11.1 up — the 10.11 and 10.6 rows above come from the vendor, not from us.

Maintenance periods, numbering scheme and the footnote on the change from five years to three: the MariaDB Foundation’s maintenance policy, retrieved 19/08/2026. Package states: Debian package tracker, Launchpad and the AlmaLinux 10 AppStream; distribution lifetimes: debian.org and Canonical; series status and the diverging end dates: the vendor’s downloads interface; tag meanings: the official Docker image description — each linked above. The rolling-release cycles 12.1 and 12.2 and the recorded version 12.3.2 come from our own dataset as of 19/08/2026. For any date with consequences, the vendor page decides.