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.
Applies to MariaDB 10.6 to 11.8 (cPanel 136+) or 12.3 (DirectAdmin CustomBuild 1.696+ and standalone)
Table of Contents
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 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 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 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 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 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/*.cnfAnything 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 mariadbDo the version change through the panel or package manager, start the service, then:
mariadb-upgrade
systemctl restart mariadbmariadb-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.
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-upgradeThe 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 maps out the dates.
MariaDB 10.6 end of life at a glance
Official documentation: MariaDB documentation, endoflife.date, Linux man pages.
Related guides: Converting MySQL to MariaDB (and why in-place switching is no longer supported) · Upgrading MariaDB in WHM safely: backups, slow shutdown and mariadb-upgrade · MySQL 8.0 is end-of-life: moving cPanel servers to MySQL 8.4 or MariaDB.
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.
Maintenance record
This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.
- Maintained by
- srvScripts editorial team
- Supported versions
- MariaDB 10.6 to 11.8 (cPanel 136+) or 12.3 (DirectAdmin CustomBuild 1.696+ and standalone)
- Last full review
- Next review
- Sources
- mariadb.com/docs