How to Upgrade MariaDB 10.6 to 11.8: Pre-Upgrade Checklist

Everyone notices when an update breaks something. Nobody notices when their database quietly stops getting security fixes. The second problem is worse, and right now it applies to every MariaDB 10.6 server out there.

Anna Widenius, CEO of the MariaDB Foundation, just published Still on MariaDB 10.6? Why your next upgrade is a security decision. One line from it is worth printing out: "There will be no 10.6.29." Version 10.6 reached end of life on July 6, 2026, and its final release, 10.6.28, shipped on August 13. Every fix from now on lands in newer versions only.

Anna asked us to add the managed-provider view: how we handle MariaDB updates on Elestio, and what you should check before a major version jump. Here it is.

Why a Database Upgrade Is a Security Task

It's tempting to treat a database upgrade as a "when we have time" project. The Foundation's list of recent vulnerabilities argues otherwise. A few from the October 16, 2026 batch alone:

• CVE-2026-92262 (CVSS 9.9): a bypass through legacy #mysql50# table names, with possible remote code execution
• CVE-2026-85746 (9.9): a heap overflow in ST_AsText()
• CVE-2026-97380 (8.8): a GRANT PROXY flaw that lets a user change passwords on other accounts

The Foundation notes that most of these only need a low-privileged database login. Think about who holds one of those in your stack: the WordPress plugin you installed in 2022, the reporting tool, the intern's script. On 10.6, those holes stay open for good.

These are the maintained release lines today, according to the Foundation:

The good news: you can go straight from 10.6 to 11.8 or 12.3, no intermediate stop. The Foundation recommends 11.8 for most teams. It has been generally available for over a year and it's what most tooling targets now. Pick 12.3 if you'd rather get the longest runway out of a single migration.

How Elestio Handles MariaDB Updates

On Elestio, minor and major updates follow two different rules.

Minor updates are automatic. When you deploy MariaDB, you pick a version line. Software and OS updates are on by default and run in a maintenance window you control from the service dashboard (times are in UTC). That's how a 10.11 instance moves from 10.11.18 to 10.11.19 without you doing anything. You can also hit Update now and read the logs of past runs.

Major upgrades are your call. Auto updates stay inside the version line you picked, so a 10.6 instance never wakes up on 11.8. A major version can change defaults, remove options and break an application that worked yesterday, so the decision stays with you. When you're ready, you have two options:

1. Do it yourself from the dashboard. In your service overview, click Change version, select the new version, save, then click Update now under Software auto updates. The official docs walk through it. One warning from those same docs: downgrading can cause data loss, so treat a major upgrade as a one-way door.
2. Let AI DevOps do it in place. Elestio AI DevOps can run an in-place major upgrade on your running service. You start a session from the service page, describe what you want ("upgrade this MariaDB from 10.6 to 11.8"), and watch every command live. It takes an automatic backup before it touches anything, and you can stop it at any point. AI DevOps is included in Elestio support plans: Level 1 comes with 60 credits per service per month, and a full server intervention costs 2 credits.

Either way, the checks below still apply.

Your Pre-Upgrade Checklist

Most of this comes straight from the Foundation's upgrade notes, translated to a Docker setup. Replace mariadb with the service name in your docker-compose.yml.

1. Confirm what you're running.

docker compose exec mariadb mariadb -uroot -p -e "SELECT VERSION();"

Anything below 10.11 is unmaintained. A 10.6 build below 10.6.28 is also missing fixes that already exist.

2. Make sure you have a backup you've actually restored. Elestio takes automated backups and stores remote copies in a different datacenter. Before a major upgrade, also confirm you can restore one. The cheapest way to do that on Elestio is the next step.

3. Rehearse on a clone. Use the Clone button in the dashboard to copy the service, run the version change on the clone, and point a staging copy of your app at it. Run WordPress, Laravel, phpMyAdmin, your monitoring, whatever talks to the database. If something breaks, it breaks on a copy.

4. Look for removed config options. Old my.cnf settings can stop the new server from starting. Print what the server actually reads:

docker compose exec mariadb mariadbd --print-defaults

Look for options the Foundation flags as removed or obsolete, such as innodb_change_buffering, anything TokuDB-related and old authentication plugins. Take them out of your config before you upgrade.

5. Find compressed tables. The Foundation recommends converting ROW_FORMAT=COMPRESSED tables to page compression:

SELECT table_schema, table_name
FROM information_schema.tables
WHERE row_format = 'Compressed';

For each one, run ALTER TABLE db.table ROW_FORMAT=DYNAMIC PAGE_COMPRESSED=1;. On large tables this rewrites the data, so do it in a quiet window.

6. Plan for mariadb-upgrade. The system tables need upgrading after the version change. If your stack uses the official MariaDB Docker image, it runs mariadb-upgrade on startup when MARIADB_AUTO_UPGRADE is set. Check your .env and docker-compose.yml (Update config in the dashboard) before you switch versions. If the variable isn't there, run it by hand afterwards (see Troubleshooting).

7. Check TLS afterwards. MariaDB 11.4 and later enable TLS by default. Retest every client that connects, especially older drivers and monitoring tools.

Running a Galera cluster? Same steps, one node at a time.

Troubleshooting

The server won't start: unknown variable 'innodb_change_buffering'. A removed option is still in your config. Delete the line, then restart. This is what step 4 catches ahead of time.

Warnings about outdated mysql.* tables. mariadb-upgrade didn't run. Check docker compose logs mariadb, then run it by hand:

docker compose exec mariadb mariadb-upgrade -uroot -p

An application can't connect after the upgrade. Look for TLS or certificate errors in the app logs first. Older client libraries are the usual suspects. Update the driver, or adjust the client's TLS settings.

Unknown collation: 'utf8mb4_uca1400_ai_ci' when importing a dump elsewhere. Newer MariaDB versions use this collation by default, and older servers don't know it. Restore into the same version or newer. Our MariaDB Foundation sponsorship post has a workaround if you really need to go backwards.

The Short Version

If you're on 10.6, your database stopped receiving security fixes in July. The move to 11.8 is direct, well documented, and on Elestio you can rehearse it on a clone first, then either click Change version or hand it to AI DevOps. Managed MariaDB on Elestio starts at $11/month for the VM, with automated backups, updates and monitoring included.

Thanks to Anna and the MariaDB Foundation for a post that more people running databases should read.

Thanks for reading ❤️ See you in the next one 👋