If you’re reading this, chances are you already have strong opinions — or at least strong curiosity — about MySQL vs MariaDB.
And that makes sense. These are the two most widely deployed open-source relational engines in the world, powering everything from early-stage SaaS apps to global-scale commerce systems.
But here’s something interesting we noticed before even beginning our bench-marking:
Most organizations today are still on MySQL 8.0 or MariaDB 10.6/10.11.
Not because the newer versions are problematic — but simply because production systems don’t upgrade lightly.
So before we talk numbers, let me answer the most obvious question:
Why Benchmark the Newest LTS Releases If Many Aren’t Using Them Yet?
At GenexDBS, we benchmark emerging versions for one simple reason:
The architecture of the future is shaped by the releases of today.
MySQL 8.4 and MariaDB 11.8 introduce changes — especially around durability, optimizer behavior, replication, and resource management — that will influence how platforms behave in the coming years.
When customers eventually ask,
“What should we expect if we move to the latest LTS?”
—we want to answer with confidence backed by data, not assumptions.
So think of this blog as a field report.
Not a comparison to declare a winner, but a guided walk-through of how these engines behave when placed under the same workload, on the same hardware, with the same settings.
Our Benchmark Philosophy — Keep It Simple, Keep It Fair
We intentionally avoided “hero tuning” or hidden optimizations.
Both MySQL 8.4.7 and MariaDB 11.8.3 ran:
- On the same Ubuntu host
- Inside Docker containers
- With default InnoDB durability settings
- With identical datasets and sysbench workloads
We tested:
- OLTP read/write
- Read-only
- Write-only
- Bulk insert
- JSON workloads
- Analytical JOINs
- Durability modes
Every scenario had one purpose:
Observe behavior, not manipulate performance.
That turned out to be the right decision, because what we uncovered early on completely changed our test strategy.
A Critical Discovery: Binary Logging Was Disabled in MariaDB
Our first test showed MariaDB significantly outperforming MySQL in write-heavy workloads — almost too much.
This triggered an internal audit of the configs, and we found:
- MySQL → log_bin = ON (default in Community Edition)
- MariaDB → log_bin = OFF (default unless explicitly enabled)
That alone invalidated the comparison.
Binary logging isn’t just a box to tick — it introduces real fsync operations, affects group commit, and changes transaction durability guarantees.
Comparing a binlog-off engine to a binlog-on engine is not bench-marking — it’s misdirection.
So we corrected it and re-ran everything under three controlled configurations:
Benchmark Scenarios
Scenario 1 — MariaDB with binlog enabled (to match MySQL’s durability)
This brought the engines closer in fairness without altering threading or log sizes.
Scenario 2 — MariaDB with binlog + thread pool
MariaDB ships with a thread pool that the community edition of MySQL does not include.
We tested this to reflect a realistic deployment where users enable thread pooling for scalability.
Scenario 3 — Aligning MariaDB to MySQL’s durability model
This included:
- innodb_flush_log_at_trx_commit = 1
- sync_binlog = 1
- innodb_doublewrite = ON
- InnoDB log file sizes matched
- Auto-increment lock mode aligned
- Adaptive hash index disabled
- Thread handling forced to per-connection
This scenario was the closest we could get to “apples to apples.”
With this foundation set, the results began to tell a clear and meaningful story.
OLTP Read/Write — The Real-World Workload
This is where most applications live — mixes of inserts, updates, deletes, and reads.
Here’s what we observed:
MariaDB:
- Delivered higher TPS
- Scaled more aggressively with increasing thread count
- Benefited from commit grouping behavior
MySQL:
- Displayed more stable latency
- Showed predictable behavior at all thread levels
- Maintained strict durability sequencing
In practical terms:
MariaDB pushes harder; MySQL plays safer.
Applications that care deeply about throughput (e.g., order ingestion, event logging, queue processing) may feel MariaDB’s advantage.
Applications that prioritize predictable latency (e.g., payments, transactional systems) will appreciate MySQL’s discipline
Read-Only Workloads — Nearly Identical Until High Concurrency
Up to moderate thread counts, MySQL and MariaDB behave almost the same.
Once concurrency climbs higher, MySQL begins to pull slightly ahead due to years of internal mutex and buffer pool refinement.
For read-heavy systems, the choice rarely hinges on engine performance.
Write-Only Workloads — A Clear Contrast
This category exposed the sharpest difference.
MariaDB (with binlog ON):
Even with durability enabled, MariaDB:
- Showed significantly higher write throughput
- Continued scaling linearly through higher concurrency
- Benefited from relaxed intermediate flush paths
MySQL:
Remained consistent, but:
- Every transaction followed strict redo + binlog fsync
- Group commit had less room to batch writes
If your operational workload is extremely write-intensive, the difference is not subtle — it directly affects hardware sizing, CPU consumption, and queueing behavior.
Bulk Load Performance — ETL Teams, Take Note
MariaDB completed bulk imports faster.
Why?
- It builds secondary indexes more efficiently
- It minimizes log churn during massive inserts
- It uses more flexible buffering strategies
MySQL takes a more conservative, durability-biased approach that is safer but slower.
In real-world migration or data warehousing pipelines, this can translate to hours saved.
Analytical JOINs — How the Optimizers “Think”
This was one of the most interesting parts of the benchmark.
MySQL 8.4
Prefers nested loop joins with selective index lookups.
Very efficient for queries where join relationships have high selectivity.
MariaDB 11.8
Prefers hash joins more often.
Shines when large result sets must be combined.
Which one is better?
It depends entirely on the shape of your data.
This test reminded us that optimizer design is not a matter of speed — it’s a matter of philosophy.
JSON Workloads — Read vs Write Behavior Split
A clean, predictable difference:
- MySQL stores JSON in a compact binary format → faster reads
- MariaDB stores JSON textually → faster updates
So JSON performance isn’t about which engine is “better,” but about which type of JSON workload your application depends on.
Threading Model — A Real Operational Difference
Here’s a fact many overlook:
MySQL Community Edition
- Uses one-thread-per-connection
- Great for small-to-medium deployments
- Can become expensive under thousands of connections
MariaDB Community Edition
- Includes thread pool, which:
- Reduces context switching overhead
- Increases CPU efficiency
- Keeps throughput stable under heavy concurrency
This matters a lot in environments with:
- API gateways
- Analytics tools
- BI tools
- Large pools of idle connections
You’ll feel this difference not just in benchmarks — but in day-to-day operational stability.
Resource Efficiency
This was one of the most practical findings:
MariaDB produced more throughput per CPU than MySQL under similar conditions.
This does not mean “MariaDB is faster.”
It means:
- MariaDB’s durability model is more relaxed
- MySQL’s durability model is more strict
- Therefore MariaDB needs fewer CPU cycles per commit
If your workload allows relaxed commit behavior, MariaDB gives you more performance per dollar.
If your workload needs strict durability, MySQL gives you more predictability per transaction.
High Availability — Two Engines, Two Philosophies
Both MySQL and MariaDB support synchronous replication, but they approach it differently.
MySQL Group Replication (GR)
- One primary writable node
- Other nodes run in semi-synchronous fashion
- Uses global GTIDs with strict ordering
- Strong emphasis on data consistency
- Transparent fail-over with predictable recovery
It’s extremely safe, but requires structured planning for topology changes.
MariaDB Galera Cluster
- True multi-master: you can write to any node
- Uses domain-based GTIDs
- Certification-based conflict detection
- Easier cluster expansion
- Works elegantly with MaxScale for routing
Galera prioritizes operational flexibility and scale-out friendliness.
So the summary is:
- MySQL GR → strict, ordered, consistent
- Galera → flexible, multi-master, scale-friendly
Neither is “more correct” — they simply target different operational environments.
Conclusion — What These Benchmarks Really Tell Us
After several days of controlled testing and validation, here is the takeaway that mattered the most:
You should not choose a database engine based on benchmark numbers alone.
You should choose it based on the architectural philosophy that matches your workload.
Choose MySQL if you value:
- Strong, predictable durability
- Stable latency under transaction pressure
- Strict GTID ordering for replication
- Traditional consistency guarantees
Choose MariaDB if you value:
- Higher throughput in write-heavy workloads
- Elastic scalability with thread pooling
- Faster ETL and ingestion
- Multi-master clustering via Galera
Both are excellent engines.
Both continue to evolve in different directions.
And both deserve to be understood for what they are — not what they used to be years ago.
Trackbacks/Pingbacks