Percona Server 8.4.11 improves TPS in MySQL I/O-bound scenarios

On August 27, 2026, Percona published a performance investigation on its Database Blog, written by Bogdan Degtyariov, comparing three versions of Percona Server for MySQL 8.4 released throughout 2026: 8.4.8-8 (March 12), 8.4.10-10 (June 30), and 8.4.11-11 (August 20). The goal is direct and useful for anyone running a database in production: to measure whether it's worth upgrading, where the gains show up, and why. New features and security patches were deliberately left out of the analysis, as were latency (percentiles) and resource usage (CPU, RAM, I/O). The focus is a single metric: throughput (TPS) in OLTP read-write.

Methodology matters more than the final number

Before looking at any result, it's worth understanding the test design, since it's what gives the comparison meaning. The workload was generated with Sysbench OLTP Read-Write, on a robust server: Intel Xeon Gold 6230 (2×20 cores, 80 logical CPUs with Hyper-Threading), 187 GiB of DDR4 RAM, a 2.9 TB Intel NVMe SSD, Ubuntu 24.04.

The core of the method is cross-referencing three variables in a controlled way:

• Database size: 24 GB (100M rows), 48 GB (200M), and 96 GB (400M), always with 20 tables.
• Concurrency: from 1 to 512 threads (1/4/16/32/64/128/256/512).
• Buffer-to-data ratio: 1:12 (I/O bound), 1:2 (partially in memory), and 1:1 (fully in memory).

The buffer-to-data ratio is the most interesting axis. It isolates the behavior of innodb_buffer_pool_size against the data volume. In the 1:12 scenario, for example, they tested a buffer_pool of 2G for 24GB of data, 4G for 48GB, and 8G for 96GB. This makes it possible to see how the server behaves with increasingly larger databases while keeping the same cache ratio.

One engineering detail deserves attention, because it separates a serious benchmark from a loose number: Percona locked the CPU turbo frequency at 2400 MHz from the start. The Xeon 6230 has a base clock of 2100 MHz and a turbo of 3900 MHz, but turbo only holds briefly on a single isolated core. Under maximum load across all cores, some servers held 2530 MHz for more than 20 hours, others only 2420 MHz. Fixing the ceiling eliminated the tug-of-war between turbo trying to climb and thermal protection dropping the clock, reducing variation between runs. It's the kind of care that ensures the measured difference comes from the software, not the silicon.

The InnoDB configuration used is that of a seriously run OLTP server: innodb_flush_log_at_trx_commit = 1 (full ACID), innodb_doublewrite = ON, innodb_flush_method = O_DIRECT, innodb_redo_log_capacity = 4G, a thread pool with thread_pool_size = 80 matching the physical core count, and binlog disabled (disable_log_bin = ON) to isolate the database's workload. Each combination ran three times, with a 15-minute measurement window.

Where 8.4.11 takes off: high concurrency with I/O

The result that stands out is in the most stressed scenario: 1:12 (I/O bound), an 8G buffer against 96GB of data. When the number of threads exceeds the 80 physical cores (128 and above), versions 8.4.8-8 and 8.4.10-10 suffer abrupt performance degradation past the saturation point, which occurs around 64 threads. 8.4.11-11, by contrast, keeps increasing TPS.

According to the text, this is due to an optimization in InnoDB's LRU page flushing algorithm, targeting exactly the case where the data is larger than the available buffers and there are many concurrent connections doing random reads and writes. Percona promises to detail the mechanism in a separate post.

There's also a more discreet but relevant gain between 8.4.8-8 and 8.4.10-10, especially at the saturation point with 64 threads. Percona attributes this to the introduction of Performance Guided Optimization (PGO), a compilation technique in which the binary is optimized from real execution profile data. 8.4.10-10 was faster than 8.4.8-8 across all tests and configurations, which makes PGO a consistent gain, even if less spectacular than 8.4.11's flushing improvement.

The buffer pool isn't just a ratio, it's an absolute size

The analysis of the 1:2 scenario offers a capacity-planning lesson that often goes unnoticed. With a buffer_pool of 12G and 24GB of data, 8.4.11-11's advantage over the previous versions remains huge. But moving up to 24G/48GB the gap shrinks, and at 48G/96GB it shrinks even further, even while keeping the 1:2 ratio across all three.

The author's conclusion is explicit: performance doesn't depend only on the ratio between buffer and data, but also on the absolute size of the buffer. For anyone sizing infrastructure, this dismantles the lazy heuristic of reasoning only by cache percentage. Two servers with the same buffer-to-data ratio can deliver quite different throughput depending on the absolute values.

Where 8.4.11 is NOT the best choice

Here's the trade-off the article is honest enough to expose. In the fully in-memory scenario (1:1), 8.4.10-10 is slightly ahead of 8.4.11-11, though the gap is small. And, more importantly: in this case upstream MySQL is faster than any version of Percona Server.

The correct reading is as follows. The 8.4.11-11 patch was designed specifically to fix the fact that Percona Server was slower than MySQL in I/O-bound scenarios, and to eliminate that sharp drop above 64 threads. It's not part of upstream MySQL 8.4.11. In the workloads where Percona Server used to lose (low thread counts, I/O bound), 8.4.11-11 now shines. But when the entire dataset fits in RAM, the flushing optimization loses relevance, because there's almost no flushing under pressure, and upstream retakes the lead.

In other words: the upgrade decision isn't universal. For those with a large database that doesn't fit in the buffer pool and high concurrency, the case for 8.4.11-11 is strong. For those running a small, fully buffered dataset, the gain disappears, and the choice between Percona Server and upstream MySQL comes down to other factors (the features and patches that this benchmark, by design, left out).

What Brazilian DBAs take away from this

The benchmark reinforces an old principle: performance is born from design, and design starts by understanding the relationship between the working set and available memory. Before switching versions chasing TPS, the professional needs to know which of the three regimes their database operates in today. A SHOW ENGINE INNODB STATUS and monitoring the buffer pool hit rate reveal whether the workload is I/O bound or not, and that answer determines whether the 8.4.11 gain will materialize in production or stay confined to the chart.

It's worth noting what the author himself delimits: percentile latency and resource consumption were left out. In OLTP production, average TPS doesn't tell the whole story, a bad p99 can break the SLA even with high throughput. Anyone evaluating an upgrade would do well to reproduce the test with their own workload and also measure the latency tail. Percona provides the schema (schema_dump.sql) and the configuration files for each run in the post's interactive charts, which allows replicating the methodology instead of blindly trusting someone else's result, exactly the kind of rigor that separates an infrastructure decision from a bet.