Your backend team has been running MySQL 8.0 in production for three years when the compliance review flags Oracle's commercial license terms — specifically the restrictions around redistribution and the cost of MySQL Enterprise features like the thread pool. Someone on the team suggests evaluating MariaDB 11.x as a drop-in replacement, citing its compatible wire protocol and GPL-only licensing. Two engineers spend a sprint on the migration POC and come back with a list of surprises: authentication plugin mismatches, JSON function name differences, and a replication topology that does not map cleanly. The decision is not as simple as swapping a binary.
- MariaDB forked from MySQL 5.5 in 2009; both have diverged significantly, especially at MySQL 8.0 vs MariaDB 11.x.
- Wire protocol compatibility holds for most MySQL 5.7-era workloads but breaks in specific MySQL 8.0 features — especially authentication, JSON functions, and replication modes.
- MariaDB wins on licensing (pure GPL for core) and built-in features like thread pool, system-versioned tables, and Galera Cluster at no extra cost.
- MySQL 8.0 wins on InnoDB optimizer maturity, hash join support, better JSON performance, and a more mature cloud ecosystem (Aurora, PlanetScale).
- MariaDB 11.x introduced Business Source License (BSL) for some components — not fully open-source in all respects any more.
- For greenfield workloads in 2026: choose MySQL 8.0/9.x if you rely on managed cloud offerings or Oracle's ecosystem; choose MariaDB if you need Galera, temporal tables, or want to avoid Oracle entirely.
A Brief History: One Codebase, Two Paths
MySQL was created in 1995 and acquired by Sun Microsystems in 2008. When Oracle bought Sun in 2010, much of the MySQL community grew uneasy about the future of an open-source database under a commercial database vendor. Michael "Monty" Widenius — one of MySQL's original creators — had already forked the codebase in 2009, creating MariaDB as a community-maintained, GPL-licensed alternative starting from MySQL 5.5.
The split was not purely philosophical. Oracle's development of MySQL became less transparent, with more features gated behind the commercial Enterprise edition. MariaDB's goal was to remain open — all features in the community edition, no "Enterprise-only" carve-outs. For most of the 2010s, MariaDB tracked MySQL's compatibility closely enough that many Linux distributions replaced MySQL with MariaDB as the default (notably Red Hat/CentOS, Debian, and Arch).
By 2024–2026, the two databases have diverged more than they have converged. MariaDB Corporation underwent a significant change when K1 Investment Management acquired the company, introducing uncertainty about the project's direction — and the adoption of the Business Source License (BSL) for some MariaDB 11.x Enterprise components added complexity to the "fully open" narrative. Meanwhile, MySQL moved through 8.0 and into 8.4 and 9.x, adding major optimizer improvements and cementing its dominance in managed cloud offerings.
Compatibility: Are They Really Drop-In Replacements?
The short answer: yes for MySQL 5.7-era applications, increasingly no for MySQL 8.0-specific features.
The wire protocol remains compatible. Any MySQL client library — JDBC, mysqlclient, go-sql-driver — can connect to MariaDB without modification. For applications that use basic SQL, InnoDB storage, and standard replication, a migration from MySQL 5.7 to MariaDB 10.x is often straightforward. Many teams have done exactly this without application-layer changes.
The problems surface in the details. MySQL 8.0 changed its default authentication plugin from mysql_native_password to caching_sha2_password. MariaDB uses mysql_native_password by default, which means older clients that were already broken against MySQL 8.0 work fine against MariaDB — but if you are migrating from MySQL 8.0 and have users or applications configured for caching_sha2_password, they will need reconfiguration.
JSON handling is another friction point. Both databases support JSON columns and a rich set of JSON functions, but function names and behaviors differ in places. MySQL's JSON_TABLE(), introduced in 8.0, does not exist in MariaDB (MariaDB has its own equivalent). Window functions and CTEs (Common Table Expressions) are supported in both, but with syntactic differences in edge cases. If your application was written specifically against MySQL 8.0's JSON or window function behavior, test thoroughly before assuming compatibility.
Replication is where migrations get expensive. MySQL 8.0 InnoDB Cluster uses Group Replication, which is entirely MySQL-specific. MariaDB uses Galera Cluster for synchronous multi-master replication — the topologies are not interchangeable. If you are running a MySQL Group Replication setup, migrating to MariaDB requires rebuilding your high-availability layer from scratch using Galera or asynchronous replication.
The internal system table schemas differ between MySQL 8.0 and MariaDB. Running
mysql_upgrade from one to the other is not supported. Always perform logical dumps (mysqldump or mydumper) when migrating between them, never physical file copies or binary upgrades.
Feature Comparison Table
| Feature | MySQL 8.0 / 8.4 | MariaDB 10.x / 11.x |
|---|---|---|
| System-versioned (temporal) tables | No | Yes (10.3+, native SQL:2011) |
| Thread pool | Enterprise edition only | Built-in, free (all editions) |
| Galera Cluster (synchronous multi-master) | No (uses Group Replication instead) | Built-in (wsrep API) |
| InnoDB Cluster / Group Replication | Yes (native) | No direct equivalent |
| Columnstore storage engine | No | Yes (MariaDB ColumnStore) |
| Spider storage engine (horizontal sharding) | No | Yes (built-in) |
| Default charset | utf8mb4 | latin1 (10.x); utf8mb4 in 11.x+ |
| Default auth plugin | caching_sha2_password (8.0+) | mysql_native_password |
| Atomic DDL | Yes (8.0+) | Crash-safe DDL (10.6+, not full atomic) |
| Hash join | Yes (8.0.18+) | Yes (10.7+, hash join support added) |
| Invisible columns | Yes (8.0.23+) | Yes (10.3+) |
| JSON_TABLE() | Yes (8.0+) | No direct equivalent (use JSON_QUERY) |
| Window functions | Yes (8.0+) | Yes (10.2+) |
| Common Table Expressions (CTEs) | Yes (8.0+) | Yes (10.2+) |
| Descending indexes | Yes (8.0+) | Yes (10.8+) |
| Audit log plugin | Enterprise only | Built-in (MariaDB Audit Plugin, free) |
| License | GPL v2 + Commercial (Oracle) | GPL v2 (core); BSL for some 11.x Enterprise features |
Performance Comparison
Neither database is categorically faster — workload determines the winner. Here is where each has a measurable edge in 2026.
Where MariaDB tends to win: High-concurrency OLTP workloads benefit from MariaDB's built-in thread pool. On servers with hundreds of simultaneous connections, the thread pool reduces context switching and improves throughput without any licensing cost. MySQL's thread pool requires the Enterprise edition, which means most self-hosted MySQL deployments are running the default one-thread-per-connection model. For workloads with connection spikes — SaaS multi-tenant applications, for example — this is a meaningful operational difference. MariaDB's optimizer also handles certain query patterns with multiple subqueries differently and can outperform MySQL in specific OLAP-adjacent queries.
Where MySQL tends to win: The InnoDB optimizer in MySQL 8.0 received significant investment from Oracle engineers — histogram statistics, improved cost model, better index merge strategies. For complex analytical queries on InnoDB tables, MySQL 8.0 frequently executes more efficient query plans out of the box. JSON document workloads also perform better on MySQL 8.0, where the binary JSON format and JSON function implementations have been highly optimized. If your application is JSON-heavy (document store pattern), MySQL 8.0 is the stronger performer.
Synthetic benchmarks rarely reflect application-specific access patterns. Before making a decision based on performance, run pgbench-equivalent load tests (sysbench works well with both) against a representative dataset from your production environment. A 30-minute sysbench OLTP_read_write run with your actual concurrency profile will tell you more than any published benchmark.
Licensing and Support
MySQL is released under GPL v2 for the Community Edition. Oracle also sells MySQL Enterprise Edition with additional features (thread pool, audit log, enterprise backup, enterprise firewall) under a commercial license. If you are running MySQL Community, you have no Oracle support obligation, but you also have no access to Enterprise features.
MariaDB's licensing history is more complicated than it appears. The core MariaDB Server has always been GPL v2 — that has not changed. However, since MariaDB 11.x, some components of MariaDB Enterprise (the commercial offering from MariaDB Corporation) use the Business Source License (BSL). BSL is not open-source by OSI definition: it restricts production use above certain thresholds until a "change date" when it reverts to a proper open-source license. For the majority of users running MariaDB Community Server, this does not affect them directly — the BSL applies to MariaDB Enterprise-only components. But it signals a shift in the project's open-source posture that the community has noticed.
MariaDB Corporation's acquisition by K1 Investment Management in 2023 added further uncertainty. MariaDB went through a period of financial instability, layoffs, and strategic repositioning. By 2026 the company has stabilized, but the period reinforced for many organizations that betting on MariaDB Corporation's commercial support carries more counterparty risk than betting on Oracle for MySQL.
If your organization's open-source policy requires OSI-approved licenses throughout, audit which MariaDB components you depend on. The Community Server remains GPL, but Enterprise-tier features under BSL do not meet OSI criteria during their restricted period.
Ecosystem and Cloud Support
Cloud managed service availability is one of the clearest differentiators in 2026.
MySQL cloud offerings: Amazon Aurora MySQL is the most widely deployed MySQL-compatible managed database at scale, offering significantly improved write performance and automated failover over standard RDS MySQL. Google Cloud SQL for MySQL and PlanetScale (based on Vitess/MySQL) round out a mature MySQL cloud ecosystem. Oracle's own MySQL HeatWave is notable for its integrated OLAP acceleration.
MariaDB cloud offerings: AWS RDS MariaDB is available and well-maintained. Azure Database for MariaDB existed but Microsoft announced its retirement (deprecated in favor of Azure Database for MySQL Flexible Server). SkySQL (MariaDB Corporation's cloud offering) provides managed MariaDB. The MariaDB cloud footprint is meaningfully smaller than MySQL's, which matters if your organization is building cloud-native infrastructure.
Tooling compatibility is generally good. Percona's pt-toolkit (pt-query-digest, pt-online-schema-change) works with both MySQL and MariaDB. mydumper/myloader works with both. Orchestrator for replication topology management supports both. Prometheus exporters (mysqld_exporter) work with both, though some MariaDB-specific metrics require the dedicated mysqld_exporter build that understands MariaDB's status variables.
Migration Considerations
MySQL to MariaDB: Logical dump migration using mysqldump is the recommended path. Test all stored procedures, triggers, and events — syntax differences exist in edge cases. Audit all authentication configurations and update any hardcoded caching_sha2_password references. If you use MySQL 8.0 JSON_TABLE(), find MariaDB equivalents before migrating. Rebuild replication topology from scratch if you are using Group Replication.
# Dump from MySQL 8.0 (use --column-statistics=0 for mysqldump compatibility) mysqldump --column-statistics=0 --single-transaction \ --routines --triggers --events \ -h mysql-host -u root -p mydb > mydb_dump.sql # Restore to MariaDB 10.x / 11.x mysql -h mariadb-host -u root -p mydb < mydb_dump.sql # Verify row counts match mysql -h mysql-host -e "SELECT COUNT(*) FROM mydb.orders;" mysql -h mariadb-host -e "SELECT COUNT(*) FROM mydb.orders;"
MariaDB to MySQL: This direction is less common but follows the same logical dump approach. Watch for MariaDB-specific syntax: system-versioned table definitions, Spider engine tables, and Galera-specific wsrep settings in my.cnf must all be removed or replaced. If you use MariaDB's temporal table queries (FOR SYSTEM_TIME AS OF), there is no MySQL equivalent — you will need to redesign those queries.
Run both databases in parallel for two to four weeks before cutting over. Use a query mirroring proxy or application-level dual-write to validate result set equivalence on your actual queries, not just row counts. Tools like gh-ost can help with schema migrations during the transition period on either database.
Which Should You Choose in 2026?
Use this decision framework:
Choose MySQL 8.0 / 8.4 if: you are deploying on a major cloud provider and want the richest managed service options (especially Aurora); your team has existing MySQL expertise and tooling; you need the most mature InnoDB optimizer; or your organization has a policy of using software backed by a large commercial vendor with predictable support contracts.
Choose MariaDB 10.x / 11.x if: you need synchronous multi-master replication without paying for additional software (Galera is built-in); you need system-versioned (temporal) tables natively; your connection concurrency is high enough that the built-in thread pool is a meaningful advantage; you want to avoid Oracle as a dependency entirely; or you are building on Linux distributions that ship MariaDB as default and want to stay close to the distribution's supported stack.
For the original team scenario: if the concern is Oracle's commercial license terms and you are on MySQL Community Edition, you are already on the GPL edition with no commercial restriction. The thread pool argument is real — if connection counts exceed 200-300, MariaDB's built-in thread pool is operationally valuable. But if you are using Aurora MySQL or have built your HA layer on Group Replication, the migration cost likely exceeds the benefit.
- MariaDB and MySQL share a common origin but have diverged significantly — especially between MySQL 8.0 and MariaDB 11.x. Do not assume drop-in compatibility without testing.
- Authentication plugin differences (
caching_sha2_passwordvsmysql_native_password) are the most common migration friction point and must be planned for explicitly. - MariaDB's built-in thread pool and Galera Cluster are the strongest technical differentiators for self-hosted, high-concurrency deployments.
- MySQL's managed cloud ecosystem (Aurora, PlanetScale, Cloud SQL) is substantially more mature in 2026.
- MariaDB's BSL licensing for some Enterprise components means "fully open-source" is no longer accurate for all of the MariaDB product line.
- Always migrate via logical dump, never physical file copy. Validate with parallel run periods before full cutover.
- The right choice depends on your HA topology, cloud provider, connection concurrency profile, and organizational risk tolerance — not just feature lists.
Working with JusDB on MySQL and MariaDB
JusDB manages both MySQL and MariaDB deployments in production. Whether you are evaluating a migration, need help with Galera clustering, or want an independent assessment of which engine fits your workload, our DBAs have run both in production at scale.
Explore JusDB MySQL/MariaDB Services → | Talk to a DBA
Related reading: