MySQL vs MariaDB: Differences, Compatibility & Licensing

A question our MySQL database server support team answers weekly: are MySQL and MariaDB still interchangeable? They were in 2012. They are not now. This article covers where the two databases have diverged — versioning, features, replication, licensing, and tooling — with each claim sourced from the MariaDB Knowledge Base or the MySQL reference manual.

Shared history

MariaDB was forked from MySQL in 2009 by Michael "Monty" Widenius, MySQL's original author, after Oracle acquired Sun Microsystems (and MySQL with it). Early MariaDB releases tracked MySQL version-for-version: per the MariaDB Knowledge Base compatibility page, MariaDB 5.5 functioned as a drop-in replacement for MySQL 5.5, and MariaDB 10.2 through 10.4 functioned as limited drop-in replacements for MySQL 5.7. The same page states that "the implementation differences continue to grow in each new MariaDB version." The drop-in era is over.

Version numbering: no more 1:1 mapping

The two projects number releases independently. MySQL's current lines are 8.0, the 8.4 LTS series, and the 9.x innovation series, documented at dev.mysql.com. MariaDB's maintained lines are 10.6, 10.11, 11.4, and 11.8 (long-term series), plus short-term rolling releases. MariaDB 11.4 is not "equivalent to" any MySQL version; the MariaDB Knowledge Base compares each maintained MariaDB series against MySQL 8.0 as separate incompatibility documents, not as version pairs. Treat the two as related but distinct products, the way PostgreSQL and its forks are treated.

Feature differences

The JSON difference matters most in practice. MySQL stores JSON in a packed binary format documented in the MySQL JSON reference; MariaDB stores it as normal TEXT. Both support most JSON functions, but on-disk format, comparison semantics, and replication of JSON columns differ.

Replication compatibility

Per the MariaDB Knowledge Base replication compatibility page:

• MySQL 5.7 to MariaDB: MariaDB 10.2 and later can replicate from a MySQL 5.7 primary, using binary log file and position — never MySQL GTIDs, which MariaDB does not implement. ROW format is recommended.
• MySQL 8.0 to MariaDB: not possible at all before MariaDB 10.6.21 / 10.11.11 / 11.4.5 / 11.7.2, because MySQL 8.0 introduced new binary log events. Those versions and later can replicate from MySQL 8.0 with conditions: JSON columns must be converted to TEXT on the MySQL side, binlog-row-value-options must be empty, and binlog transaction compression must be off. Before MariaDB 11.4.9 / 11.8.4 / 12.1.1, the replication user must also use mysql_native_password because MariaDB did not support caching_sha2_password.
• MariaDB to MySQL: works only without GTID auto-positioning on the MySQL side, without binlog encryption or compression on the MariaDB side, and only with character sets and collations MySQL supports — MariaDB's default utf8mb4 collations are not among them.

Licensing and ownership

The practical difference: with MySQL, several server-level features (thread pool, native audit plugin, TDE key management) sit behind the commercial edition. With MariaDB, the equivalent features ship in the GPL build and the paid product adds packaging, proxy, and support rather than server capability.

Tooling and cloud availability

Client compatibility remains high because the wire protocol is shared: per the compatibility page, all MySQL connectors (JDBC, PHP, Python, .NET, ODBC) work unchanged against MariaDB, and phpMyAdmin supports both. MySQL Workbench is developed by Oracle against MySQL; it generally connects to MariaDB over the common protocol, but MariaDB is not a supported target, and features tied to MySQL-specific system tables — performance_schema reports, X Protocol features, version-specific administration screens — misreport or fail against MariaDB servers. MariaDB's own GUI directions are third-party tools (HeidiSQL ships with the Windows installer, DBeaver, dbForge).

In the cloud: Amazon RDS and Azure Database offer both engines as managed services. Amazon Aurora's MySQL-compatible edition tracks MySQL (5.7/8.0 compatibility), not MariaDB — there is no Aurora MariaDB. Google Cloud SQL offers MySQL but not MariaDB. If the roadmap includes Aurora or Cloud SQL, that alone is a reason to standardize on MySQL semantics.

Performance

Both projects publish improvements each release, and third-party benchmarks disagree with each other depending on workload, version, and configuration. The honest summary: the optimizers have diverged enough that the same query can plan differently on each engine, MariaDB's built-in thread pool helps high-connection-count workloads that would need MySQL Enterprise to match, and MySQL 8.x hash joins help large analytical joins. Neither is categorically faster. Benchmark your own workload on the versions you would actually run.

Migration direction matters

MySQL to MariaDB is the supported, documented direction — MariaDB publishes upgrade paths from each MySQL version and the server reads MySQL data files of the corresponding vintage. The reverse is harder and gets harder with every release: MariaDB features with no MySQL equivalent (sequences, system-versioned tables, Aria/MyRocks tables, MariaDB-specific collations, MariaDB GTID state) do not transfer, and past the early 10.x series there is no in-place downgrade path. Moving MariaDB 10.x/11.x to MySQL means a logical dump and restore (mysqldump or mydumper), schema fixes for unsupported features, and application retesting. Budget it as a migration project, not a package swap.

Which one to run

FAQ

Is MariaDB still a drop-in replacement for MySQL?

No. That held through the 5.5 era and partially through MariaDB 10.4 versus MySQL 5.7. Against MySQL 8.x there are binary log, GTID, JSON storage, authentication, and collation differences that require planned migration in either direction.

Can MariaDB and MySQL replicate to each other?

Within limits. MariaDB can be a replica of MySQL 5.7 (10.2+) or MySQL 8.0 (10.6.21+/11.4.5+ with JSON, binlog-option, and authentication caveats). MariaDB as a primary for MySQL requires disabling GTID auto-positioning, binlog compression, and binlog encryption, and avoiding MariaDB-only collations. GTID-based replication never works across the two.

Which is faster, MySQL or MariaDB?

Workload-dependent. The optimizers, thread handling, and storage engines have diverged; published benchmarks favor each engine depending on the test. Measure with your own schema and query mix.

For version-by-version MySQL release detail see our MySQL versions guide, and for the fork's release history see the MariaDB overview.