Open-Source Database Server Adds Thread Pooling in 26.7.0 and 9.7
The database thread pool has arrived in the free community edition of the open-source relational database server's July release, versions 26.7.0 and 9.7.2. Percona software engineer Bogdan Degtyariov writes in an October 5, 2026 post that before this release, the official server thread pool plugin existed only for paying customers of that same database server's enterprise edition. The main free alternatives with thread pooling were Percona's database server, which shipped it as a plugin, a community fork of the same engine with thread pooling built into the server, and a third-party GitHub plugin. This first part of Degtyariov's analysis covers what thread pooling is and how Percona's database server implements it; a performance comparison between Percona's database server and the open-source database server appears in Part 2.
Thread pooling is a technique that reuses a fixed number of pre-created threads to handle multiple client connections and execute statements inside a database. In a default configuration of the open-source relational database server, called one-thread-per-connection, the server creates a dedicated thread whenever a client connects, runs that client's queries, and then destroys the thread. When connection counts grow very large, this default method causes performance to drop significantly because creating, destroying, and constantly switching between thousands of threads, a process called context switching, wastes system resources and creates contention, meaning many processes compete for the same CPU and memory. Percona's Vadim Tkachenko has used a traffic-control analogy to explain thread pooling in a separate post, and Percona's documentation covers it further. Degtyariov adds a clear warning: a thread pool is not a universal database booster. It is an advanced tool that must be used with full understanding of the workload; otherwise results can be far from perfect.
Thread pooling organizes work into thread groups. Each group is assigned to a specific CPU core, so the number of groups often matches the number of physical or logical cores. Incoming client connections are distributed evenly across these groups with a round-robin method, meaning each new connection is sent to the next group in turn. Inside each group, a listener thread monitors incoming queries and places them into either a high-priority queue, such as queries within an active transaction, or a normal low-priority queue. Worker threads then pick up queries from the queues, always handling high-priority items first, execute them, and wait for the next request instead of shutting down. This reuse eliminates the overhead of creating and destroying a thread for every connection.
The benchmark described by Degtyariov sweeps several thread pool settings. The baseline uses thread_handling=one-thread-per-connection, while pooled runs use thread_handling=pool-of-threads. The parameter thread_pool_size is tested at 10, 20, 40, 80, 120, and 160; the author notes that a value of 5 was also tested but performance was unsatisfactory and it is not included. A second parameter pair, thread_pool_max_threads / thread_pool_max_active_query_threads, is fixed at 12000 as the maximum number of threads in the pool. A third pair, thread_pool_oversubscribe / thread_pool_query_threads_per_group, sweeps values 2, 3, and 4, which set how many threads can be active at the same time within a single group.
The test workload is Sysbench OLTP Read-Write, a common command-line tool that generates online transaction processing load. The server runs on an Intel Xeon Gold 6230 with two 20-core processors, hyper-threading giving 80 logical CPUs, 187 GiB of DDR4 memory, and a 2.9 TB Intel NVMe SSD (model SSDPE2KE032T8). The operating system is Ubuntu 24.04 with kernel 6.8.0-60-generic. The database engines compared are Percona's database server 9.7.1-1 and the open-source database server 26.7.0, both release builds. The test database contains 24 GB of data, or 100 million rows, spread across 20 tables in all runs. The schema is available as a downloadable SQL file at https://percona-lab-results.github.io/2026-interactive-metrics/schema_dump.sql.
Concurrency is another dimension: the benchmark drives 40, 80, 120, 160, 320, 640, 1280, 2560, and 5120 concurrent threads. Three buffer-to-data ratios are used: 1:12 for an I/O-bound workload, 1:2 for a partially buffered workload, and 1:1 for a fully buffered workload, which correspond to InnoDB buffer pool sizes of 2 GB, 12 GB, and 32 GB. Before each measurement, a ramp-up phase of 600 seconds, or 10 minutes, is used, and the post says ramp-up times were determined experimentally until increasing them further produced no significant changes. The actual measurement window is 900 seconds, or 15 minutes, based on previous benchmark experience to keep total testing time reasonable. Each configuration is run once because the full suite already takes a long time.
Several other database settings are listed as important. The InnoDB buffer pool, the memory area where the open-source relational database server caches data and index pages, is set to 2 GB, 12 GB, or 32 GB depending on the ratio. Buffer pool load at startup and dump at shutdown are both set to OFF. Thread stack is 512K, thread cache size is 256, and the connection backlog is 4096. InnoDB I/O capacity is set to 10000, with a maximum of 20000, and read I/O threads are set to 16. The post notes that full configuration files for each run can be downloaded from its interactive graphs.
Part 1 deliberately contains no performance results. It establishes the mechanics and the test bed so readers understand exactly what will be measured. The performance comparison between Percona's database server with its thread pool and the newly capable open-source database server is the subject of Part 2. For teams that run databases in production, managed cloud and data infrastructure such as AEU Data offers managed databases, automated backups, encrypted storage, monitoring and high-availability building blocks, so a thread pool experiment does not have to put backups or uptime at risk.