TL;DR: What you need to know
Servers running Ubuntu 26.04 use one of two database types: Percona or MariaDB. These two used to be interchangeable, but they no longer are. When you move, clone or restore a site, always keep it on the same database type it came from: Percona to Percona, or MariaDB to MariaDB. Moving a site between the two types is likely to fail, and support for fixing those failures is limited. If a move between types does go wrong, the fix will almost always be to redo it onto a server with the matching database type.
Introduction
Ubuntu 26.04 servers run Percona 8.4 or MariaDB 11.8, and those two engines can no longer be treated as interchangeable. Percona 8.0 does not run on 26.04 and MariaDB 10.11 is not published for it, so every site arriving on a 26.04 server comes from a different database version than the one it lands on.
That has four practical consequences for migrations, backups, restores, clones and staging, covered below.
MariaDB is no longer a MySQL drop-in
MariaDB began as a fork of MySQL and for years could stand in for it. That is no longer true. MySQL (and Percona, which tracks it) and MariaDB have each added features the other does not share, and by Percona 8.4 and MariaDB 11.8 the gap is wide enough to break things that used to just work.
The difference that matters most for WordPress is collations. Each engine now has its own default collations, which the other doesn’t fully recognise. Tables created by plugins or with the server’s default collation can carry one engine’s collation into a dump, and that dump may then fail to load on the other engine.
The practical implication on 26.04: Percona and MariaDB need to be treated as two different databases. Any tool that reads or writes dumps has to know which engine it is talking to.
Cross-engine migrations are far more likely to fail
Moving a site between Percona and MariaDB is now much more likely to fail on 26.04 servers than on 24.04 or 22.04 servers. This applies to migrations, clones, staging pushes, and restores alike: any job that takes a dump from one engine and loads it into the other.
Support for these cross-engine moves is limited. When one fails, the fix is almost always to migrate again to a new server, keeping the same database engine on both ends:
- Percona to Percona (for example 8.0 on 24.04 to 8.4 on 26.04)
- MariaDB to MariaDB (for example 10.11 on 24.04 to 11.8 on 26.04)
In practice, this means the destination server should be built with the same database family as the source before the site is moved.
Why 26.04 servers carry two mydumper builds
26.04 servers install two builds of mydumper, one for each database family, so that backups from older Percona and MariaDB servers can still be restored. A single build cannot reliably cover both, because mydumper and myloader are compiled against a specific client library and inherit that engine’s behaviour. MariaDB’s client libraries and its mariadb-* commands are now separate from MySQL’s, so a build made for one isn’t guaranteed to work against the other.
This matters most during site moves and restores. A site backed up on a 24.04 server with Percona 8.0 or MariaDB 10.11 has to restore onto a 26.04 server running Percona 8.4 or MariaDB 11.8. The restore has to use the build that matches the source dump’s family:
| Dump came from | Restores onto 26.04 | mydumper build used |
|---|---|---|
| Percona 8.0 / 8.4 | Percona 8.4 | MySQL/Percona build |
| MariaDB 10.11 / 11.8 | MariaDB 11.8 | MariaDB build |
There is also a packaging wrinkle. Upstream publishes no mydumper package for 26.04, and the Ubuntu archive only carries the very old 0.10.1. Our builds therefore use the 24.04 (noble) package with a compatibility shim, so they stay on the same mydumper version as the rest of the fleet.
Separate dump names for clones, staging and backups
Every workflow that dumps a database names its dumps differently, so they can never overwrite each other and backups only ever pick up backup dumps. Clones, staging pushes, backups and the other dump-producing tasks can all run on the same server, sometimes against the same site, and often at the same time.
With shared names, two things could go wrong:
- Clashes: A clone or staging push writing its dump while a backup is running could overwrite or corrupt the other’s files.
- Polluted backups: A backup that collects “whatever dumps are present” could sweep up a stray clone or staging dump, storing the wrong data or the wrong engine’s dump inside a backup.
Distinct names per workflow remove both risks. A backup only collects dumps carrying the backup naming, and every other workflow cleans up only its own files. Combined with the two mydumper builds, this keeps each dump tied to the job that made it and the engine it came from.