By Percona Lab Results  ·  2026  ·  MySQL MariaDB Percona Benchmark Database

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. Test Environment & Infrastructure

2.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. The host was provisioned fresh before each engine run.

2.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)

2.3 Buffer Pool Tiers

Three InnoDB buffer pool sizes were tested, each representing a distinct workload characteristic:

3. Database Configuration

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.

3.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).

3.2 Version-Specific Configuration

Configurations were branched based on detected major version:

MySQL / Percona 5.7: innodb_log_file_size=2G, innodb_log_files_in_group=2, query_cache_type=0, query_cache_size=0, innodb_checksum_algorithm=crc32

MySQL / Percona 8.0: innodb_log_file_size=2G, innodb_log_files_in_group=2, innodb_change_buffering=none (query cache removed in 8.0)

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)

4. Benchmark Workload

4.1 Warmup Protocol

4.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.

5. Metrics & Reporting

5.1 Primary Metrics

5.2 Derived Metrics

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

5.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.

6. Results: Read-Write Local

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

Table 6.1.1 — TPS by Thread Count, 32 GB Buffer Pool (Read-Write, Local)

At 32 GB, MySQL 8.4 and Percona 8.4 demonstrate exceptional high-concurrency scaling through 512 threads (13,325 and 13,385 TPS). MariaDB engines peak at 128 threads then degrade sharply. MySQL 5.7 peaks early at 64 threads.

Table 6.1.2 — TPS by Thread Count, 12 GB Buffer Pool (Read-Write, Local)

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 6.1.3 — TPS by Thread Count, 2 GB Buffer Pool (Read-Write, Local)

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.

Table 6.1.4 — MariaDB Version Progression (32 GB, RW, Local) — baseline: MariaDB 10.11

MariaDB (baseline 10.11): Both 11.4 and 12.1 show broad regressions across nearly all concurrency levels. Single-thread performance drops ~20% and the degradation persists through 64t (~5%), 256t (~10%), and 512t (~13–15%). Only the 128-thread peak remains within the 5% threshold.

Table 6.1.5 — MySQL Version Progression (32 GB, RW, Local) — baseline: MySQL 5.7

MySQL (baseline 5.7): Regressions are confined to low concurrency. MySQL 8.0 dips at 4t (−9%) and 16t (−8%). MySQL 8.4 and 9.6 show steeper early regressions at 4t (−16–18%) and 16t (−18–19%), recovering strongly above 64 threads where the 8.4 generation continues scaling past all other versions.

Table 6.1.6 — Percona Version Progression (32 GB, RW, Local) — baseline: Percona 5.7

Percona (baseline 5.7): Percona 8.0 regresses at 4t (−11%), 256t (−10%), and 512t (−15%). Percona 8.4 regresses at 4t (−14%), 16t (−13%), and 32t (−7%), then surpasses 5.7 sharply above 64 threads, ultimately delivering the highest peak TPS in the dataset.

7. Results: Read-Only Local

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

Table 6.2.1 — TPS by Thread Count, 32 GB Buffer Pool (Read-Only, Local)

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 6.2.2 — TPS by Thread Count, 12 GB Buffer Pool (Read-Only, Local)

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 6.2.3 — TPS by Thread Count, 2 GB Buffer Pool (Read-Only, Local)

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.

Table 6.2.4 — MariaDB Version Progression (32 GB, RO, Local) — baseline: MariaDB 10.11

MariaDB (baseline 10.11): The most severe regressions in the dataset. Every thread count for both 11.4 and 12.1 degrades by 20–28%, with no concurrency level staying within the 5% threshold. The read-only path is clearly significantly worse in 11.4+, suggesting substantial changes to the read-path internals.

Table 6.2.5 — MySQL Version Progression (32 GB, RO, Local) — baseline: MySQL 5.7

MySQL (baseline 5.7): No regressions ≥5% in read-only mode. All 8.x versions improve over 5.7 at every thread count, with 8.0, 8.4, and 9.6 pulling ahead strongly above 32 threads.

Table 6.2.6 — Percona Version Progression (32 GB, RO, Local) — baseline: Percona 5.7

Percona (baseline 5.7): Percona 8.0 just crosses the threshold at 256t (−5.3%). Percona 8.4 shows no regressions ≥5% in read-only mode and tracks closely with MySQL 8.4 throughout.

8. Results: Read-Write Network

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

Table 6.3.1 — TPS by Thread Count, 32 GB Buffer Pool (Read-Write, Network)

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 6.3.2 — TPS by Thread Count, 12 GB Buffer Pool (Read-Write, Network)

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 6.3.3 — TPS by Thread Count, 2 GB Buffer Pool (Read-Write, Network)

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.

Table 6.3.4 — MariaDB Version Progression (32 GB, RW, Network) — baseline: MariaDB 10.11

MariaDB (baseline 10.11): The regression pattern from local tests holds and intensifies over network. Every thread count for both 11.4 and 12.1 degrades ≥5%, with 11.4 reaching −23% at 256t and 12.1 at −20%. The 512-thread drop is the most acute, with both newer versions losing 12–15% versus 10.11.

Table 6.3.5 — MySQL Version Progression (32 GB, RW, Network) — baseline: MySQL 5.7

MySQL (baseline 5.7): MySQL 8.0 regresses at 4t (−7%). MySQL 8.4 and 9.6 regress at 4t (~−11%), 16t (~−13%), and 32t (~−11–12%), consistent with the local pattern. The regressions are transient and offset by large gains at 128–512 threads.

Table 6.3.6 — Percona Version Progression (32 GB, RW, Network) — baseline: Percona 5.7

Percona (baseline 5.7): Percona 8.0 regresses at 4t (−7%) and 512t (−15%). Percona 8.4 regresses at 4t (−13%), 16t (−12%), and 32t (−6%), closely mirroring the MySQL 8.4 profile. Network overhead does not change the generational ranking order.

9. Key Findings Summary

Version Progression — All Differences Greater Than 5% vs Baseline (32 GB)

RW Local

RO Local

RW Network

10. Methodology Notes & Caveats

8.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 proxies. Real application query distributions differ; results should be treated as directional, not absolute.
• 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.

8.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.

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:

8.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.

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

Subscribe

Notify of

new follow-up comments new replies to my comments

Label

{} [+]

Name*

Email*

Website

Δ

Label

{} [+]

Name*

Email*

Website

Δ

0 Comments

Oldest

Newest Most Voted

Inline Feedbacks

View all comments