MariaDB LTS Releases and Support Windows

MariaDB splits its releases into long-term support series, maintained for around five years, and rolling releases that live for about a year. For anyone running a database in production the LTS series is the only sensible choice, but the numbering does not make the distinction obvious. This article explains which versions are LTS, how long each is supported, and what has changed in the relationship between MariaDB and MySQL.

LTS and rolling releases

MariaDB publishes two kinds of release:

Nothing in the version number tells you which is which, so the designation has to be looked up. Recent LTS series include 10.6, 10.11 and 11.4, with 11.8 following as the next long-term series. Versions in between are rolling releases.

The practical guidance is straightforward: run an LTS series in production, and treat rolling releases as you would a beta - useful for evaluating something specific, not for a system you intend to leave alone.

What a support window covers

Within an LTS series, maintenance releases (11.4.1, 11.4.2 and so on) deliver bug fixes and security fixes. New features are not added to an LTS series after it is declared stable, which is exactly what makes it suitable for long-lived deployments.

Quarterly maintenance releases are the normal rhythm, with out-of-band releases for serious security issues. As with any database, applying maintenance releases promptly is low risk and high value, because they do not change behaviour.

The relationship with MySQL

MariaDB began as a fork of MySQL and retained drop-in compatibility for years. That is no longer a safe assumption. The two have diverged in areas including:

• JSON handling. MySQL has a native JSON type; MariaDB implements JSON functions over a text type with a check constraint.
• Authentication plugins and defaults, which differ enough to matter for client configuration.
• Replication. MariaDB uses its own global transaction ID implementation, which is not interchangeable with MySQL’s.
• System tables and information schema, where columns and views have diverged.
• Storage engines. MariaDB ships Aria, ColumnStore and others; MySQL’s InnoDB has evolved separately.
• Feature sets such as system-versioned tables, sequences and temporal queries, which exist on one side only.

Applications using plain SQL and a well-behaved driver usually move without trouble. Anything that touches replication, administrative tooling, or vendor-specific SQL needs testing rather than assumption.

-- MariaDB system-versioned tables, with no MySQL equivalent
CREATE TABLE accounts (
  id INT PRIMARY KEY,
  balance DECIMAL(12,2)
) WITH SYSTEM VERSIONING;

SELECT * FROM accounts FOR SYSTEM_TIME AS OF TIMESTAMP '2026-01-01 00:00:00';

Upgrading between LTS series

MariaDB supports upgrading one major series at a time. The process is conventional:

1. Take a verified backup.
2. Read the incompatible changes section of the release notes for every series you are passing through.
3. Install the new binaries and start the server.
4. Run mariadb-upgrade, which updates system tables and checks for tables needing rebuild.

mariadb-upgrade --user=root --password

Downgrades are not supported, so the backup is the rollback plan. For replicated setups, upgrade replicas before the primary so that the older primary is never replicating into a newer replica than it expects.

Recent direction

Work across recent series has concentrated on optimiser improvements, better handling of large workloads, continued development of system-versioned and application-time period tables, vector search support for similarity queries, and steady improvements to InnoDB performance and instrumentation.

Choosing a version

• New deployments: the most recent LTS series.
• Existing deployments: plan a move before the current LTS series reaches end of life, allowing time for testing rather than arriving at the deadline.
• Evaluating a specific new feature: a rolling release in a non-production environment, with the expectation of moving to the LTS series that follows it.
• Distribution packages: check what your distribution ships. An LTS distribution may package an older MariaDB series and maintain it on its own schedule, which can be a longer or shorter window than upstream.

Conclusion

MariaDB’s release model rewards knowing which series is LTS, because the version numbers do not say. Run an LTS series, apply its quarterly maintenance releases, upgrade one series at a time with a verified backup, and stop assuming drop-in compatibility with MySQL - the two projects have been diverging for long enough that the differences now need testing.