# MariaDB 10.6 End of Life: Safe Upgrade Paths to 11.8 or 12.3

Source: https://srvscripts.com/guides/mariadb-10-6-end-of-life/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

MariaDB 10.6 reached end of life on 6 July 2026 with 10.6.28 as its final release. Any server still on it is now running a database with no security updates, which for a hosting provider is a compliance problem as much as a technical one. The project’s guidance is to move 10.6 users to either 11.8, the LTS supported until June 2028, or 12.3, the LTS released in May 2026 and supported until June 2029. Which one you pick depends less on features than on what your control panel supports today and how far you want the next upgrade to be.

In short: Move 10.6 servers to MariaDB 11.8 on cPanel, where WHM’s upgrade interface jumps directly and 12.3 is not yet offered, and to 12.3 on DirectAdmin and standalone servers, stepping through 10.11 and 11.4 with CustomBuild rather than skipping.

**Short answer:** Move 10.6 servers to MariaDB 11.8 on cPanel, where WHM’s upgrade interface jumps directly and 12.3 is not yet offered, and to 12.3 on DirectAdmin and standalone servers, stepping through 10.11 and 11.4 with CustomBuild rather than skipping. Before each hop, remove the variables 10.6 tolerated but later versions reject, search customer schemas for the new reserved words, take a logical dump, and set `innodb_fast_shutdown = 0` for a clean stop; afterwards run `mariadb-upgrade` and `mariadb-check --all-databases --check-upgrade`.

## Establish where every server is

```
mariadb --version
mariadb -e "SELECT VERSION();"
mariadb -e "SHOW GLOBAL STATUS LIKE 'Uptime';"
```

On cPanel, `whmapi1 current_mysql_version` reports what the panel believes is installed, and on DirectAdmin `da build versions | grep -i mariadb` shows the CustomBuild selection. Across a fleet, collect the version into a spreadsheet; the [MySQL health snapshot script](/scripts/mysql-health-snapshot/) captures it alongside the status counters you will want for a before-and-after comparison.

## The two targets

11.8 is the safer target for cPanel servers. It is in the WHM upgrade workflow since cPanel 136, supported on AlmaLinux 8, 9 and 10 and Ubuntu 24.04, and its default-behaviour changes over 10.6 are the 11.4-series ones: `mariadb-*` command names as canonical, some optimizer defaults, and character-set defaults. 11.8 also brings the VECTOR type and the `VEC_DISTANCE_*` functions, which matter if any customer is running an AI-adjacent application.

12.3 is the longer-lived target and the one DirectAdmin’s CustomBuild has supported since 1.696. It adds `caching_sha2_password` as an authentication plugin, Oracle-compatibility syntax, the XML type, optimizer hints and a segmented Aria key cache, and it removes several old variables. Its extra year of support is attractive, but cPanel does not yet offer it, so on cPanel the decision is made for you: 11.8 now, 12.3 when WHM adds it. See [MariaDB 12.3: what changed and what breaks](/guides/mariadb-12-3-lts-what-breaks/) before choosing it anywhere.

## Hop sequences by platform

cPanel allows a direct jump from 10.6 to 11.8 through WHM’s MySQL/MariaDB Upgrade interface; internally it steps through the intermediate releases, running `mariadb-upgrade` at the end. It does not allow downgrades, so the backup is the only rollback. Our [safe WHM upgrade guide](/guides/upgrade-mariadb-whm-safely/) covers the run itself.

DirectAdmin’s CustomBuild expects you to step through LTS versions rather than skip: 10.6 to 10.11, then to 11.4, then 11.8 or 12.3, running `da build mariadb` at each step. Skipping steps sometimes works and sometimes produces a data directory the next version refuses; the time saved is not worth it. The [DirectAdmin upgrade guide](/guides/upgrade-mariadb-directadmin-custombuild/) has the exact commands.

Standalone servers using the MariaDB repository can jump directly in principle, since the on-disk format is upgraded by `mariadb-upgrade`, but the same caution about intermediate defaults applies. On a server with hundreds of customer schemas, step through 10.11 and 11.4 and run application smoke tests at each stop.

## What to test before the fleet

Pick one server that represents the fleet, clone it or restore a backup onto a staging host, and run the upgrade there first. Then check three things: removed variables in `my.cnf` that abort startup (our [unknown variable guide](/guides/mariadb-unknown-variable-after-upgrade/) lists them), reserved words that break customer queries (`ROW_NUMBER` from 10.7, `CONVERSION` and `TO_DATE` in 12.3), and application connector compatibility, particularly PHP `mysqlnd` against `caching_sha2_password` if you choose 12.3.

```
grep -E 'innodb_log_write_ahead_size|wsrep_strict_ddl|keep_files_on_create|big_tables|large_page_size|storage_engine' /etc/my.cnf /etc/my.cnf.d/*.cnf
```

Anything that command prints must be removed before the upgrade, not after.

## Preparation on each server

Before every hop, take a logical backup and a filesystem snapshot if the platform allows it, then set a slow shutdown so InnoDB flushes everything and the new version does not have to replay a redo log written by the old one:

```
mariadb-dump --all-databases --single-transaction --routines --events --triggers | gzip > /root/pre-upgrade-$(date +%F).sql.gz
mariadb -e "SET GLOBAL innodb_fast_shutdown = 0;"
systemctl stop mariadb
```

Do the version change through the panel or package manager, start the service, then:

```
mariadb-upgrade
systemctl restart mariadb
```

`mariadb-upgrade` rewrites system tables and checks every user table. It is idempotent and safe to run twice.

## Common pitfall

Upgrading the server and forgetting the clients. cPanel and DirectAdmin ship a compatible client library with the server, but customer applications bundled with their own drivers, external replication clients and backup tooling all need to be checked. A MySQL 5.7-era connector talking to MariaDB 12.3 will fail authentication for any account moved to `caching_sha2_password`; see [our compatibility guide](/guides/caching-sha2-password-mariadb-12/).

## Verify

After the upgrade and a few hours of production traffic:

```
mariadb -e "SELECT VERSION(); SHOW GLOBAL STATUS LIKE 'Threads_connected'; SHOW ENGINE INNODB STATUS\G" | head -40
tail -100 /var/lib/mysql/$(hostname).err | grep -iE 'error|warn'
mariadb-check --all-databases --check-upgrade
```

The version string should match the target, the error log should be free of repeated warnings, and `mariadb-check` should report every table as OK. Keep the logical backup for at least a week; if a customer discovers a broken query on day five, the dump is what you restore that one schema from. Then plan the next upgrade now: 11.8 leaves you a two-year window, 12.3 a three-year one, and the [support timeline guide](/guides/mariadb-support-timeline-2026-2029/) maps out the dates.

## MariaDB 10.6 end of life at a glance

**Official documentation:** [MariaDB documentation](https://mariadb.com/docs/), [endoflife.date](https://endoflife.date/), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [Converting MySQL to MariaDB (and why in-place switching is no longer supported)](https://srvscripts.com/guides/convert-mysql-to-mariadb-safely/) · [Upgrading MariaDB in WHM safely: backups, slow shutdown and mariadb-upgrade](https://srvscripts.com/guides/upgrade-mariadb-whm-safely/) · [MySQL 8.0 is end-of-life: moving cPanel servers to MySQL 8.4 or MariaDB](https://srvscripts.com/guides/mysql-8-0-end-of-life/).

## Frequently asked questions

### Can I upgrade MariaDB 10.6 directly to 11.8 or 12.3?

On cPanel, WHM handles a direct 10.6 to 11.8 jump by stepping through intermediate releases internally. On DirectAdmin, CustomBuild expects 10.6 to 10.11 to 11.4 and then 11.8 or 12.3. Standalone servers can jump in principle, but stepping through the LTS versions with tests at each stop is the safer route on a multi-tenant server.

### Should I choose MariaDB 11.8 or 12.3 after 10.6?

Choose 11.8 on cPanel, because WHM does not offer 12.3 yet and running an unsupported version by hand breaks the panel’s tooling. Choose 12.3 on DirectAdmin and standalone servers for the extra year of support, after checking for the `CONVERSION` and `TO_DATE` reserved words and `caching_sha2_password` client compatibility.

### Can I downgrade MariaDB if the upgrade goes wrong?

No. Neither the panels nor the on-disk format support going back once `mariadb-upgrade` has run, so the pre-upgrade logical dump and a filesystem snapshot are the only rollback. Rehearse on a staging clone of a representative server before touching the fleet.