MariaDB End of Life: 10.6 EOL and Dates for Every Version

MariaDB 10.6 reached community end of life on 6 July 2026, MariaDB 10.5 on 24 June 2025 and MariaDB 10.4 on 18 June 2024. The community series still maintained are the long-term releases 10.11, 11.4, 11.8 and 12.3, plus the 13.x rolling releases for a few months each. The dates below come from the MariaDB Foundation's maintenance policy on mariadb.org, checked on 12 October 2026, together with MariaDB plc's engineering policy for Enterprise Server and the Amazon RDS calendar.

The MariaDB maintenance policy in the project's words

The MariaDB Foundation maintenance policy announces a new long-term release (LTS) every year and a rolling release every quarter. Community LTS binaries are published for three years after GA, and releases up to 11.4 got five. That is why 11.8 reaches community end of life on 4 June 2028, before 11.4 on 29 May 2029. For the three-year releases the Foundation says the source release period is unchanged: critical and security fixes continue in source releases for two further years. Rolling releases are maintained only until the next one replaces them. The Foundation describes all of these dates as public policy, not legally binding. When it retired 10.6, it said there would be no more bug fixes, security fixes or corrective releases for that branch after 6 July 2026.

MariaDB end of life dates by version

Checked against the MariaDB Foundation maintenance policy on 12 October 2026. The rolling table lists only 13.0 and 13.1, so a server on an earlier rolling series such as 12.0 to 12.2 is outside maintenance, just as one on 10.6 is.

MariaDB plc Enterprise Server has its own lifecycle

MariaDB Enterprise Server is a separate product from MariaDB plc, and its lifecycle is set in the MariaDB plc Engineering Policy (version 4.33, 17 July 2026). Enterprise Server 10.6, which went GA on 23 August 2021, has standard support to 23 August 2027 and end of life on 23 August 2029. Enterprise Server 11.4 (16 January 2025) runs to 16 January 2030 and 16 January 2033, and 11.8 (22 October 2025) to 22 October 2030 and 22 October 2033. After standard support a release enters extended support, which gives security fixes and highly critical bug fixes until end of life, for additional fees from MariaDB plc. So the vendor route past July 2026 for 10.6 is a paid subscription, not the community build.

Where your MariaDB comes from decides who patches it

A server installed from a distribution or a cloud service follows that vendor's calendar, not the Foundation's. Amazon RDS for MariaDB lists 31 December 2026 as the end of standard support for 10.6, and its version page does not mention extended support for MariaDB. RHEL 9 ships MariaDB 10.5 as part of its base Application Streams, and Red Hat's Application Streams page lists retirement dates of May 2028 for the 10.11 stream and September 2028 for 11.8. Check the packaging before you decide a server is unpatched, and check it again before you decide it is covered.

Why upgrading off MariaDB 10.x is not one jump

The MariaDB documentation says that skipping intermediate major or LTS versions is supported and tested for standalone servers, but a rolling upgrade of a Galera cluster must go one major or LTS version at a time, and you must read the incompatible-changes section for every version in between. Each step has its own traps:

• 10.5 to 10.6. OFFSET becomes a reserved word, utf8 becomes an alias for utf8mb3 (controlled by old_mode), innodb_flush_method defaults to O_DIRECT, and a long list of InnoDB options, including innodb_buffer_pool_instances and innodb_log_files_in_group, is removed and must come out of my.cnf. See upgrading from 10.5 to 10.6.
• 10.6 to 10.11. InnoDB or Mroonga tables that used a non-zlib compression algorithm are unreadable until the matching compression library is installed. See upgrading from 10.6 to 10.11.
• 10.11 to 11.4. The innodb_defragment options and old_alter_table are removed. The optimizer cost model changed in MariaDB 11.0, so query plans can change. From 11.4 the server enables SSL by default with a generated self-signed certificate, and clients verify the server certificate by default, so old client configurations can fail at connect time.
• 11.4 to 11.8. Changes to innodb_snapshot_isolation make REPEATABLE READ transactions more likely to hit ERROR 1020 on bulk UPDATE and DELETE statements. See upgrading from 11.4 to 11.8.

After installing new binaries, run mariadb-upgrade. Take a backup first, rehearse on a restored copy, and keep the old version until cutover is done.

What running an end-of-life MariaDB risks

• Security fixes stop. A vulnerability disclosed next year is fixed in the maintained series and left open in 10.6, 10.5 and 10.4.
• Bug fixes stop. Defects in InnoDB recovery, replication or Galera state transfer are fixed forward, not backported.
• Compatibility narrows. Newer connectors, proxies and backup tools are tested against the maintained series, not against 10.4 to 10.6.
• Audits flag it. An unsupported database holding customer data is a finding in most compliance regimes.

The incidents that show up on older MariaDB estates

• Galera nodes that will not rejoin. A node keeps failing state transfer, or the cluster drops to non-Primary after a network partition, and writes stop until quorum is restored by hand.
• Flow control stalls. One node on slow storage, or one very large transaction, makes Galera flow control pause every writer, so the slowest node sets the write speed of the whole cluster.
• Replica lag that never recovers. Under row-based replication, every row event against a table with no primary key can mean a full table scan on the replica, and parallel apply does not fix that.
• Disks that fill. Binary logs with long retention, or a long-running transaction that stops InnoDB purge and lets undo grow, take the server offline at 100 percent.

None of these is caused by end of life. What end of life changes is that a defect fix will only ever ship in a series you are not running. That is the case for having MariaDB support in place on the series you have while the upgrade is planned.

Your options

• Keep the series you run, and keep it patched. OSSeva, AceMQ's extended support platform, provides patched builds of MariaDB 10.4, 10.5 and 10.6 after community maintenance ends, as signed DEB and RPM packages, tarballs and container images in the same series, with the same data directory and configuration. It also supports the 10.11, 11.4, 11.8 and 12.3 LTS lines. Coverage is as listed on OSSeva's page, last reviewed 29 September 2026, and the OSSeva MariaDB EOL page shows every series.
• Upgrade to a maintained LTS. The Foundation names 10.11, 11.4, 11.8 and 12.3 as suitable targets depending on environment. 12.3 is maintained to 12 June 2029; 10.11 only to 16 February 2028, so an upgrade to 10.11 means doing this again in about 16 months.
• Buy vendor extended support. MariaDB Enterprise Server 10.6 runs to 23 August 2029 under MariaDB plc's policy, for a fee, and stays on the same series.
• Use a managed service. Amazon RDS handles patching, but 10.6 there reaches end of standard support on 31 December 2026.
• Get support for the version you run. AceMQ provides 24/7 MariaDB support for Galera, replication and MaxScale on any series, with a 15-minute emergency SLA, and plans and rehearses the upgrade. The wider picture is in database support.

Start by finding out what you have. Run SELECT VERSION(); on every server, and on Galera nodes SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size';. Record whether each server came from the MariaDB repositories, a distribution package or a cloud service, because that decides who patches it. If the upgrade also makes you ask whether to stay on this engine family, see MySQL end of life and PostgreSQL vs MySQL. For the other technologies AceMQ and OSSeva cover past end of life, see end-of-life software support.

• MariaDB Foundation: Maintenance policy and release table
• MariaDB Foundation: MariaDB Server 10.6 reaches end of life on July 6th
• MariaDB plc: Engineering Policy (Enterprise Server lifecycle)
• MariaDB documentation: General upgrade information
• MariaDB documentation: Upgrading from 10.5 to 10.6
• MariaDB documentation: Upgrading from 10.6 to 10.11
• MariaDB documentation: Upgrading from 10.11 to 11.4
• MariaDB documentation: Upgrading from 11.4 to 11.8
• MariaDB documentation: What is MariaDB 11.4
• MariaDB documentation: What is MariaDB 11.0
• AWS: MariaDB on Amazon RDS versions
• Red Hat: Enterprise Linux Application Streams life cycle
• OSSeva: MariaDB extended support
• OSSeva: MariaDB end of life dates