Does WordPress use MySQL or MariaDB?

WordPress's current requirements recommend either MariaDB 10.11 or later or MySQL 8.0 or later. That makes both viable for WordPress core at the stated versions. Check every plugin, backup tool, hosting extension, and migration utility separately, because WordPress's general requirement does not certify the rest of your operating stack.

Which database is included with Ubuntu 24.04?

Ubuntu 24.04 LTS offers separate MySQL and MariaDB server packages. The Noble package index inspected on 7 September 2026 listed MySQL on the 8.0 line and MariaDB on the 10.11 line. Security revisions vary by architecture and change over time, so record the exact candidate from your approved repository before installation.

Can MySQL and MariaDB replicate with each other?

Do not assume direct compatibility. MariaDB documents that its GTID structure differs from MySQL's and that the formats cannot be mixed directly. JSON, authentication, collations, and binary-log features can add further constraints. Design replication from the exact product documentation, prove it in an isolated environment, and use a single supported topology rather than combining defaults from both products.

Stack Guides

MySQL vs MariaDB for a LEMP Stack: Which to Install and When It Matters

Q: Is MariaDB a drop-in replacement for MySQL?

Do not assume it is. The products retain broad protocol and SQL compatibility, but modern releases differ in JSON storage, authentication, collations, system variables, and GTID replication. Treat a move between them as a migration: use the target product's documented logical path, test a production-shaped copy, prove restore and rollback, and keep the source intact until acceptance is complete.

LEMP Field Notes · Updated 2026-09-07 · 6 min read

MySQL vs MariaDB for a LEMP Stack: Which to Install and When It Matters

In briefChoose the database your application, extensions, backup tools, and hosting platform explicitly support. MySQL is the safer choice for MySQL-specific JSON, authentication, or replication features. MariaDB is appropriate when the application certifies it and your operations already use MariaDB tooling. Modern releases are separate products, not automatic drop-in replacements, so test the exact versions, schema, queries, accounts, backups, and restore path before committing.

Contents

Should a LEMP stack use MySQL or MariaDB?
What is the practical difference in a LEMP stack?
Which database does Ubuntu 24.04 package?
Does WordPress support both MySQL and MariaDB?
Where have MySQL and MariaDB diverged?
Is MariaDB a drop-in replacement for MySQL?
What should you test before committing?
Which one should a new LEMP project choose?
Sources

Should a LEMP stack use MySQL or MariaDB?

Use the database version your application, extensions, backup tooling, and hosting plan explicitly support. MySQL is the safer default when vendor documentation names MySQL or the application depends on MySQL-specific JSON, authentication, or replication features. MariaDB is a sound choice when the application certifies it and you prefer Ubuntu's MariaDB packages or MariaDB's own ecosystem. Do not choose on the old claim that they are interchangeable. Modern releases require separate compatibility testing.

This is a desk-researched product comparison, not a benchmark. No database was load-tested for this article, so it does not rank either server by speed.

What is the practical difference in a LEMP stack?

LEMP means Linux, Nginx, a MySQL-compatible database, and PHP. Nginx does not care whether the application stores data in MySQL or MariaDB. PHP normally connects through PDO or MySQLi, while the application and database server determine which SQL, authentication, data types, and operational features are valid.

MariaDB began as a MySQL-compatible server, and the two still share much of the client protocol and familiar SQL surface. They are now separate products with separate release lines. Compatibility at connection time does not prove that a schema, query set, replication topology, or restore procedure will behave identically.

Decision area	Prefer MySQL when	Prefer MariaDB when
Application support	The vendor certifies a specific MySQL release	The vendor certifies a specific MariaDB release
Existing estate	Backups, replicas, monitoring, and staff procedures already target MySQL	Those operational dependencies already target MariaDB
JSON use	The application relies on MySQL's native JSON storage or MySQL-specific functions	JSON is used within MariaDB's documented text-backed model and tested there
Replication	The design uses MySQL GTIDs or MySQL Group Replication	The design uses MariaDB's replication model and tooling
Migration risk	The source system is already MySQL	The source system is already MariaDB

For a conventional PHP site that uses ordinary InnoDB tables and supported SQL, either may be viable. The decisive word is supported.

Which database does Ubuntu 24.04 package?

Ubuntu 24.04 LTS offers both servers as distinct packages. On 7 September 2026, Ubuntu's Noble package index listed the mysql-server metapackage on the MySQL 8.0 line and mariadb-server on the MariaDB 10.11 line. The exact security revision differed by architecture, and it will change again as updates ship.

That means Ubuntu does not make the architectural choice for you. Selecting the MySQL package installs MySQL; selecting the MariaDB package installs MariaDB. Record the repository, architecture, package version, and application requirement before installation. A tutorial's version string is only a historical observation.

For the wider server build, use the Ubuntu 24.04 LEMP installation guide, then replace its database choice only when the application's support matrix permits it.

Does WordPress support both MySQL and MariaDB?

Yes, within WordPress's stated version floor. The current WordPress requirements page recommends MariaDB 10.11 or later or MySQL 8.0 or later. That supports either database family for WordPress itself; it does not certify every plugin, managed-host extension, backup utility, or migration path.

Apply the same rule to any PHP application. Read its current requirements and upgrade notes. Check the exact release you intend to run, not just the product name. An application may support both families generally while an extension uses a function, collation, or administrative feature available in only one.

Where have MySQL and MariaDB diverged?

The largest risk is not ordinary SELECT, INSERT, or UPDATE statements. It is code and operations that touch product-specific behavior.

JSON is not the same storage type

MySQL 8.4 documents JSON as a native type. It validates documents and stores them in an internal binary format designed for direct access to members. MariaDB documents JSON as an alias for LONGTEXT COLLATE utf8mb4_bin, with JSON validation applied through a constraint.

Both can accept and query JSON, but identical type names do not imply identical storage, functions, indexing options, comparison behavior, or replication. Inventory every JSON column and function before choosing or migrating. Test generated columns, indexes, path expressions, duplicate-key handling, and export/import behavior with representative data.

GTIDs and replication are product-specific

MariaDB's current compatibility documentation says its Global Transaction ID structure differs from MySQL's and that the formats cannot be mixed directly. MySQL also documents Group Replication as its own feature with explicit requirements and limitations.

Do not design a mixed topology from the phrase “MySQL-compatible.” Choose one documented replication model, verify that backups restore into the target release, and rehearse failover outside production. If a managed service is involved, its supported engines and replication controls take priority.

Authentication and administration can differ

Account plugins, password policies, roles, system variables, configuration names, and administrative utilities have diverged. A PHP connector speaking the shared protocol may connect successfully while an old deployment script, monitoring check, or user-creation statement fails.

List every dependency that talks to the database: the application runtime, command-line clients, backup jobs, schema migration tools, monitoring exporters, reporting systems, and replicas. Confirm each against the exact target version.

Is MariaDB a drop-in replacement for MySQL?

Treat “drop-in replacement” as historical context, not a migration plan. MariaDB's compatibility matrix says the projects preserve broad compatibility but identifies high-impact differences in authentication, JSON, collations, variables, and GTIDs. Its upgrade guidance specifically tells MySQL 8.0 users to use a logical dump when moving to MariaDB rather than swapping server binaries over the existing data directory.

A safe evaluation uses a copy of production-shaped data in an isolated environment. Restore through the target product's documented logical path, run schema migrations, compare row counts and critical queries, exercise login and background jobs, and test a second restore. Preserve the original backup and source server until the acceptance and rollback criteria are complete.

Never point the other database server at an existing production data directory. Physical files, system tables, redo logs, and upgrade state are version-specific. A logical migration is slower than wishful thinking but easier to audit.

What should you test before committing?

Use a short acceptance sheet with observed results:

Support: record the application and extension pages that name the exact database family and minimum release.
Schema: load a fresh copy and check tables, views, triggers, stored routines, generated columns, collations, and foreign keys.
Queries: run the application's automated tests plus representative reads, writes, searches, reports, and background jobs.
Identity: test application accounts, administrative access, password rotation, TLS requirements, and least-privilege grants.
JSON and SQL modes: exercise every nontrivial JSON expression and any query affected by strictness, grouping, dates, or reserved words.
Operations: prove backup, restore, monitoring, log collection, upgrade, and rollback procedures.
Capacity: measure the candidate under the application's own workload. Do not import a benchmark from unrelated hardware or data.

Pass or fail each item. “It started” is not an acceptance result.

Which one should a new LEMP project choose?

Choose in this order:

If a commercial application or managed platform specifies one engine, use that engine and supported release.
If an existing system is being moved, remain on its current database family unless a documented requirement justifies the migration.
If a new application uses MySQL-native JSON, Group Replication, or other MySQL-specific behavior, choose MySQL.
If the application explicitly supports MariaDB and the operating team standardizes on its packages and tooling, choose MariaDB.
If both remain valid, prototype both from the same schema and select on operational fit: supported upgrades, restore evidence, observability, staff familiarity, and exit cost.

Do not select MariaDB because it once behaved like a transparent MySQL substitute. Do not select MySQL because its name appears in the letter M of LEMP. Select the supported system you can restore, monitor, upgrade, and migrate deliberately.

Sources

An independent publication. Not affiliated with any prior owner of this domain.