Open-source database cluster support ends, forcing upkeep choices
The open-source relational database's Galera cluster has reached the end of its existing development and maintenance path, according to Percona, putting incident support and future fixes at the centre of an operational decision for database teams. In an October 8, 2026 article, Valeria Bogatyreva reports that the database vendor, which acquired Codership in May 2025, set September 30, 2026 as the support deadline for all current versions of that database's Galera cluster. Development, maintenance and binary releases, the ready-to-install software packages, end under that policy.
A cluster is a group of database servers, called nodes, working together. Galera supplies replication, the mechanism that keeps their data coordinated. The deadline does not itself change how an installed cluster runs: it should behave on October 1 as it did the previous day. What changes is the route to expert escalation and an eventual software correction. That distinction matters because a database can remain operational while the arrangements needed to recover from its next difficult failure have disappeared.
Diagnosis, not replication alone, can dominate an outage. Bogatyreva cites incidents attributed to the Codership team in which queries accumulated without useful errors in the logs, the records software leaves about its activity. One outage lasted twenty minutes and ended only after someone chose a node to terminate. Another involved flow control, the mechanism that slows incoming work when cluster members cannot keep up: writes timed out while the sent flow-control message counter, a counter of flow-control messages sent, remained at 0. The expected signal therefore did not reveal the stall.
Percona argues that such failures often originate outside Galera's write-set replication, which distributes the changes made by database transactions. Examples include flashcache, a storage caching component; an overridden replication provider options configuration line; DNS, the name-to-address lookup service, resolving to the wrong network interface; and a firewall allowing communication in only one direction. In another case, a team investigating repeated restarts in Kubernetes, software for coordinating application containers, had to read the source code of its operator, the automation that manages the database. These examples explain why mean time to recovery, the time needed to restore service, can be driven more by finding the cause than by repairing it.
The migration route recommended by the vendor's enterprise database offering is its alternative database's Galera cluster. That is not simply a replacement support arrangement for the same database. As Percona notes, the alternative database has different system tables, which store internal database information, and a fundamentally different data dictionary, the catalogue describing database objects. The alternative database's migration notes also call for systematically recreating user privileges, the permissions controlling access. For organisations that want to remain on the original database, those differences make the choice an architectural decision rather than a contract renewal.
Percona presents two alternatives, both commercial options from a supplier with an interest in the decision. Its database support offering covers an existing Galera cluster of the original database without migration, platform replacement or rebuilding privileges. Percona advertises senior engineers for the original database available 24x7x365 through teams working across time zones, with both incident triage and advisory help. That advice covers replication interface tuning, adjustment of the interface between the original database and Galera; DDL strategy, planning database structure changes; distribution of writes; and quorum design, deciding how enough nodes agree that the cluster may continue operating. Its Premium tier advertises contractual initial responses as short as 15 minutes for Severity 1 incidents. An initial-response commitment is not a repair-time guarantee.
The other option is Percona's maintained cluster distribution, which combines Percona's distribution of the original database server with Percona's own Galera library fork, a separately maintained version available in a public repository. Percona describes it as compatible with the original database's community edition and says database schemas, the definitions of tables and their relationships, system tables and user accounts carry over unchanged. It also says replication interface behaviour, tools, connectors and the wider ecosystem remain familiar. A public ten-step migration walkthrough is available to follow independently. These are Percona's compatibility claims, not evidence that every deployment can be moved without validation.
Percona's case for its maintained cluster distribution rests on continued maintenance of the cluster layer. It identifies work on incremental state transfer (IST), which supplies changes a recovering node missed, and state snapshot transfer (SST), which supplies a full data copy. Other areas include node eviction, removing a member from the cluster; flow control; and DDL while writes are occurring concurrently. The company points to quarterly public release notes with Jira issue identifiers, the references used to track individual fixes. The supplied source includes a release-table image but does not expose its contents, so individual fixes or identifiers cannot be established from that text.
According to Percona, that release cadence extends back to 2012 across versions 5.5, 5.6, 5.7, 8.0 and now 8.4, with the 8.0 line still receiving releases alongside it. The company says nearly 4,000 host instances of its maintained cluster distribution reported telemetry, automatically sent usage information, outside Kubernetes during the preceding 90 days. It separately reports that the maintained cluster distribution's Operator runs across thousands more Kubernetes deployments. These are supplier-reported figures, not an independent count of users or a reliability measurement. Percona also points to recent work on replication cache inspection, examining Galera's cache of replicated changes, and cross-site replication in the Operator, which coordinates copies across locations.
For customers using its migration service, Percona describes a target test environment and a comparison of replication interface behaviour with the existing cluster. The aim is to observe how the replacement handles the same failures before committing. The service also includes a documented rollback plan, a scheduled cutover with off-hours support, and a health audit a few weeks after production use begins. Those are useful evaluation criteria for any migration proposal: compatibility should be checked against the actual workload and failure behaviour, with a defined way back if the move fails.