MySQL vs MariaDB: what actually differs

MariaDB began as a fork of MySQL led by original MySQL developers. For years each MariaDB release was close to a “drop-in replacement” for the matching MySQL version. That is no longer true in general: since MariaDB 10.x and MySQL 8.x the two have added different features and changed different defaults. This page sticks to differences that the MariaDB and MySQL documentation state.

What stays compatible

• The client protocol: MariaDB’s documentation says its client protocol is binary compatible with MySQL’s, and MySQL connectors work with MariaDB.
• Core SQL and the account model ('user'@'host', CREATE USER, GRANT).
• Configuration files: MariaDB’s server reads my.cnf, including [mysqld] sections, and additionally [mariadb] sections.
• Tools by name: MariaDB renamed its binaries to mariadb, mariadb-dump and so on, and keeps the mysql* names as symlinks.

Documented differences

MariaDB publishes a per-version list. The points below come from its comparison of MariaDB 11.8 with MySQL 8.0; check the page for your exact versions.

• GTIDs: MariaDB’s global transaction IDs are not compatible with MySQL’s, and the GTID system variables differ. A replication setup cannot mix them freely, and MariaDB states it cannot replicate from a MySQL 8.0 primary because of binary log format differences.
• JSON: in MariaDB, JSON is an alias for LONGTEXT and values are stored as text; MySQL stores JSON in a binary format. Comparisons and some operators behave differently.
• Authentication: MariaDB cannot use accounts created with MySQL’s SHA-256 password algorithm, and on Unix-like systems root@localhost on a fresh install uses unix_socket (log in with sudo mariadb). MySQL 8.4 defaults to caching_sha2_password.
• Storage engines: MariaDB includes engines MySQL does not, such as Aria, ColumnStore, MyRocks, S3 and Spider. Both use InnoDB as the main transactional engine.
• Server initialization: MariaDB does not support mysqld --initialize; it uses mariadb-install-db.
• X Protocol: MariaDB does not support MySQL’s X Plugin.
• Performance Schema: disabled by default in MariaDB, enabled by default in MySQL.
• Option names: MariaDB accepts unique prefixes of option names (with a warning); MySQL requires full names.
• SET PERSIST exists in MySQL but is not supported in MariaDB.

Moving data between them

Because on-disk formats and system tables have diverged, the safest way to move a database between MySQL and MariaDB is a logical dump and reload, not copying the data directory. Dump only application databases and recreate accounts with CREATE USER/GRANT statements on the target.

# on the MySQL host
mysqldump -u root -p --single-transaction --routines --events --triggers \
  --databases shop > shop.sql

# on the MariaDB host
mariadb -u root -p < shop.sql

Test the application against the target before switching: look especially at JSON columns, SQL that relies on version-specific functions, and connection settings that name an authentication plugin.

Which one should I pick?

Pick the one your distribution, hosting platform or application vendor supports best, then stay consistent across environments. Mixing them inside one replication topology or between test and production is where most surprises come from. Version numbers no longer line up: MariaDB 11.x is not “MySQL 11”.

Official documentation

• MariaDB: MariaDB vs MySQL compatibility
• MariaDB: Incompatibilities between MariaDB 11.8 and MySQL 8.0
• MariaDB: Authentication from MariaDB 10.4