The Fork That Won’t Die
It’s been 15 years since Michael “Monty” Widenius walked away from MySQL after Oracle bought Sun Microsystems in 2010. He started MariaDB as a drop-in replacement, promised speed and openness, and here we are in 2026 — and somehow both databases are still worth your consideration. That’s not supposed to happen. Forks are supposed to die. Either the parent wins or the fork does. Instead, MariaDB’s become the faster, scrappier sibling while MySQL’s 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 — both are production-grade, widely deployed, battle-tested. But in a “these two have diverged enough that your actual workload determines which one saves you headaches” way.
Let’s dig past the forks and talk about what actually matters.
The Oracle Shadow
Here’s the elephant: Oracle owns MySQL. That’s not a scandal — it’s a fact that shapes everything. MySQL’s development moves at a corporate pace. Releases happen. Features land. But they’re beholden to Oracle’s roadmap, which prioritizes enterprise SQL Server competitors, not the home labber running a 2-core VPS.
MariaDB’s different. It’s backed by the MariaDB Foundation and MariaDB Corporation (a profitable company, by the way — not venture-funded chaos). They move faster. They’re chasing growth, not shareholder returns. The team actually responds to community requests. That’s not sentiment; that’s just how different incentives play out.
MySQL still gets updates. Version 8.4 (LTS) is solid. But if you need something bleeding-edge — better performance, new features, quicker fixes — MariaDB hits the gas first.
Storage Engines: Where Personality Emerges
Both use InnoDB by default these days. But watch what happens when you dig deeper.
MySQL sticks with InnoDB for 99% of cases. 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.” It ships with Aria (faster for read-heavy workloads), ColumnStore (analytical queries), MyRocks (if you love compression), and Mroonga (full-text search that doesn’t suck). You don’t have to use them. But they’re there, ready to solve specific problems without installing a separate database.
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 spin up a ColumnStore partition and handle it inside the database. Simpler, fewer moving parts.
In practice: If you’re running straight transactional workloads (web app database), InnoDB’s fine in both. If you’re mixing transactional + analytics, MariaDB’s flexibility saves you infrastructure.
JSON Support: Show of Hands
MySQL’s had JSON since 5.7. It’s a first-class data type with functions. JSON_EXTRACT, JSON_ARRAY_APPEND, all that.
MariaDB got JSON support later (10.2), but it’s different. It’s compatible with MySQL’s JSON functions, but MariaDB also gives you native JSON operators borrowed from PostgreSQL syntax:
-- MySQL style (both support)SELECT JSON_EXTRACT(data, '$.user.name') FROM events;
-- MariaDB also supports PostgreSQL-ishSELECT data->'user'->>'name' FROM events;It’s not a game-changer unless you’re migrating from Postgres and want familiar syntax. But it’s the kind of thing that makes MariaDB feel less like “MySQL’s little brother” and more like “we thought about this differently.”
Replication: Master-Master Complexity
Here’s where the fork’s history matters.
MySQL moved to Group Replication (Galera-inspired but built in-house). It’s robust, multi-master aware, requires configuration. Works fine, but it’s enterprise-feeling. Setup:
# MySQL Group Replication - simplified config[mysqld]binlog_format=ROWserver-id=1gtid_mode=ONenforce_gtid_consistency=ONgroup_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"group_replication_start_on_boot=ONMariaDB ships with true multi-master replication out of the box. Galera Cluster is built-in (same tech, same team). Simpler setup, synchronous writes, easier failover:
# MariaDB Galera - synchronous multi-master[mariadb]wsrep_on=ONwsrep_cluster_name="sumguy"wsrep_cluster_address="gcomm://db1,db2,db3"wsrep_node_address="db1"wsrep_node_name="node1"If you’re running 2-3 database nodes in your homelab and want true multi-master (not just master-replica), MariaDB’s easier to set up and more predictable when a node fails.
MySQL’s Group Replication works. It’s the enterprise choice. But for small deployments, it’s like hiring an accountant to balance a personal checkbook.
JSON vs Row-Based Replication
MySQL prefers row-based replication. Safer, handles large transactions better, but can generate massive binary logs if you’re doing bulk updates.
MariaDB defaults to MIXED replication mode (statement-based where safe, row-based where not), but pure row-based is available. For self-hosted setups with limited storage, avoiding full row logging keeps your binary log footprint manageable.
Developer Features: The Death Cuts
Window Functions — Both have ‘em now. MySQL 8.0+, MariaDB 10.2+. Query-writing feels less awful.
Common Table Expressions (CTEs) — Both support. MariaDB’s recursive CTEs work better for tree/graph queries.
Generated Columns — MySQL’s got them. MariaDB’s got ‘em. Handy for computed fields. MariaDB’s are persistent by default, MySQL requires you to ask for it.
CHECK constraints — MariaDB 10.2 actually enforces them. MySQL added enforcement in 8.0.16 (earlier 8.0.x versions parsed and ignored them), so older MySQL setups silently dropped your constraints without warning.
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 in 8.4!” Both are true some of the time.
In actual homelab conditions (a few hundred concurrent connections, moderate query complexity):
- MariaDB wins on bulk operations and parallel replication
- MySQL wins on complex analytical queries
Neither’s going to be your bottleneck if you’ve got decent hardware. Your schema design will be. Your indexes will be. The database choice is downstream of that.
Here’s the Honest Take
Choose MariaDB if:
- You want to self-host 2-3 database nodes with true synchronous replication
- You’re mixing transactional + analytical workloads (Aria, ColumnStore)
- You like moving fast and having access to new features quickly
- You’re suspicious of Oracle (valid)
- Your setup’s complex enough that you’d benefit from built-in Galera
Choose MySQL if:
- You’re in an Oracle shop and need consistency across databases
- You want the “enterprise standard” (fair reason, actually)
- You’re paranoid about dependency on a smaller company
- Your workload’s standard transactional (web app, CRUD stuff)
- Your team knows MySQL inside-out and MariaDB’s just another fork to learn
The real answer: In 2026, you can’t go wrong. Both are solid, both get updates, both work in containers, both have good backup tooling. Pick one, understand its replication model, and move on. Don’t let this decision paralyze you.
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, full stop.
Migration: Easier Than You’d Think
If you’re running MySQL and want to try MariaDB (or vice versa), the path’s smooth. MariaDB’s literally built as a drop-in replacement. Back up your mysqldump, restore into MariaDB, flip the config, restart. You’ll probably spend more time testing than migrating.
The reverse (MariaDB → MySQL) is slightly rougher if you’ve leaned into MariaDB-specific features (Galera, Aria tables), but still manageable. Just don’t drop anything fancy into production without a test run.
The Ecosystem Still Matters More
Here’s the thing nobody talks about: your database doesn’t exist in a vacuum. The tooling around it does more work than the engine itself.
- Backups: Percona’s XtraBackup works for both. Use it.
- Replication: Streaming replication works. Automated failover (Orchestrator, Patroni) works.
- Monitoring: Prometheus exporters for both. Grafana dashboards exist. Check your metrics.
- ORMs: Every framework supports both equally.
Your database’s 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
If I’m spinning up a homelab database in 2026, I’m reaching for MariaDB. Faster Galera setup, modern features by default, community that moves at human speed, no Oracle shadow. But I’m not losing sleep if I have to use MySQL. Both are production-grade. Both will outlive your home lab.
The real risk is thinking this choice is permanent. It’s not. Migrate if your needs change. It’s a database, not a religion.
Pick one, set up good backups, monitor the metrics, and get back to building stuff. That’s where the real work happens.
