MariaDB vs MySQL: does it matter for your site?

About 60% of the WordPress sites in WordPress.org's database version chart run MariaDB, and about 40% run MySQL. WordPress takes either one: MariaDB 10.11 or later, or MySQL 8.0 or later. You probably won't notice the engine under your site until it moves to a host that runs the other one.

A move like that can stall on one line of error text. Someone exporting from MySQL 8.0 into MariaDB got Unknown collation utf8mb4_0900_ai_ci on every try, and their Stack Exchange question has 74,574 views. On our test server (not a DreamHost server), the opposite move failed the same way. A table made with MariaDB 11.8's default collation stopped a MySQL 8.4 import with Unknown collation: 'utf8mb4_uca1400_ai_ci', while a WordPress database moved cleanly in both directions.

Which engine each DreamHost plan runs

Every DreamHost plan where we run the database for you uses MySQL. DreamHost's Help Center version table lists 8.0 for shared MySQL and 8.0 or 8.4 for Dedicated, depending on the Ubuntu release. The MySQL VPS page lists MySQL 8.0. The query below shows what yours runs.

Managed VPS keeps your databases on DreamHost's shared MySQL servers, so it follows the shared row. The Dedicated plan is where you can also install any MySQL version you like, according to DreamHost's Help Center MySQL overview.

On shared hosting, if your app needs MySQL 8.4 before your server moves, the Help Center's answer is to add a MySQL VPS and move your databases to it. Before you add one, see whether your database is slowing your site, and if you're pricing a cloud database too, RDS for MySQL pricing next to a private MySQL server.

How to check yours

1. Open phpMyAdmin
   Log in to phpMyAdmin from your DreamHost panel, or from your own server's tools.
2. Click the SQL tab
   It opens a box where you can type a query against the server.
3. Run the version query

   Paste this and run it:

   sqlCopy

   SELECT VERSION();

   A MySQL server answers with a plain number, such as 8.4.11. A MariaDB server names itself in the answer, and ours returned 11.8.9-MariaDB-ubu2404.

On a VPS you set up yourself, the Linux release decides what apt install gives you. Ubuntu 24.04 ships MySQL 8.0 and MariaDB 10.11. Ubuntu 26.04 ships MySQL 8.4 and MariaDB 11.8. Debian 13 has MariaDB 11.8 and no MySQL server package at all, and its default-mysql-server package installs MariaDB. Our test confirmed that, and it showed Ubuntu's default-mysql-server going the other way: it installs MySQL, 8.4 on 26.04 and 8.0 on 24.04. On our LAMP Stack VPS, the same query tells you which MariaDB version you got. If you haven't picked the Linux yet, our guide to which Linux to run on your VPS compares the four we offer.

What's different between MySQL 8.4 and MariaDB 11.8

MariaDB is made by MySQL's original developers. The two have drifted apart, and MariaDB's own list of differences is long. These are the rows a site owner can run into.

You'll most likely meet the collation row first. MySQL 8 tags new text columns with utf8mb4_0900_ai_ci, and MariaDB 11.4 and later use utf8mb4_uca1400_ai_ci, per MariaDB's compatibility matrix. An export carries those names in every CREATE TABLE line. MariaDB's list of differences says 11.8 knows 550 collations, including 44 aliases it added in 11.4.5 to ease replication from MySQL. In our test, MariaDB 11.8 took a MySQL 8.4 table tagged utf8mb4_0900_ai_ci without complaint. The reverse failed, because MySQL 8.4 doesn't know utf8mb4_uca1400_ai_ci, and the import stopped with ERROR 1273. WordPress doesn't hit either problem. It created every table as utf8mb4_unicode_520_ci on both engines.

The shipped defaults matter if you compare the two yourself. MySQL 8.4 turns binary logging on out of the box, and MariaDB leaves its binary log off. Performance Schema follows the same split: on in MySQL, off in MariaDB 11.8. A side-by-side test that leaves both untouched compares two settings files as much as two engines, so we ran ours both ways.

Memory, speed and disk on our test server

With nothing connected, MySQL sat at 427 MiB of memory and MariaDB at 137 MiB. We ran the official MySQL 8.4.11 and MariaDB 11.8.9 images one at a time on a test VM with 2 vCPU and 4 GB of memory, the same size as our Stack 4 plan.

On speed the two came out about the same once the settings matched. Each engine ran the benchmark once per setting, which is too few runs to call either one faster.

You'd feel the memory gap on a small server, where the database shares RAM with PHP and your web server. Of our test VM's 3,904 MB, 3,465 MB was still available with MariaDB idling and 3,136 MB with MySQL. Right after the benchmark, turning MySQL's two shipped extras off cut its gap over MariaDB from 356 MiB to 101 MiB. For sizing a database server, see how much RAM MySQL needs.

Does your app care?

We installed WordPress 7.1.3 on each engine, generated 200 posts and 500 comments, and loaded the home page without an error on either. The apps in the table below are like that: check your app's requirements page before you think about the engine, and you'll usually find both listed with a minimum version. These come from each app's own page, read on October 16, 2026.

Ghost is the one app here that cares. Its supported databases page says MySQL 8 is the only supported database in production, and it strongly recommends moving off MariaDB if you're on it.

Nextcloud 35 is worth a second look too. Its requirements list MySQL 8.4 and 9.7 and leave 8.0 off. On a server you run yourself, use MySQL 8.4 or one of the MariaDB versions it lists.

Moving a database between them

To move a database between MySQL and MariaDB in either direction, you export it to a SQL file and import that file. MariaDB's migration guide answers Can I perform an in-place upgrade? with a plain No for anyone coming from MySQL 8.0 or 8.4. You can't copy the files across.

1. Check the version on both servers
   Run SELECT VERSION(); on the old server and the new one. Knowing which engine you're leaving tells you which collation names to look for in step 3.
2. Export with the old server's own tool

   On MySQL, use MySQL's mysqldump. MariaDB's migration guide asks for it, since MariaDB's own mariadb-dump hasn't been tested much against MySQL. On MariaDB, use mariadb-dump. Name one database and leave out --databases, so the file has no CREATE DATABASE line:

   bashCopy

   mysqldump --user=USER \
     --password \
     --single-transaction \
     --routines --triggers \
     --hex-blob \
     DBNAME > site.sql

   DreamHost's import errors article explains that a CREATE DATABASE line makes the import fail with ERROR 1044. If you're moving into DreamPress, leave out --routines and --triggers, because DreamPress MySQL servers don't support stored routines or triggers.

3. Swap any collation names the new server doesn't know
   A WordPress database usually skips this step, since WordPress used utf8mb4_unicode_520_ci on both engines in our test and moved both ways with no errors. Tables that carry the server's default collation can fail in one direction. MySQL 8.4 stopped on Unknown collation: 'utf8mb4_uca1400_ai_ci' in a MariaDB 11.8 export, while MariaDB 11.8 accepted MySQL's utf8mb4_0900_ai_ci. Older MariaDB versions reject it, as in the Stack Exchange question. Replace the unknown name throughout the file with utf8mb4_unicode_520_ci, which both engines know, then import again. That's the fix the top Stack Exchange answers used, and it's the collation WordPress picked on both engines in our test.
4. Import into an empty database
   Create the database and its user in your panel first, then import the file in phpMyAdmin or with the mysql client. In our test, dumps from mysqldump and mariadb-dump set their own character set. If you pipe a hand-written SQL file into the mysql client inside the official MySQL Docker image, add --default-character-set=utf8mb4: without it, that client fell back to latin1 in our test and garbled accented letters.
5. Test the site before you switch DNS
   Load a few pages, log in to the admin, run a search and save a post.

Which one to pick

Our pick for a PHP site is the engine your host already runs, kept on a supported version.

If you're on MySQL 8.0, your next step is MySQL 8.4, and you can stay with MySQL to get there. Oracle moved MySQL 8.0 to Sustaining Support on April 21, 2026, and it tells users to upgrade to 8.4 or 9.7. DreamHost's Help Center says Dedicated servers are already moving to 8.4, shared servers move on DreamHost's own schedule, and MySQL VPS customers can contact support to request it.

How we measured

We ran the test on October 19, 2026, on a VM under Colima on an Apple M2 Mac: arm64, 2 vCPU, 3,904 MB of visible memory, no swap, Ubuntu 24.04.4 and Docker 29.5.2. We didn't use a DreamHost server. We used the official mysql:8.4.11 and mariadb:11.8.9 images, pinned by digest, and changed nothing for the as-shipped runs. Idle memory is the median of 12 docker stats readings taken 5 seconds apart after a 2-minute settle, and it hadn't moved 10 minutes later. The benchmark was sysbench 1.0.20's oltp_read_write test with 4 tables of 100,000 rows, which fit in each engine's default 128 MB buffer pool, 4 threads, a 60-second warm-up and then one 120-second run per engine and setting.

Our VPS and Dedicated servers use AMD EPYC processors, so compare the engines by ratio and don't expect the same absolute numbers there. We didn't test a MySQL VPS, shared MySQL or our LAMP Stack image. Each benchmark ran once, on synthetic data that's simpler than a real site's traffic. MariaDB's run also logged 683 errors that sysbench retries and counts separately (about 6 a second), and MySQL's logged none; we didn't look into why. The WordPress check covered the install, generated content and page loads, and each move used the source engine's own dump tool.

MySQL and MariaDB FAQs