Open-source database 26.7 starts calendar versioning
The open-source database 26.7 marks a significant change for teams that operate the relational database used by many web applications in production: the database has moved from the familiar 8.x and 9.x numbering line into a calendar-based release scheme. Percona reports that the vendor shipped the new Innovation release as 26.7.0 rather than 9.8, using a Year.Month.Patch pattern that makes the release date visible in the version number itself.
The change follows several earlier phases in the database server’s versioning. Version 8.0, used from 2018 to 2026, followed a traditional single-track model in which new features and bug fixes arrived in the same 8.0 line. In mid 2023, the vendor introduced a dual-track model with Innovation releases and Long Term Stable releases. An Innovation release is the faster-moving branch for new features and changes, while an LTS release is the steadier branch intended for longer production use. Percona describes the LTS support cycle as 5 years of Premier Support followed by 3 years of Extended Support, with a typical new LTS roughly every 2 years.
Under that model, Innovation releases 8.1, 8.2 and 8.3 arrived between 2023 and 2024, leading to the first LTS release, 8.4, in April 2024. The Innovation numbering later moved into the 9.x series, with versions 9.0 through 9.6 released between 2024 and 2026. The second LTS release, 9.7, arrived in April 2026, again with the 5 year Premier Support period followed by 3 years of Extended Support.
The new numbering scheme is written as YY.M.P. In 26.7.0, 26 stands for 2026, 7 stands for July and 0 is the patch number, meaning a smaller corrective update within that release. Percona says the quarterly Innovation release cycle continues under the new format. It gives 26.10.0 as the tentative next Innovation release for October 2026, and says the next LTS release under the new scheme is expected in April 2028 as 28.4.0.
For database administrators, the main value is planning clarity. A version such as 26.7.0 immediately shows when the release was shipped, while labels such as 8.4 or 9.7 do not carry that timing information on their face. Percona also states that the change does not affect existing LTS releases 8.4 and 9.7. Those branches continue to receive normal quarterly maintenance updates, including bug fixes and security patches, while new Innovation features move into the calendar-numbered series.
The upgrade path is important. Percona says the database server 9.7.x LTS is the only entry point into the first calendar-versioned lineage, 26.7.0. In practice, a system must first be upgraded to 9.7 LTS before moving to 26.7.0. Version 8.4.x LTS or earlier versions cannot jump directly into the new lineage. A single-hop upgrade from 9.7.x LTS to 26.7.0, or to later releases in the same lineage such as 26.10.0, 27.1.0 or 27.4.0, remains valid until the next LTS, 28.4.0. Percona gives the example path 8.4.x LTS to 9.7.x LTS to 26.7.0, and notes that older end-of-life versions such as 5.7 or 8.0 must first move to 8.4 LTS before following that route.
The open-source database 26.7 also adds a Change Stream Applier, a replication component that changes how replica servers apply database changes. Replication means copying data changes from one database server to another so a standby or secondary system can stay aligned with the primary. The earlier Multi-threaded Applier used a coordinator to read transactions sequentially from relay files, then hand them to worker threads for parallel execution. That model can lose efficiency when a worker is idle while waiting to commit because an earlier or dependent transaction must finish first.
The Change Stream Applier separates applying a transaction from committing it in the required order. If a worker has finished applying a transaction but must wait before committing, it can move on to another dependency-ready transaction instead. Percona lists three replication settings connected with this change: the applier version setting, where 1 means the older Multi-threaded Applier and 2 means the Change Stream Applier; the applier worker count setting, which sets the worker count per replication channel; and the applier event memory limit setting, which sets per-channel memory limits for cached binary log events. A binary log is a record of database changes used for recovery and replication.
Percona also notes two operational improvements. Change Stream Applier workers can read transaction events from the relay log at the same time and release event memory after events are consumed. Relay log files can be marked for concurrent purging once all transactions have been applied successfully and nothing remains to be read from those files. To use the feature, Percona says row-based replication is required, with binary logging set to row mode, and Global Transaction Identifier enforcement must be on. A Global Transaction Identifier is a unique label for a database transaction that helps servers track what has already been processed.
Another notable change is the Thread Pool Plugin becoming available in Community releases. The database server has traditionally used a one-thread-per-connection model, meaning each client connection creates its own server thread. That can become expensive when an application opens many simultaneous connections, especially if many are idle or sleeping while waiting for work. A thread pool handles many client connections through a smaller, controlled number of worker threads, reducing the need to create a separate thread for every connection. Percona says this is useful where applications create very high numbers of concurrent database connections and raising the maximum connection setting would cause excessive thread creation and resource use.
Percona describes enabling the plugin by loading the thread pool shared module in the database server configuration, restarting the database service and verifying that the thread pool plugin is active through the server’s plugin information view. It also lists thread pool configuration variables such as the thread pool size, query threads per group, maximum unused threads and stall limit settings. Monitoring is available through Performance Schema tables for connections, thread group state, thread group statistics and thread state, plus status variables for thread pool query threads. Performance Schema is the database server’s built-in set of tables for observing server activity.
The open-source database 26.7 also changes undo log truncation in InnoDB, the storage engine that manages how data is stored and recovered inside the database server. An undo log records earlier versions of changed data so transactions can be rolled back and consistent reads can be served. Previously, InnoDB used a separate undo truncation log file to track undo tablespace truncation, including during recovery.