Choosing a MariaDB version for Magento 2.4.8: 10.5, 11.4 or 11.8

You're taking staging to Magento 2.4.8-p5, and you open app/etc/di.xml to check which database versions it accepts. The SqlVersionProvider supported-version patterns list MariaDB 10.2 through 10.6. Adobe's system requirements page for the same release lists MariaDB 11.4 and 11.8. Staging runs 10.5, and it passes. So the question is fair: can you stay on 10.5, or do you have to move to 11.4?

Short answer: 10.5 working on staging is not the same as 10.5 being supported. Plan to move to one of the versions Adobe lists. The rest of this article covers which one, and how to do the move without betting production on it.

The version check and the support matrix answer different questions

SqlVersionProvider is a gate. When the setup and upgrade commands run, Magento reads the server version string and matches it against the patterns in di.xml. If nothing matches, the command stops with an unsupported-RDBMS error. Passing that gate only means Magento won't refuse to run.

The system requirements page is what Adobe says it has tested and will stand behind for that release. That's the list that counts when you hit a query regression, raise a support ticket, or explain a platform decision to someone who controls the budget.

So when the two disagree, go by the requirements page for what you should run, and by di.xml for what will actually start. Before you plan anything, check the file your install really uses instead of a screenshot or a copy from another environment:

grep -n -A12 'supportedVersionPatterns' app/etc/di.xml
grep -rn 'MariaDB' vendor/magento/magento2-base/app/etc/di.xml

If your installed codebase really only matches 10.x patterns, find that out on staging, not during a production maintenance window. Don't hand-edit core di.xml to widen the patterns. You can override the argument from a small custom module, and some teams do. But then you're running a combination nobody has tested, so write that down as a decision rather than leaving it as a quiet workaround.

Staying on 10.5 is a deferral, not a decision

10.5 isn't on the list Adobe publishes for 2.4.8-p5. "It runs on staging" only tells you the version gate matched and your test traffic didn't hit anything broken. Two things make it risky to stay.

First, upstream support. Check where 10.5 is in its lifecycle on MariaDB's own maintenance policy page. Don't rely on a blog post for this, this one included. If the upstream line isn't getting fixes anymore, database security issues stop being patched no matter what Magento does.

Second, every later Magento patch release is another chance for the gap to catch you. You'll do this migration eventually. It's cheaper to do it now, while you're already doing a platform upgrade and regression testing, than to do it later as an emergency.

Our view: finish the 2.4.8-p5 upgrade on 10.5 if you have to separate the two risks, then schedule the database move as its own change soon after. Don't treat 10.5 as where you're staying.

11.4 or 11.8

Both are on Adobe's list for this release, so either one is defensible. Some practical differences:

• Support window. Look up both on MariaDB's maintenance policy page and write down the end-of-life dates in your change ticket. The later date is worth something because it pushes back your next forced database migration.
• Hosting and packaging. Check what your managed host, your distro repositories, or your container base images actually ship and patch. A version you have to build yourself or pin to a third-party repo has an ongoing cost.
• Distance from 10.5. Both are a major jump from 10.5, so optimizer, default, and deprecation changes build up either way. The newer line has more changes and has had less time in production across the ecosystem.
• Tooling. Backup tools, monitoring agents, and replication setups need to support the target version as well. Check mariadb-backup, your monitoring exporter, and any read-replica or failover tooling.

If your host supports both and your tooling handles both, 11.4 is the conservative choice. It's the smaller jump and has been in use longer. Pick 11.8 if its support window is meaningfully longer and you want to put off the next migration. In either case, record why you chose it.

The upgrade runbook

Run this on staging first, using a recent copy of production data. Synthetic fixtures won't expose the slow queries that matter.

1. Take two backups. Make a logical dump with mariadb-dump --single-transaction --routines --triggers --events, and also take a filesystem or volume snapshot of the data directory with the server stopped. You'll restore from the snapshot. The dump is there in case the snapshot is bad.
2. Record the baseline. Save SELECT VERSION();, SHOW VARIABLES output, the sql_mode value, and the server's default character set and collation. Pin anything you depend on explicitly in my.cnf so a changed default in the new version doesn't alter behavior without you noticing.
3. Upgrade the server, then run mariadb-upgrade to update the system tables.
4. Run Magento's checks. Run bin/magento setup:db:status and then bin/magento setup:upgrade. The version gate runs at this point, and an unsupported-version error shows up here, not in production.
5. Rebuild and check the indexers. Run bin/magento indexer:reindex, then bin/magento indexer:status. Watch for indexers stuck in processing and for reindex times well above your baseline.
6. Check cron. Run bin/magento cron:run a few times and look at cron_schedule for jobs stuck in running or failing repeatedly. Queue consumers belong in the same check.
7. Test the real flows. Category pages with layered navigation, search, cart price rules, checkout, admin order grids, and exports. The admin grids and reports run the heaviest ad-hoc SQL.

Rollback means restore, not downgrade

Don't count on pointing an older MariaDB binary at a data directory that a newer major version has already upgraded. The rollback plan is: stop the new server, restore the snapshot you took in step 1, and start the old version on it. If the snapshot can't be used, rebuild from the logical dump on a clean old-version instance.

Time the restore on staging, and use that number to size the production maintenance window. Any orders taken on the new version before you roll back have to be reconciled by hand. That's why the go/no-go checks should come before you reopen the store, not after.

Common problems after the upgrade

• Query plan regressions. Pages that were fast get slow, most often layered navigation, large admin grids, and reports. Turn on the slow query log from the first minute and compare it with the baseline.
• Collation and charset mismatches. New tables created by extensions pick up new server defaults and then clash in joins with older tables. Pin the defaults as described in step 2.
• Stricter SQL behavior. Third-party modules that depended on lenient sql_mode handling start throwing errors. These usually show up in cron and imports before the storefront.
• Tooling that fails without clear errors. Backup jobs or monitoring that don't recognize the new version string. Confirm the first post-upgrade backup actually restores.

What to do next

Run the grep above on your actual codebase, look up the end-of-life dates for 11.4 and 11.8, check what your host packages, and schedule a staging rehearsal with production data. If you want someone to go over the version choice or run the rehearsal with you, see our Magento 2 operations work or get in touch.