MySQL Ecosystem Performance Benchmark Report 2026

Comparative Analysis of InnoDB-Compatible Engines — Percona Lab Results

Repository: github.com/Percona-Lab-results/2026-interactive-metrics

Executive Summary

This report presents results from a comprehensive sysbench OLTP benchmark comparing 10 InnoDB-compatible database engine versions across three generations of MariaDB, MySQL, and Percona Server. Tests span three buffer pool tiers (2 GB, 12 GB, 32 GB), eight concurrency levels (1 to 512 threads), and three test scenarios — read-write local, read-only local, and read-write over a 10Gb/s network — yielding 700+ data points.

1. Benchmark Overview

1.1 Purpose and Scope

This benchmark was designed to provide vendor-neutral, reproducible performance data for MySQL-compatible open-source database engines. The goal is to quantify how each engine scales under OLTP read-write and read-only workloads at varying levels of concurrency and memory pressure — three dimensions that are critical for production capacity planning.

The study addresses the following primary questions:

• How does raw throughput (TPS) scale with thread count for each engine?
• What is the impact of InnoDB buffer pool size on throughput?
• How do different versions within the same family compare?
• Where is the concurrency saturation point reached?
• How do local runs differ from high-speed (10Gb/s) network data transfer?

1.2 Engines Under Test

Ten distinct engine versions were benchmarked, spanning three product families:

2. Key Findings Summary

This summary is provided to give the reader an immediate overview of the most critical performance deltas and trends observed across all benchmark runs. It highlights which engine versions excel under specific conditions (high concurrency, read-only workload, I/O pressure) and quantifies the most significant generational improvements or regressions found in the data.

3. Test Environment & Infrastructure

3.1 Hardware & Host Configuration

All benchmarks were executed on a single bare-metal host to eliminate network and virtualization overhead. The database server and benchmark client ran on the same machine (loopback connection) for local tests, and on separate machines connected via 10Gb/s Ethernet for network tests.

Hardware configuration of the host:

Software Configuration:

3.2 Containerization Strategy

Each engine was run as a Docker container using official images (percona/percona-server, mariadb, mysql). The host network mode was used to avoid bridge networking overhead. A fresh container was started for each engine/tier combination using the following sequence:

1. Stop and remove any existing benchmark container
2. Detect actual server version by connecting and running SELECT VERSION()
3. Generate a version-specific configuration file (see Section 3)
4. Restart the container with the new configuration mounted
5. Wait for the server to become ready (mysqladmin / mariadb-admin ping loop)
6. Verify InnoDB buffer pool size matches the intended tier (hard abort on mismatch)

3.3 Buffer Pool Tiers

With the database size of 24G, three InnoDB buffer pool sizes were tested, each representing a distinct workload characteristic:

4. Database Configuration

The schema contains 20 tables with 5M rows in each one adding up to 100M rows.

The size of the database files on the disk is 24G.

The schema dump can be downloaded from the interactive graphs page or directly at percona-lab-results.github.io/2026-interactive-metrics/schema_dump.sql.

4.1 Shared Base Configuration

A common configuration was applied to all engines to ensure fairness. Version-specific directives were layered on top (see 3.2).

4.2 Version-Specific Configuration

Configurations were branched based on detected major version:

MySQL / Percona 5.7 / 8.0: innodb_log_file_size=2G, innodb_log_files_in_group=2

MySQL 8.4 / 9.x: innodb_redo_log_capacity=4G, innodb_change_buffering=none (new redo log architecture)

MariaDB < 12.1: innodb_log_file_size=2G, innodb_log_files_in_group=2, query_cache_type=0, query_cache_size=0, thread_handling=one-thread-per-connection

MariaDB 12.1+: Same as above minus query_cache directives (removed in 12.1)

5. Benchmark Workload

5.1 Warmup Protocol

NOTE: The proposed warmup values are determined experimentally and are sufficient for the hardware configuration used for the benchmarking. However, in case of much slower hosts the user will need to adjust them by editing scripts.

5.2 Measurement Run

Each measurement run lasted 900 seconds (15 minutes) with results reported at 1-second intervals. System telemetry (iostat, vmstat, mpstat, dstat) was collected concurrently.

The published data reflects a single run for each measurement. However, to check for the steady state, we performed selective 2nd and 3rd validation runs across various platforms and servers to confirm the consistency of the initial results.

We chose not to publish the validation runs to keep the results readable. With 980 base measurements generating 6 files each, adding the validation runs would have made the dataset difficult to navigate.

Reaching a steady state with reads was done by checking InnoDB and OS I/O read metrics to ensure they reach zero after a sufficient preheating stage.

The method with writes was to monitor the output metrics until they stabilized. However, a limitation must be acknowledged. A stable output over a shorter timeframe doesn’t entirely rule out delayed background jobs (like page flushing or insert buffer merges) that might surface if the database operated for days.

6. Metrics & Reporting

6.1 Primary Metrics

6.2 Derived Metrics

QPS/TPS gain relative to additional RAM; QPS/TPS gain relative to thread count increase.

6.3 Output Files

Each run produced: .sysbench.txt, .iostat.txt, .vmstat.txt, .mpstat.txt, .dstat.txt. Each server config produced: .cnf.txt, .vars.txt, .status.txt, pt-mysql-summary.txt.

7. Results:

7.1 Read-Write Local

The read-write local benchmark tests mixed OLTP transactions over loopback connection.  → Open interactive graph

Table 7.1.1

At 32 GB, MySQL 8.4 and Percona 8.4 demonstrate good high-concurrency scaling through 512 threads (13,325 and 13,385 TPS).  MariaDB engines peak at 128 threads then show a notable decrease in performance, though MariaDB exhibits much better single-thread performance, especially visible in version 10.11. MySQL 5.7 peaks early at 64 threads.

Table 7.1.2

At 12 GB, Percona 5.7 leads with 1,385 TPS at 512 threads. MariaDB engines peak around 128 threads. MySQL 8.0 uniquely continues improving to 1,144 TPS at 512 threads.

Table 7.1.3

Under severe memory pressure (2 GB), Percona 5.7 dominates at 813 TPS (512 threads). The 8.4-generation engines plateau around 530 TPS. Percona 8.0 shows the worst overall performance at this tier.

7.2. Results: Read-Only Local

The read-only benchmark eliminates write contention, revealing pure read-path scalability.  → Open interactive graph

Table 7.2.1

MariaDB 10.11 dominates with 32,392 TPS at 128 threads — 38% ahead of the next engine. MySQL 5.7 peaks at 13,684 TPS (32 threads) then collapses to 3,889 at 512 threads.

Table 7.2.2

All engines converge into a tighter band. MySQL 8.4 and 9.6 lead at ~3,670 TPS. MySQL 5.7 shows a flat curve above 32 threads (~2,600 TPS).

Table 7.2.3

Read-only workloads saturate early. MariaDB 12.1 leads slightly at 1,753 TPS. MySQL 9.6 and Percona 8.4 degrade sharply above 128 threads.

7.3. Results: Read-Write Network

The network benchmark measures read-write OLTP over 10Gb/s Ethernet.  → Open interactive graph

Table 7.3.1

MySQL 8.4/9.6 and Percona 8.4 reach 12,781, 12,715, and 13,076 TPS at 512 threads. MariaDB 10.11 peaks at 10,050 (128 threads) but degrades to 4,088 at 512.

Table 7.3.2

Percona 5.7 leads at 1,417 TPS (512 threads). MariaDB engines peak at 128 threads (~1,240 TPS). Percona 8.0 reaches only 797 TPS.

Table 7.3.3

Percona 5.7 leads at 842 TPS (512 threads). MariaDB engines peak at 128 threads (~655 TPS). Network overhead adds 2–5% to I/O-bound limitations.

8. Version Progression

8.1. Read-Write Local

8.2. Read-Only Local

8.3. Read-Write Network

9. Methodology Notes & Caveats

9.1 Limitations

• All tests run on a single server host — results reflect single-node performance only. Replication, cluster, or proxy overhead are not measured.
• The sysbench oltp_read_write and oltp_read_only workloads are synthetic OLTP approximationbs. Real application query distributions differ; results should be treated as directional, not absolute.
• The random numbers for the tests are uniformly distributed, which is not the case in most real life applications.
• Network tests were conducted over a dedicated 10Gb/s Ethernet link between two bare-metal hosts. Results may differ on shared networks, or cloud environments.
• Data size is small compared to real databases.

9.2 Reproducibility

All benchmark scripts are published at github.com/Percona-Lab-results/2026-interactive-metrics/tree/test-data.

OS support is currently limited to Ubuntu 24.04.

The repository contains four entry-point scripts. To reproduce:

1. Install prerequisites:

Grant Permissions: Add your current user to the docker group by running:

Log out and back in, or run newgrp docker to update your group permissions without restarting.

Note: The user requires root access (sudo) as the scripts internally execute sudo commands for environment management and telemetry collection.

2. For local read-write benchmarks:

Calls run_metrics.sh for each engine. Results stored in benchmark_logs/{db}/{version}/.

3. For local read-only benchmarks:

Enables read-only mode. Results stored in benchmark_logs_read_only/{db}/{version}/.

4. For network read-write benchmarks:

Install prerequisites on the remote host and add the user to the docker group as described in step 1.

Manages Docker on remote host via SSH, deploys config via SCP, collects telemetry remotely. Results in benchmark_remote_logs/{db}/{version}/.

5. For network read-only benchmarks:

Combines remote execution with read-only mode. Results in benchmark_remote_logs_read_only/{db}/{version}/.

Each run_metrics.sh / run_remote_metrics.sh invocation handles the full lifecycle for one engine: container startup, version detection via SELECT VERSION(), configuration generation with version-specific branching, buffer pool verification, data preparation (20 tables × 5M rows), two-phase warmup, and 15-minute measurement runs at all eight concurrency levels across all three buffer pool tiers. System telemetry (iostat, vmstat, mpstat, dstat) is collected at 1-second granularity alongside each measurement. Server variables (SHOW VARIABLES), status counters (SHOW STATUS), and pt-mysql-summary output are captured per tier.

Default Schema sbtest is created upon docker container run. Tables are populated with the following sysbench command:

9.3 Configuration Philosophy

The benchmark uses a single tuned config rather than default settings, for a deliberate reason: default configurations are not representative of production deployments and systematically understate the performance potential of modern InnoDB. The config applied here is conservative but reasonable — it does not apply per-engine exotic tuning, ensuring all engines compete on roughly equal footing at a production-realistic baseline.

Side Note:

MariaDB provided this response with some valid recommendations about configuration in newer MariaDB versions:

A response to Percona’s 2026 MySQL ecosystem benchmark: useful data, but not a realistic MariaDB comparison

However, there are issues in the implementation ofinnodb_snapshot_isolation which MariaDB uses by default:

MDEV-39263 – innodb_snapshot_isolation fails to prevent lost updates under contention
MDEV-39264 – innodb_snapshot_isolation allows non-repeatable reads after UPDATE on unrelated column

We will review specific benchmarks and provide the results.

Report generated from raw benchmark data in branch raw-data of the repository. Charts generated with matplotlib. Document assembled programmatically.
Percona Lab Results · 2026 · github.com/Percona-Lab-results/2026-interactive-metrics