Benchmark: MariaDB vs MySQL on Commodity Cloud Hardware
What we tested: Relative performance of MariaDB vs MySQL
How we tested: Multi-statement, transaction processing workload (Sysbench 90:10)
Where we tested: Amazon AWS EC2 and RDS,
What we conclude: MariaDB provides superior performance on commodity cloud hardware for real business workloads.
Looking back in MariaDB Server’s family tree, we find its ancestor, MySQL Server. MariaDB Community Server and MySQL Server Community Edition, both Open Source, have over the years been packaged for many of the same Linux distributions, powering application stacks behind hundreds of popular websites and applications. And both are available in the cloud.
- SQL support
- InnoDB storage engine for ACID-compliant transactions
- Common Table Expressions and Window Functions
- Data-at-Rest and Data-in-Transit Encryption
- Availability from leading cloud providers worldwide
- Core features and behavior familiar to at least a third of developers worldwide (per Stack Overflow Developer Survey 2020)
MariaDB Server additionally supports:
- Compatibility with a subset of Oracle PL/SQL, via
SQL_MODE=ORACLE, since 2018
- Sequences, since 2018
EXCEPT, since 2018
- Advanced InnoDB online DDL with instant
ALTER, since 2019
- Temporal Tables (System-Versioned, Application-Time Period, Bitemporal), since 2019
- Pluggable Data Types, since 2020
- Columnar storage for analytics, since 2020
MariaDB Platform X5 further extends these capabilities with:
- Enhanced code stability
- Distributed analytical processing with columnar storage, backed by low-cost object storage
- Distributed SQL with high availability, fault tolerance and write-scaling
- Federated servers and database interconnect via ODBC
- Automatic failover, transaction replay, and session restore
- Hot online backups
- Robust SQL firewalling and proxy capabilities
- Availability on MariaDB SkySQL, cloud database service from MariaDB
A Real-World Workload
Database workloads come in all shapes and sizes, and in evaluating your options it is important to start at an understandable point. In choosing a workload for benchmarking, we wanted to select something easily understood and commonly seen in business, then assess performance on a level playing field on commonly available cloud configurations — a common workload running on exactly the sort of cost-effective cloud hardware (not exotic hardware) that customers choose because it makes good business sense.
For our workload, we chose a 90% read, 10% write workload, and we drove this workload using Sysbench, one of the most popular benchmarking tools in the MySQL community.
How to Run a Sysbench 90:10
Sysbench 90:10 is an adaptation of the sysbench open source benchmark driver. This configuration of sysbench attempts to stress the underlying transaction processing capability of a database system using a mix of simple, multi-statement transaction, consisting of 9 point select statements (reads) and 1 point update statement (writes).
The following command lines document the sysbench settings used in the prepare and run commands of the test.
sysbench oltp_read_write --mysql-host=xx.xx.xx.xx --mysql-user=xxxxx --mysql-password=xxxxxxxxx --mysql-db=sysbench --table-size=1000000 --tables=10 --threads=10 --auto-inc=off --secondary=off --create_secondary=off prepare
sysbench oltp_read_write --point-selects=9 --range-selects=false --index-updates=0 --non-index-updates=1 --delete-inserts=0 --time=300 --tables=10 --table-size=1000000 --rand-type=uniform --report-interval=10 --mysql-db=sysbench --mysql-host=xx.xx.xx.xx --mysql-user=xxxxx --mysql-password=xxxxxxxxx --threads=xx --rand-seed=xxxxx run
--threadsis the variable used to increase load on the system. Each test curve starts at 8 concurrent threads and grows by factors of two between test points (8, 16, 32, 64, 128, etc). Individual test points execute for 5 minutes (300 seconds). The test will continue growing threads until average latency of a test point exceeds a defined threshold of 50ms.
--rand-seedis a numeric value used to ensure that the random number sequence of multiple drivers differs and the drivers do not run in lock step.
- Our tests were driven from dedicated driver nodes, EC2
c5.xlargeinstances running CentOS Linux 7 (
ami-0bc06212a56393ee1) from the same zone as the database server.
- Driver node count scaled-up with database node size, from 1 driver for a
largedatabase instance, to 4 drivers for a
- We initially tested
m5dinstances, and then tested RDS
- Our tests were driven with Sysbench 1.0.20, available from: https://github.com/akopytov/sysbench
In our initial tests, we compared the relative performance of MariaDB Community Server 10.5.5 vs MySQL Server 8.0.21 Community Edition using Sysbench 90:10.
The tests leverage concurrency as a variable to apply increasing load on a database. Our objective is to determine the overall capacity of a system. We do that by examining the tradeoff between throughput and latency as load (concurrency) increases. Plotting throughput versus latency as a curve we are able to see when a database configuration reaches a “capacity point” (knee of the curve). At this point, increases in load stop translating into increases in throughput and instead translate into increases in latency.
Our results with MariaDB:
Our results with MySQL:
In general, MariaDB significantly outperforms MySQL at lower scale points and continues to maintain a performance differential at higher scale. This is indicated in the charts by lower latency for MariaDB than MySQL and higher throughput from MariaDB than MySQL.
Lower latency results mean a more responsive database and ultimately a more responsive application experience for your users. Higher throughput represents an ability to perform more work per second. The fact that MariaDB exhibits both lower latency and higher throughput than MySQL on commodity cloud hardware for a real business workload (90% reads, 10% writes) means MariaDB can deliver a better user experience at lower cost.
Testing in a cloud environment comes with a certain level of variability in the performance results. It is inherent in the nature of cloud computing. In an attempt to account for this variance, the results above are the averaged results from three independent tests. The following graphics show the actual results of the individual tests, illustrating the run-to-run variance between tests and how that variance grows with scale.
After testing with databases running in EC2, we wondered if these performance characteristics would also be present in RDS. Though the latest 10.5 release series (GA in June 2020) of MariaDB Community Server is not yet available on RDS, we were able to test with MariaDB 10.4 (GA in June 2019 and added to RDS in April 2020) and compare against MySQL 8.0.20.
To many, MariaDB Server is a successor to MySQL Server, having superseded its position in the application stack years ago. But for those holding on to old MySQL, we believe these results present a compelling argument that for users interested in operating real-world workloads on widely available, cost-effective commodity cloud hardware, MariaDB is the best cloud database.
You can even see this in our testing of Amazon RDS. For easy apples to apples comparison we thought we’d compare MySQL and MariaDB on the same cloud platform, systems, configured by an independent 3rd party, no further tuning and tweaking – MySQL and MariaDB on AWS RDS.
MariaDB Server is available on leading cloud providers worldwide, and for the best of the best you can find MariaDB Platform including MariaDB Enterprise Server on MariaDB SkySQL.