MariaDB End-of-Life Dates —
Official EOL Schedule for Every Version

MariaDB 10.6 LTS reaches end of life on July 6, 2026 — less than seven weeks away. If you're running 10.6 in production, that's your most immediate action item. MariaDB 10.4 and 10.5 are already past EOL. And the shift from the 10.x to 11.x series has caught many teams off guard — the LTS release cadence changed, and the upgrade path is not always obvious.

This page is the single reference for MariaDB end-of-life dates across every version — with EOL Risk Scores™, LTS vs rolling release explained, and a plain-English upgrade guide.

Complete MariaDB EOL Schedule

MariaDB maintains two types of releases: LTS (Long-Term Support) releases with multi-year support windows, and rolling releases with short support windows of one to two years. Most production databases should be on an LTS release. Rolling releases are for teams that want access to new features faster and are prepared to upgrade frequently.

LTS vs Rolling Releases — What It Means for EOL

MariaDB's versioning changed significantly with the 11.x series, and understanding it is essential for EOL planning.

LTS releases (10.4, 10.5, 10.6, 10.11, 11.4, 11.8, and future 12.3+) receive 5 years of support. These are the versions you should be running in production. The .3 release designation within each major version series is the LTS version going forward.

Rolling releases (10.7, 10.8, 10.9, 10.10, 11.0, 11.1, 11.2, 11.3, 11.5, 11.6, 11.7, 12.0, 12.1, 12.2) receive only 1–2 years of support. They are feature preview releases meant for teams that want to test upcoming functionality. Running a rolling release in a production database is a common mistake — it looks like a newer version but has a shorter support window than the LTS it preceded.

MariaDB 10.6 LTS — EOL July 6, 2026

MariaDB 10.11 LTS — Supported Until February 2028

MariaDB 11.4 LTS — Supported Until May 2029

MariaDB 11.8 LTS — Current Recommended Version

MariaDB vs MySQL — EOL Implications

MariaDB started as a MySQL fork in 2009 when Oracle acquired MySQL. The two databases have diverged significantly since then — particularly in the 10.x and 11.x series — but many teams still run MariaDB on infrastructure originally provisioned for MySQL, and the MySQL vs MariaDB EOL question comes up frequently in upgrade planning.

They are not interchangeable at EOL. A MySQL 8.0 EOL date does not apply to MariaDB 10.6, and vice versa. The databases have different release schedules, different LTS policies, and different vendor support structures. If your infrastructure documentation says "MySQL compatible" but you're running MariaDB, you need to track MariaDB EOL dates specifically.

Migrating from MariaDB to MySQL (or vice versa) at EOL is high risk. If your team is considering a database swap as part of an EOL migration, treat it as a full database migration project — not a version upgrade. Schema compatibility issues, replication format differences, and application query behavior can all differ in ways that don't surface until production load hits.

Amazon RDS for MariaDB has its own EOL schedule. If you're running MariaDB on Amazon RDS, check the RDS for MariaDB support dates separately — they trail community EOL dates by months in some cases. Check the EOL Checker for RDS-specific dates.

How to Upgrade Safely

• 01
  Confirm your current version and release type Run SELECT VERSION(); on your database. Cross-reference the version number against the table above — confirm whether you're on an LTS or rolling release. If you're on a rolling release that's already past EOL, you may not have noticed because the version number looks "newer" than an LTS still in support.
• 02
  Choose your target version For most teams on 10.6: upgrade to 10.11 for a conservative step, or 11.4 for the best long-term position. For teams on 10.4 or 10.5: go directly to 11.4 or 11.8 — you're already multiple versions behind and a two-step upgrade through 10.11 adds unnecessary complexity.
• 03
  Run mysql_upgrade and check for incompatibilities MariaDB provides mariadb-upgrade (formerly mysql_upgrade) to update system tables and check for incompatibilities. Run this in your staging environment first. Pay attention to any deprecated functions, removed storage engines, or changed SQL mode defaults that your application may be relying on.
• 04
  Test replication carefully If you're running replication, upgrade replicas before the primary. Mixed-version replication (primary on newer version, replicas on older) is supported during the upgrade window but should be temporary. Validate that binary log format and GTID settings are consistent across the topology after upgrade.
• 05
  Back up before every step Take a full backup with mariabackup or mysqldump before upgrading. Test that the backup restores successfully. This sounds obvious but is skipped more often than it should be — especially under audit-driven upgrade pressure.
• 06
  Consider commercial extended support if you need time MariaDB Corporation offers Enterprise support with extended lifecycle for LTS versions — 2 additional years standard, up to 5 years with extended options. If your migration from 10.6 will run past July 6, evaluate whether enterprise support is worth the cost versus accelerating the upgrade timeline.