MySQL and MariaDB are closely related but they are not the same database. MariaDB started as a fork of MySQL in 2009 and the two have diverged significantly since then. For most WordPress site owners the choice is made by their hosting provider, but understanding the differences matters when evaluating hosts, migrating between them, or making decisions for self-hosted setups.
This post covers where the two databases differ, where they are compatible, how they perform, and which situations favor each.
How MariaDB came to exist
MySQL was created in 1995 and acquired by Sun Microsystems in 2008. When Oracle acquired Sun in 2010, several of MySQL’s original developers were concerned about Oracle’s stewardship of an open source project that competed with Oracle’s own commercial database products. The lead developer of MySQL, Michael Widenius, forked the codebase and created MariaDB, naming it after his daughter.
MariaDB was designed as a drop-in replacement for MySQL – compatible with the same client libraries, the same SQL syntax, and the same data formats – while remaining under a fully open source license with a community-driven development model.
For several years MariaDB tracked MySQL closely and the two were nearly interchangeable. Since then, both projects have added features independently and the gap has grown. They are compatible for most common workloads but they are no longer identical.
Licensing and development model
MySQL is dual-licensed. The Community Edition is GPL, meaning it is free to use. The Enterprise Edition adds monitoring tools, backup utilities, and security features behind a commercial license. Oracle controls the development roadmap.
MariaDB is GPL licensed with no commercial tier for the core database. The MariaDB Foundation oversees development with contributions from the community and corporate sponsors. MariaDB Corporation offers commercial support and enterprise tooling separately from the database itself.
In practice, most hosting environments use MySQL Community Edition or MariaDB, both of which are free. The licensing difference matters more for enterprises evaluating support contracts than for typical WordPress deployments.
Feature differences
The two databases have diverged enough that some features exist in one but not the other, or exist in both but behave differently.
Storage engines
Both support InnoDB as the default storage engine, which is what WordPress uses. InnoDB provides ACID compliance, row-level locking, and foreign key support – all relevant for WordPress’s database operations.
MariaDB introduced its own storage engines not present in MySQL, including Aria (a crash-safe alternative to MyISAM) and ColumnStore (for analytical workloads). These are largely irrelevant for WordPress but matter for specific use cases.
JSON support
MySQL 8.0 introduced native JSON data type with a rich set of JSON functions and a functional index on JSON expressions. This is a genuinely useful feature for applications that store structured data in JSON columns.
MariaDB has JSON support but implemented differently. MariaDB’s JSON data type is an alias for LONGTEXT with a CHECK constraint validating JSON format – it does not use a binary storage format. This means MariaDB’s JSON functions are less performant for large JSON documents compared to MySQL 8.0. For WordPress core this difference is irrelevant since WordPress does not use JSON columns, but plugins that store JSON data may behave differently.
Window functions and CTEs
Both databases support window functions and Common Table Expressions (CTEs), which are useful for complex analytical queries. WordPress core does not use these, but custom plugins or reporting tools that query the WordPress database might.
Authentication
MySQL 8.0 changed the default authentication plugin from mysql_native_password to caching_sha2_password. This broke compatibility with older client libraries and applications that had not been updated. MariaDB continues to use mysql_native_password by default, which has broader compatibility with older clients.
This is a practical difference that affects migrations. Moving from MariaDB to MySQL 8.0 can break database connections in applications using older client libraries until the authentication method is explicitly set or the client is updated.
Replication
Both support standard MySQL replication. MariaDB added Galera Cluster for synchronous multi-master replication as a first-class feature. MySQL’s equivalent (Group Replication) exists but has different characteristics and configuration. For high-availability database setups, the replication options differ enough to warrant specific evaluation.
Performance schema and observability
MySQL 8.0 significantly improved its Performance Schema and added the sys schema for easier performance analysis. MariaDB has its own performance monitoring tools but the MySQL 8.0 observability story is generally considered more comprehensive for production monitoring.
Performance
Benchmarks between MySQL and MariaDB vary significantly depending on workload, configuration, version, and what is being measured. General statements about one being faster than the other are not reliable.
For WordPress workloads specifically – read-heavy, many small queries, InnoDB tables, relatively simple SQL – both perform well and the difference is not meaningful in practice. The bottlenecks on a typical WordPress site are query optimization (missing indexes, N+1 queries from plugins), connection overhead, and hardware, not which database engine is running underneath.
Where performance differences do appear:
Read-heavy workloads: MariaDB has historically had a faster thread pool implementation, which can benefit high-concurrency read workloads on shared hosting. MySQL 8.0 narrowed this gap significantly.
Write-heavy workloads: MySQL 8.0’s improvements to InnoDB internals generally benefit write-heavy workloads. WooCommerce stores processing many simultaneous orders may see differences here.
Query optimizer: Both have sophisticated query optimizers but they make different decisions in some cases. A query that is fast on one may be slower on the other due to different optimization paths. This rarely matters for standard WordPress queries but can matter for complex custom queries.
The honest answer is that for most WordPress sites, you will not notice the difference in day-to-day performance. Configuration and hardware matter far more than which of the two you are running.
Compatibility
For standard WordPress installations, MySQL and MariaDB are effectively interchangeable. WordPress core supports both and has for years. WooCommerce, the major page builders, and most popular plugins work correctly on either.
Compatibility issues arise at the edges:
MySQL 8.0 reserved words: MySQL 8.0 added new reserved words that conflict with column or table names in some older plugins. A plugin that worked on MySQL 5.7 or MariaDB may throw errors on MySQL 8.0 because it uses a word that is now reserved. This is a known migration issue with a straightforward fix (quoting the identifier) but it can catch you off guard.
Authentication changes: As mentioned above, MySQL 8.0’s default authentication plugin change can break older client libraries. Most modern PHP versions and WordPress installations handle this correctly, but legacy setups may not.
JSON behavior: Plugins that store data in JSON columns and use MySQL-specific JSON functions may not work correctly on MariaDB due to the different JSON implementation.
Migrating between them: Migrating a WordPress database from MariaDB to MySQL or vice versa generally works without issues for standard WordPress tables. Export via mysqldump, import into the other database, and WordPress will function normally. Edge cases appear with plugins that use database-specific features.
Which should you use for WordPress
For most WordPress sites, the correct answer is whichever one your hosting provider runs well-configured and keeps updated. The operational quality of the database setup – regular updates, proper configuration, adequate memory for the InnoDB buffer pool, regular backups – matters more than which of the two you are on.
If you are choosing between hosting providers where one runs MySQL 8.0 and one runs MariaDB, the database choice alone should not be the deciding factor. Evaluate the hosting stack as a whole.
If you are self-hosting and making the choice yourself:
Choose MySQL 8.0 or 8.4 if you want the most feature-complete implementation, the best JSON support, strong observability tooling, and Oracle’s long-term investment in the codebase. MySQL 8.4 is the current LTS release with long-term support through 2032.
Choose MariaDB if you prefer a fully community-driven open source project, want broader compatibility with older client libraries, or are running a stack where MariaDB’s specific features (Galera Cluster, certain storage engines) are relevant.
For WordPress specifically, neither choice is wrong.
What Hostney runs
Hostney runs MySQL. Servers on Rocky Linux 9 run MySQL 8.0, and newer servers on Rocky Linux 10 run MySQL 8.4, the current LTS release.
MySQL 8.0 and 8.4 are fully supported by WordPress core, WooCommerce, and all major plugins. The InnoDB buffer pool is configured per-account based on plan allocation, and query execution is isolated per container so one site’s heavy queries do not affect another’s response times.
If you are migrating a site from a host running MariaDB, the migration process is straightforward for standard WordPress installations. Export your database with mysqldump, import it into MySQL, and WordPress will run without modification. If you encounter issues with reserved word conflicts or authentication, support can walk through the specific fix.
Summary
MySQL and MariaDB share a common origin but have diverged meaningfully over the past decade. MySQL 8.0 and 8.4 offer better JSON support, stronger observability, and continued investment from Oracle. MariaDB offers a community-driven development model, broader legacy client compatibility, and features like Galera Cluster for specific high-availability use cases.
For WordPress, both are fully supported and the performance difference in typical workloads is not significant. The quality of the hosting configuration around the database matters more than which one is running. If you are evaluating hosts, look at buffer pool sizing, query isolation, backup frequency, and MySQL version rather than whether it is MySQL or MariaDB.