MySQL 26.7 moved the Thread Pool plugin to Community edition. As of the 26.7.0 Innovation release (GA 2026-07-31), the MySQL Thread Pool — the connection-handling model Oracle reserved for MySQL Enterprise Edition for roughly fifteen years — now ships in MySQL Community Server — no subscription, no commercial binary.
For any team running high-connection-count MySQL on Community builds, this is the most consequential edition change since the MySQL 9.7 LTS Community transfers three months earlier.
This MySQL Thread Pool release analysis covers what actually changed, how to turn the plugin on and verify it is working, how to tune and monitor it with the Performance Schema, who should adopt it now versus wait, and where it leaves the Community-versus-Enterprise decision. Every claim is version-pinned; configuration values shown are starting points to be measured against your workload, not universal settings. Standard caveat: test in staging and keep a rollback path before changing thread_handling on a production server.
What MySQL 26.7 Changed, and Why It Matters
MySQL 26.7.0 is the first generally available Innovation release after MySQL 9.7 LTS, and the first MySQL release to use the new YY.M calendar-versioning model (so "26.7" is the July 2026 release, not a 26th major version). Its headline edition change is short to state and large in consequence: the Thread Pool plugin is now included in MySQL Community Edition. It is the same plugin, with the same system variables and the same Performance Schema instrumentation that Enterprise customers have used for years. Oracle confirmed the change in the MySQL July 2026 GA announcement.
This continues a trajectory that began at 9.7. That LTS moved eight capability groups across the Enterprise-to-Community line — the Hypergraph Optimizer, the OpenTelemetry telemetry component, three Group Replication components (flow control, resource manager, primary election), replication applier metrics, and JSON Duality View DML. MySQL 26.7 adds Thread Pool to that list.
The practical significance is that the MySQL Thread Pool was, for fifteen years, the single most-cited Enterprise Edition performance feature. Its move to Community does not invent a capability the open-source world lacked — Percona Server has shipped its own thread pool since 5.5, and MariaDB has long had one — but it makes Oracle's canonical implementation free on stock MySQL. For the renewal conversation, the effect is decisive: the Enterprise value proposition has shifted away from performance and high availability toward security, backup, AI, and support. Thread Pool is no longer a reason to hold an Enterprise subscription.
The Problem the MySQL Thread Pool Solves: Connection Scaling
To understand the MySQL Thread Pool, start with the default. MySQL's connection-handling model is thread-per-connection: every client connection is served by one dedicated operating-system thread for its entire lifetime. This is simple and low-latency at moderate concurrency, and it is the right default for most workloads. It degrades predictably when the number of concurrent connections climbs well past the number of CPU cores.
Three mechanisms drive the degradation, and all three are measurable rather than theoretical. Context-switching overhead rises as thousands of runnable threads compete for a handful of cores, so the OS scheduler spends an increasing share of cycles switching rather than executing.
CPU-cache efficiency falls because each thread carries its own stack, and thousands of stacks evict each other's working set from L2/L3. And transaction parallelism drives contention inside InnoDB — more concurrent transactions means more pressure on shared structures, and past a point additional concurrency reduces throughput instead of increasing it.
The thread pool replaces "one thread per connection" with a bounded set of thread groups. Connections are distributed across thread_pool_size groups (default derived from CPU count), and each group runs a small number of active threads that multiplex many connections. Because the number of actively executing threads is capped near the core count, thread-stack reuse keeps the CPU-cache footprint small and transaction parallelism stays bounded — which is precisely what protects InnoDB from the contention cliff.
The trade is latency fairness: a bounded pool can queue a statement briefly under load, so a latency-critical, moderate-concurrency workload can be worse off on the pool than on the default model.
Enabling the MySQL Thread Pool in 26.7 Community
Because the MySQL Thread Pool is now bundled with Community Edition, enabling it is the same declarative install used on Enterprise, with no commercial package to source first. Confirm the plugin library is present, install the plugin set, and switch the connection-handling model. The plugin is loaded at startup, so the durable configuration lives in my.cnf. The mechanics match the MySQL Thread Pool reference documentation.
-- 1. Confirm you are on a release that ships Thread Pool in Community
SELECT VERSION(); -- expect 26.7.0 or later on a Community build
-- 2. Load the plugin set (INSTALL PLUGIN persists in the mysql.plugin table,
-- but thread_handling must still be set in my.cnf; see step 4)
INSTALL PLUGIN thread_pool SONAME 'thread_pool.so';
-- 3. Verify the plugin and its companion Performance Schema tables are ACTIVE
SELECT PLUGIN_NAME, PLUGIN_STATUS, PLUGIN_TYPE
FROM information_schema.PLUGINS
WHERE PLUGIN_NAME LIKE 'thread_pool%'
OR PLUGIN_NAME LIKE 'tp_%';
The connection-handling model itself is not a runtime-settable variable — it is read at server start. Set it in the configuration file and restart during a maintenance window. State the blast radius before you do: switching thread_handling changes how every connection is scheduled, so validate on a replica first and have the one-line rollback ready.
# my.cnf — Thread Pool configuration (MySQL 26.7 Community)
# Change: thread_handling one-connection-per-thread -> pool-of-threads
# Requires a server restart. Rollback: comment these out and restart.
[mysqld]
thread_handling = pool-of-threads
thread_pool_size = 16 # start at number of physical cores
thread_pool_max_transactions_limit = 512 # ~ cores x 32; caps concurrent txns
thread_pool_stall_limit = 6 # units of 10ms; 6 = 60ms stall check
thread_pool_algorithm = 1 # 1 favors high-concurrency OLTP
thread_pool_query_threads_per_group = 2 # worker threads per group to start
-- 4. After restart, confirm the model actually changed SHOW GLOBAL VARIABLES LIKE 'thread_handling'; -- Expected: thread_handling = pool-of-threads SHOW GLOBAL VARIABLES LIKE 'thread_pool%';
Tuning the MySQL Thread Pool: The Variables That Matter
Four MySQL Thread Pool variables carry most of the tuning weight. Treat the values below as starting points anchored to hardware, then adjust against measured throughput and latency — never against a rule of thumb alone. The starting points below follow the MySQL Thread Pool tuning guidance.
| Variable | What it controls | Starting point |
|---|---|---|
thread_pool_size | Number of thread groups; the primary concurrency dial | Number of physical cores for InnoDB workloads (max 512); keep low (4–8) for MyISAM-heavy ones |
thread_pool_max_transactions_limit | Ceiling on concurrently executing transactions across all groups | Physical cores × 32, then tune down if InnoDB contention persists |
thread_pool_stall_limit | How long a group waits before treating a running statement as stalled and starting another worker (units of 10 ms) | Default 6 (60 ms); lower it if short queries are stuck behind long ones |
thread_pool_algorithm | Scheduling algorithm | 1 for high-concurrency OLTP; 0 is the conservative default |
The thread_pool_stall_limit value is the one most worth understanding. When every thread in a group is busy, the group will not start a new statement until the stall timer expires — this is deliberate, and it is what caps parallelism. Set it too high and a burst of long-running statements can starve short OLTP queries; set it too low and you erode the contention protection you turned the pool on for. This is a workload-shape decision, not a default.
One interaction is worth calling out explicitly, because it trips up first-time tuners. thread_pool_size and thread_pool_max_transactions_limit are not independent knobs. The first sets how many thread groups exist; the second caps how many transactions can execute across all of those groups at once. If you raise thread_pool_size to match a high core count but leave the transaction limit low, you have created groups that are structurally allowed to run work but are throttled from doing so, and throughput plateaus below what the hardware can deliver. Conversely, a generous transaction limit with too few groups concentrates connections and reintroduces the queuing you were trying to avoid.
Tune them as a pair: set thread_pool_size to the physical core count first, then raise or lower thread_pool_max_transactions_limit while watching the stall ratio and InnoDB row-lock waits, and stop at the point where additional concurrency stops improving committed transactions per second. That inflection point is specific to your schema and access pattern, which is exactly why the values in the table above are starting points and not answers.
Monitoring the MySQL Thread Pool with the Performance Schema
The MySQL Thread Pool ships three Performance Schema tables, and they are the measurement source for every tuning decision. Recommendations that are not anchored to these tables are guesses.
-- Live per-group state: how many connections and threads each group holds,
-- and how deep the high/low priority queues are right now
SELECT TP_GROUP_ID,
CONNECTION_COUNT,
THREAD_COUNT,
ACTIVE_THREAD_COUNT,
QUEUED_QUERIES -- backlog is the early-warning signal
FROM performance_schema.tp_thread_group_state
ORDER BY QUEUED_QUERIES DESC;
-- Stall ratio: the single most important thread pool health metric.
-- A rising ratio means statements are being treated as stalled and
-- spawning extra workers — i.e. the pool is fighting your workload.
SELECT SUM(STALLED_QUERIES_EXECUTED) / NULLIF(SUM(QUERIES_EXECUTED), 0)
AS stalled_ratio,
SUM(QUERIES_EXECUTED) AS total_queries,
SUM(STALLED_QUERIES_EXECUTED) AS stalled_queries
FROM performance_schema.tp_thread_group_stats;
/* Illustrative output shape — values will differ on your server +---------------+---------------+-----------------+ | stalled_ratio | total_queries | stalled_queries | +---------------+---------------+-----------------+ | 0.0123 | 48211900 | 593006 | +---------------+---------------+-----------------+ */
These two tables are the backbone of MySQL Thread Pool monitoring. Read these together. A persistently high QUEUED_QUERIES in tp_thread_group_state combined with a climbing stalled ratio in tp_thread_group_stats tells you the pool is too small for the offered load — raise thread_pool_size or investigate the long statements holding groups busy. A low stalled ratio with acceptable latency means the pool is doing its job. Always baseline both before and after any variable change, and correlate with connection counts the way you would when sizing a client-side pool in our MySQL connection pooling guide.
Who Should Adopt the MySQL Thread Pool in 26.7 — and Who Should Wait
The MySQL Thread Pool is a targeted fix, not a universal upgrade. The clearest MySQL Thread Pool candidates are OLTP servers with thousands of mostly-idle or bursty connections — the classic PHP/short-connection or microservice fan-out pattern — where connection count runs far ahead of core count and throughput visibly collapses past a concurrency threshold.
If you can reproduce a throughput curve that peaks and then falls as concurrency rises, the pool is likely to flatten that fall.
Workloads that should not rush to it: latency-sensitive, moderate-concurrency systems where connection count stays near or below core count. For those, thread-per-connection is already optimal, and the pool's queuing can only add latency. Analytics/OLAP servers running a small number of large parallel queries gain nothing from connection multiplexing. And if a well-behaved client-side connection pool (ProxySQL, a framework pool) already holds server connections to a sane number, the server-side thread pool addresses a problem you may not have.
Our stance for 26.7 specifically. The feature is genuinely valuable and now free, but 26.7 is an Innovation release, not LTS — it is supported only until the next Innovation release supersedes it, whereas 9.7 LTS carries Premier support to 2034.
For production, the disciplined path is to prove Thread Pool on 26.7 in staging, confirm the throughput win against your own workload, and deploy it in production on the LTS line you actually run — 9.7 — if and when the plugin is available there, rather than putting a short-lived Innovation build under a production estate for a single feature. Treat 26.7 as the release that proves the capability is free, and your LTS as where it lands.
What This Means for the Community-vs-Enterprise Decision
With the MySQL Thread Pool gone to Community, the honest Enterprise Edition value proposition after 26.7 is security, backup, AI, and support — not performance and not high availability, both of which are now fully open source. With the MySQL Thread Pool no longer a differentiator, before renewing an Enterprise subscription run the usage audit: enumerate which Enterprise features are actually in use.
-- The Enterprise renewal audit: what are you actually paying for? SHOW PLUGINS; SELECT PLUGIN_NAME, PLUGIN_STATUS, PLUGIN_LIBRARY FROM information_schema.PLUGINS WHERE PLUGIN_LIBRARY IS NOT NULL; SHOW GLOBAL VARIABLES LIKE 'audit%'; -- Enterprise Audit in use? SHOW GLOBAL VARIABLES LIKE 'keyring%'; -- which keyring / KMS integration?
Most Enterprise estates use MySQL Enterprise Backup and Enterprise Audit and little else, and both have credible open-source equivalents (Percona XtraBackup and Percona Audit Log respectively).
Even with the MySQL Thread Pool now free, what legitimately keeps a subscription in place after 26.7 is a narrower list: Enterprise Backup where XtraBackup for your version line is not yet GA, hard Enterprise Firewall or Data Masking compliance requirements with no in-server open-source equivalent, Kerberos/LDAP enterprise authentication, DISA STIG or CIS contractual certification, NDB Cluster, or on-premises vector search and in-database LLMs via MySQL AI.
If none of those apply, Thread Pool's move removes one of the last performance-shaped reasons to renew. For a deeper look at eliminating server-side contention once the pool is in place, our InnoDB performance optimization guide covers the InnoDB-layer tuning that pairs with it.
MySQL Thread Pool FAQ
Is MySQL 26.7 Thread Pool the same as the Percona or MariaDB thread pool?
Not quite. The MySQL Thread Pool and its cousins solve the same problem with the same core idea — bounded thread groups multiplexing many connections — but they are independent implementations with different variables and internals. What 26.7 changes is that Oracle's canonical Thread Pool plugin, previously Enterprise-only, is now the free default option on stock MySQL Community, so you no longer need Percona Server or MariaDB to get an Oracle-lineage thread pool.
Do I need to restart MySQL to enable the MySQL Thread Pool?
Yes. thread_handling is read at server startup, so switching from one-connection-per-thread to pool-of-threads requires a restart. Plan it in a maintenance window, validate on a replica first, and keep the rollback (comment out the settings, restart) ready.
Should I run Thread Pool in production on MySQL 26.7?
The MySQL Thread Pool is worth staging, not rushing. Prove it on 26.7 in staging, but for production prefer the LTS line (9.7) that carries long support, since 26.7 is an Innovation release supported only until the next Innovation release. Adopt the pool where connection count greatly exceeds core count and throughput degrades under concurrency; skip it for latency-sensitive, low-concurrency, or OLAP workloads.
Does moving Thread Pool to Community end the case for MySQL Enterprise Edition?
No, but it narrows it. After 26.7, Enterprise's real value is security (Firewall, Data Masking, enterprise authentication), backup (MEB where XtraBackup is not GA for your line), MySQL AI, and Oracle support/certification — not performance or HA. Run the renewal audit above before deciding.
MySQL Thread Pool: Final Thoughts
MySQL 26.7 moving the Thread Pool plugin to Community edition is a small change to state and a meaningful one to act on for anyone tuning the MySQL Thread Pool. It gives every Community user Oracle's own connection-scaling model for free, it closes a fifteen-year Enterprise differentiator, and it reshapes the renewal math for anyone paying for Enterprise primarily for performance. The engineering discipline around it is unchanged: enable the MySQL Thread Pool only where the connection-to-core ratio justifies it, tune thread_pool_size and thread_pool_stall_limit against measured throughput, monitor the stall ratio in tp_thread_group_stats, and land it on your LTS line rather than a short-lived Innovation build.
Done that way, the MySQL Thread Pool becomes a measured throughput win rather than a configuration gamble, and the plugin's new Community status simply removes the licensing friction that used to sit in front of that decision.
If you are weighing a Thread Pool rollout, planning a 9.7 LTS upgrade, or reassessing an Enterprise renewal in light of the 9.7 and 26.7 Community transfers, MinervaDB's MySQL consulting and 24×7 enterprise-class database support teams do this work daily across 900+ enterprise customers, with staged, reversible changes and a rollback path stated before anything touches production. As always: test before applying to production, and maintain a robust, tested DR posture.
