MariaDB vs MySQL in 2026

The Fork That Won’t Die

MariaDB wins for home labs running multi-node Galera replication or mixed transactional and analytical workloads, and MySQL wins if you need strict Oracle-ecosystem consistency or don’t want to relearn anything.

MariaDB’s first release landed on 29 October 2009, which makes it 17 years old. Michael “Monty” Widenius forked it while Oracle’s acquisition of Sun Microsystems was still pending, not after: the deal closed in January 2010, months after MariaDB 5.1 shipped. He built it as a drop-in replacement, promised speed and openness, and here we are in 2026 with both databases still worth your consideration. Forks usually don’t work out that way. Either the parent wins or the fork does. Instead, MariaDB became the faster, scrappier sibling while MySQL stayed chained to the Oracle machine.

If you’re self-hosting or picking a database for your homelab, this decision matters. Not in a “oh no I chose wrong” way, because both have years of production behind them. But these two have diverged enough that your actual workload determines which one saves you headaches.

Versions checked September 2026: MariaDB 12.3.3 (LTS, released May 2026) and MySQL 9.7.3 (LTS, released April 2026). Every behavior claim below was run against MariaDB 12.3.3 and MySQL 8.4.11 in containers.

Should You Run MariaDB or MySQL in Your Homelab?

The Oracle Shadow

Oracle owns MySQL. That’s a fact which shapes everything, and it isn’t a scandal. MySQL’s development moves at a corporate pace. Releases happen. Features land. But they answer to Oracle’s roadmap, which prioritizes enterprise competitors, not the home labber running a 2-core VPS.

MariaDB’s governance is different, though not in the way most comparisons claim. Two entities exist: the MariaDB Foundation, a Delaware non-profit founded in December 2012 that safeguards open development, and MariaDB plc, the commercial company that owns the trademark and contributes most of the code.

Here is the part that gets written up wrong constantly. MariaDB plc is not a scrappy profitable independent. It went public in 2022 through a SPAC merger with Angel Pond Holdings, the stock collapsed, and in September 2024 private equity firm K1 Investment Management bought all outstanding shares for roughly $37 million and took it private. For scale, the SPAC deal had valued the company in the hundreds of millions. So when you pick MariaDB, you’re picking a database whose main corporate backer is PE-owned, with a non-profit Foundation as the actual structural guarantee of openness. The Foundation is the reason to feel good here, not the company.

Does that make MariaDB a bad choice? No. Development is healthy, the May 2026 releases took contributions from 57 people outside MariaDB plc, and the code is GPLv2 regardless of who owns the trademark. But “profitable company, not venture-funded chaos” is the opposite of what happened, and if your reason for choosing MariaDB is corporate independence, the Foundation is the thing you’re relying on.

MySQL still gets updates on a predictable cadence. MySQL 9.7 became the current LTS in April 2026 with support through 2034. If you’re still on 8.0, note that it reached end of life on 30 April 2026, so that’s the upgrade to schedule. 8.4 remains supported until April 2032.

Storage Engines: Where Personality Emerges

Both use InnoDB by default. The difference shows up when you dig deeper.

MySQL sticks with InnoDB for everything that matters. MyISAM’s still there (for reasons), but it’s a museum piece. MySQL’s philosophy: one engine, optimized to death.

MariaDB says “you do you.” Aria (crash-safe replacement for MyISAM), ColumnStore (analytical queries), MyRocks (if you love compression), and Mroonga (full-text search that doesn’t suck) are all available. Aria is compiled in. ColumnStore and MyRocks usually arrive as separate packages (mariadb-plugin-columnstore, mariadb-plugin-rocksdb) that you install and enable, so “ships with” oversells it slightly. They’re one apt install away rather than bundled.

Example: you’ve got a logging table that grows 50 million rows a month and you mostly query it for analytics. In MySQL, you’re reaching for a separate system (ClickHouse, Timescale, whatever). In MariaDB, you convert that table to the ColumnStore engine and handle it inside the same server. Fewer moving parts, one backup strategy.

In practice: running straight transactional workloads (web app database), InnoDB’s fine in both. Mixing transactional and analytical, MariaDB’s flexibility saves you a second system.

JSON Support: Show of Hands

MySQL’s had JSON since 5.7. It’s a first-class binary data type with functions: JSON_EXTRACT, JSON_ARRAY_APPEND, all that.

MariaDB got JSON functions in 10.2, and most of them are compatible: JSON_EXTRACT, JSON_SET, the usual suspects work in both. Two differences bite.

First, MariaDB’s JSON is not a distinct storage type. It’s an alias. Create a column as JSON in MariaDB 12.3 and ask what you actually got:

CREATE TABLE events (data JSON);
SHOW CREATE TABLE events;
-- data longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin
--   DEFAULT NULL CHECK (json_valid(`data`))

Text plus a validation constraint. MySQL stores parsed binary JSON, which is why MySQL can index into a document without reparsing it. For small documents you’ll never notice. For large ones under heavy read load, you will.

Second, the shorthand arrow operators are a MySQL thing:

-- Works in both (function form)
SELECT JSON_EXTRACT(data, '$.user.name') FROM events;

-- MySQL only
SELECT data->>'$.user.name' FROM events;

Run that second query on MariaDB 12.3.3 and you get:

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that
corresponds to your MariaDB server version for the right syntax to use near
'>'$.user.name' FROM events' at line 1

Still unimplemented, 17 years in. If you’ve leaned on that shorthand in MySQL, you’ll be rewriting those queries as JSON_EXTRACT or JSON_VALUE calls when you migrate. Not a dealbreaker, but it’s the kind of “drop-in replacement, mostly” footnote worth knowing before you flip the config.

Replication: Multi-Master Complexity

This is where the fork’s history matters.

MySQL built Group Replication in-house. It’s a Paxos-derived group communication system, not a Galera derivative, whatever the blog posts say. Multi-master aware, and it wants configuration:

[mysqld]
binlog_format=ROW
server-id=1
gtid_mode=ON
enforce_gtid_consistency=ON
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=ON

MariaDB bundles Galera Cluster for synchronous multi-master. Worth knowing who builds it: Galera is developed by Codership, an independent company, and MariaDB integrates and ships it. Same technology as Percona XtraDB Cluster uses, not an in-house MariaDB project:

[mariadb]
wsrep_on=ON
wsrep_cluster_name="sumguy"
wsrep_cluster_address="gcomm://db1,db2,db3"
wsrep_node_address="db1"
wsrep_node_name="node1"

If you’re running 2 or 3 database nodes at home and want true multi-master rather than master-replica, MariaDB’s path is shorter and more predictable when a node dies. One caveat that catches people: Galera requires every table to have a primary key, and it only works with InnoDB. That logging table you were going to put on ColumnStore won’t replicate through Galera.

MySQL’s Group Replication works. It’s the enterprise choice. For small deployments it’s like hiring an accountant to balance a personal checkbook.

Statement vs Row-Based Replication

Both default to ROW in current versions. Older guides claim MariaDB defaults to MIXED, and that was true for years, but MariaDB 12.3.3 reports ROW out of the box, same as MySQL. Check yours rather than trusting either claim:

SELECT @@binlog_format;

Row-based is safer and handles large transactions predictably, at the cost of much larger binary logs during bulk updates. If your binlog volume is hurting a storage-constrained box, MIXED is still available on both, and both let you set binlog_row_image=MINIMAL to log only changed columns, which usually helps more.

Developer Features: The Death Cuts

Window functions: both have them. MySQL 8.0+, MariaDB 10.2+. Query-writing feels less awful.

Common table expressions: both support them, recursive included.

Generated columns: both have them, and both default to VIRTUAL (computed on read, no storage). A lot of comparisons claim MariaDB persists them by default. It doesn’t:

CREATE TABLE g (a INT, b INT AS (a*2));
-- MariaDB 12.3.3: b int(11) GENERATED ALWAYS AS (`a` * 2) VIRTUAL
-- MySQL 8.4.11:   b int GENERATED ALWAYS AS ((`a` * 2)) VIRTUAL

Ask for storage explicitly. MariaDB spells it PERSISTENT, MySQL spells it STORED, and that spelling difference is a real migration gotcha.

CHECK constraints: MariaDB 10.2 enforces them. MySQL added enforcement in 8.0.16, and earlier 8.0.x releases parsed and silently ignored them, which is a fun way to discover your constraints never existed.

These aren’t glamorous, but they’re the difference between writing sensible SQL and working around database limitations.

Performance: Real Talk

You’ll see benchmarks. “MariaDB’s 20% faster!” “MySQL’s caught up!” Both are true for some workload, on some hardware, at some version, which means neither is useful to you.

I’m not going to invent numbers here. The published comparisons that matter are workload-specific, and the honest summary is that at homelab scale (a few hundred concurrent connections, moderate query complexity), neither engine is your bottleneck. Your schema design is. Your indexes are. Your disk is. If you want a number for your setup, run sysbench against both with your own schema and query mix. That takes an afternoon and beats every blog post, including this one.

The Short Version

Choose MariaDB if:

• You want 2 or 3 nodes with true synchronous replication and a short path to get there
• You’re mixing transactional and analytical workloads (Aria, ColumnStore)
• You want new features sooner
• You’re suspicious of Oracle (valid), and the Foundation’s non-profit structure satisfies you
• Your distro already ships it as the default (Debian, Fedora, Arch all do)

Choose MySQL if:

• You’re in an Oracle shop and need consistency across databases
• You want the option most third-party docs assume
• You’d rather depend on Oracle than on a PE-owned company plus a non-profit
• Your workload’s standard transactional (web app, CRUD stuff)
• Your team knows MySQL inside-out and MariaDB’s just another fork to learn
• You need native binary JSON or the -> shorthand

The real answer: in 2026 you can’t go badly wrong. Both are maintained, both have long LTS windows, both work in containers, both have good backup tooling. Pick one, understand its replication model, move on.

The bigger win is not running a database you don’t need. SQLite for local stuff. Redis for caching. ClickHouse if you’re actually doing analytics. MariaDB or MySQL for transactional data.

Migration: Harder Than It Used to Be

“Drop-in replacement” was accurate when the reference point was MySQL 5.5. It is not accurate for MySQL 8.x and up, and MariaDB says so in its own documentation: the two have diverged on system tables, the data dictionary, JSON storage, GTID formats, authentication plugins, and roles. There is no in-place binary upgrade path between them in either direction.

The supported route is a logical dump and reload:

mysqldump --all-databases --single-transaction --routines --events \
  -u root -p > dump.sql
# then load into the other server and re-test everything

Going MySQL to MariaDB, expect to fix -> shorthand, STORED versus PERSISTENT generated columns, caching_sha2_password accounts, and anything touching mysql.* system tables. Going MariaDB to MySQL is rougher if you’ve leaned into Galera, Aria, ColumnStore, or MariaDB-only SQL. Either way you’ll spend more time testing than migrating, and you should keep the source server running until you’re done.

The Ecosystem Still Matters More

Nobody talks about this: your database doesn’t exist in a vacuum. The tooling around it does more work than the engine itself.

• Backups: Percona XtraBackup works for MySQL. For MariaDB 10.3+, use mariabackup, which is MariaDB’s fork of it. XtraBackup and modern MariaDB are not interchangeable.
• Failover: Orchestrator handles MySQL and MariaDB topologies. MaxScale (MariaDB) and ProxySQL (both) cover routing and failover. Patroni does not apply here at all, it’s a PostgreSQL-only project, despite showing up in MySQL HA listicles.
• Monitoring: mysqld_exporter feeds Prometheus for both. Percona Monitoring and Management covers both. Grafana dashboards exist for both.
• ORMs: every framework supports both, usually through the same driver.

Your database is a utility. The infrastructure around it, backups, monitoring, failover automation, is where you’ll actually spend your time. Pick the database, then invest in those systems.

The Pragmatist’s Choice

Spinning up a homelab database in 2026, I’m reaching for MariaDB. Faster Galera setup, it’s the default on most distros, and the Foundation gives the openness claim some teeth. But I’m not losing sleep if I have to use MySQL, and I’d pick MySQL without hesitation for anything leaning hard on JSON.

The real risk is thinking this choice is permanent. Migrate if your needs change, budget a weekend for the dump and reload, and test it first. It’s a database, not a religion.

Pick one, set up good backups, monitor the metrics, and get back to building stuff.

Common Questions

Is MariaDB still a drop-in replacement for MySQL?

No, not since MySQL 8.0. The two diverged on system tables, the data dictionary, JSON storage, GTID format, and authentication plugins, and there’s no in-place binary upgrade in either direction. Migration means a mysqldump and reload, plus fixing MySQL-only syntax like the -> operator.

Which MariaDB and MySQL versions should I run in 2026?

MariaDB 12.3 is the current LTS, supported to June 2029, with 11.8 as the conservative choice to June 2028. MySQL 9.7 became LTS in April 2026 with support through 2034, and 8.4 runs to April 2032. MySQL 8.0 reached end of life on 30 April 2026.

Does MariaDB support the JSON -> operator?

No. MariaDB 12.3.3 still rejects -> and ->> with a syntax error, 17 years into the fork. Use JSON_EXTRACT or JSON_VALUE instead, which work identically in both databases. MariaDB’s JSON type is also an alias for longtext with a json_valid() check, not native binary storage.

Can I use Patroni for MySQL or MariaDB high availability?

No. Patroni is a PostgreSQL-only project despite appearing in MySQL HA guides. For MySQL and MariaDB, use Orchestrator for topology management and failover, MaxScale or ProxySQL for routing, or Galera Cluster for synchronous multi-master on MariaDB.

Who owns MariaDB?

Two entities. The MariaDB Foundation is a non-profit that safeguards open development and holds no commercial stake. MariaDB plc owns the trademark and writes most of the code, and it has been owned by private equity firm K1 Investment Management since September 2024, when K1 bought it for roughly $37 million.

Related Reading

• Automatic Backup of Docker MySQL or MariaDB Containers
• DBeaver vs pgAdmin vs DataGrip
• MongoDB Self-Hosted in 2026: SSPL and Alternatives
• PgBouncer for Connection Pooling
• Postgres in Docker: The Durable Setup