MySQL Galera Cluster EOL: Your Practical Paths Forward

Maintenance and regular binary releases for all current MySQL Galera Cluster versions (Codership’s Galera build for Oracle MySQL, not MariaDB Galera Cluster or Percona XtraDB Cluster) end on September 30, 2026. Your cluster will not stop that day. What stops is the maintained path for future fixes and compatibility updates. Oracle MySQL 8.0 also entered Sustaining Support on April 21, 2026: deployments keep running, but Premier Support has ended, and with it the normal stream of fixes, updates and certifications. Most teams therefore face two decisions at once: which database version to run, and which availability architecture to run it on. (MariaDB EOL and migration announcement)

As we explored in Part 1, the cost of waiting extends beyond the software lifecycle itself. An unmaintained clustering layer becomes an audit and vendor-risk problem even while it runs perfectly well. Once the decision to move is made, however, the harder question is what should replace it. There is no universal replacement, and we would be suspicious of anyone who said there was. Some teams will preserve Galera; others will move to a different self-managed architecture, to a managed cloud provider, or off Galera altogether. The most familiar or least disruptive migration is not necessarily the best long-term destination.

What should drive this decision is what you must preserve, what you are permitted to change, and what the architecture has to survive over the next five years. The goal is to choose the operating model your team will still want to own years after the EOL deadlines have passed.

MySQL Galera Cluster EOL Options at a Glance

Continuent develops Tungsten Cluster, one of the five options below; we have tried to separate documented facts from our own assessment. Here are the five side by side: what each preserves, how hard the migration is, and the constraint most likely to bite you.

Your first decision is broader than which product to choose: do you still want Galera at all? If the architecture continues to fit your workload and operating model, moving to another maintained Galera implementation may be the most direct path. If the limitations of Galera are already driving operational or geographic constraints, EOL may be the right point to reconsider the availability model itself.

Should You Keep Galera?

Galera is still reasonable if you genuinely benefit from writing to more than one node, your transactions are short and predominantly non-conflicting, and every voting node sits inside a low-latency network. The wsrep tooling and runbooks you have count for something.

Reasons to keep Galera include:

• You write to more than one node, and it buys you something.
• Your workload fits Galera’s certification and flow-control model.
• All your nodes sit inside one low-latency region.
• Your team knows wsrep administration and recovery cold.
• Keeping the model saves you retraining and architectural churn.

Here is the pattern we see most often. The cluster is multi-primary on paper, but every write goes through one preferred node, because that is what stopped the certification conflicts. If so, you are paying the coordination cost of a multi-primary system for a capability you are not using.

Reasons to reconsider Galera include:

• The cluster is single-writer in practice.
• Flow control or certification conflicts are costing you performance.
• Latency between regions is capping your expansion.
• You need broader DR, hybrid-cloud or multi-cloud options.
• You want routing, failover, recovery and maintenance handled as one thing.
• Security, audit or vendor-risk policy will not tolerate an unmaintained clustering layer.

If you still want Galera, the two options carry different strategic dependencies. MariaDB Galera Cluster follows the roadmap of the company that owns Codership and employs the core Galera team. Percona XtraDB Cluster keeps you in the MySQL ecosystem through an independently maintained fork. Weigh that alongside migration effort and compatibility.

Five Practical Paths Forward From MySQL Galera Cluster

Path 1: Move to MariaDB Galera Cluster

MariaDB Galera Cluster is Galera on MariaDB, maintained by the company that now owns Codership and employs the core Galera engineering team, following the May 2025 acquisition. MariaDB documents two routes, node-by-node and a parallel cluster fed by asynchronous replication. The catch sits underneath either one: wsrep survives the move, the database does not. (MariaDB’s migration documentation)

Why teams choose this path:

• Follow the current Galera maintainers’ roadmap.
• Preserve Galera and wsrep expertise.
• Use a documented node-by-node migration.
• Avoid adopting a different availability model.

Best suited to: Teams that want to stay on Galera and whose applications, vendors and operating requirements permit a move from MySQL to MariaDB.

Where it is less compelling: If your connectors or vendor certifications are tied to Oracle MySQL, this path may be closed regardless of how direct it looks. It is also the wrong move if the Galera model itself is what stopped fitting.

What the move requires: Node-by-node is less disruptive than a parallel rebuild, but it is still a database product migration. MariaDB uses different system tables and a different data dictionary, and privileges need care. Test applications, connectors, SQL behavior, admin tooling, performance and third-party vendor certification. There is also a roadmap question: MariaDB initially proposed excluding Galera from Community Server 12.3, then reversed after community feedback. Before a multi-year commitment, confirm which Galera capabilities stay in Community Server and which will be tied to commercial offerings.

Path 2: Move to Percona XtraDB Cluster

Percona XtraDB Cluster is Percona Server for MySQL packaged with the Galera library and Percona XtraBackup, and Percona published migration guidance for MySQL Galera users in July 2026. It is supported today, and because the operating model barely changes it asks the least of your team on day one. The catch sits further out, in the upstream roadmap, and is worth settling before you commit. (Percona’s guidance)

Why teams choose this path:

• Remain within the MySQL ecosystem.
• Retain familiar Galera and wsrep operations.
• Reduce architectural retraining.
• Follow Percona’s published migration path.

Best suited to: Teams that must remain in the MySQL ecosystem and still need Galera, treating PXC as a deliberate decision with accepted roadmap risk.

Where it is less compelling: If you need a settled multi-year answer today, or cross-site DR is already on your roadmap. It solves the deadline, not the constraints that made Galera hard.

What the move requires: The immediate work is familiar: validate versions, check application compatibility, re-point routing, rebuild monitoring, test failover. The roadmap question is harder. MariaDB owns Galera and says all new feature development lands only in MariaDB Galera Cluster; Percona maintains its own open fork and says releases and patches continue at their existing cadence. Our view is that sustaining a Galera fork without its original engineers is difficult; Percona disputes that. That does not make PXC unsuitable, but it is a different long-term dependency. PXC 8.0.46-38 in July 2026 was the final 8.0 release, making 8.4 the current series. Before choosing PXC for the long term, confirm the support horizon for 8.4, patching commitments, and how future Galera fixes will be incorporated.

Path 3: Adopt Another Self-Managed MySQL Architecture

Staying self-managed on Oracle MySQL without Galera means choosing between two architectures. The first is Oracle’s InnoDB Cluster, a first-party stack of Group Replication, MySQL Shell AdminAPI and MySQL Router, with ClusterSet extending it across sites through asynchronous replication. Group Replication is not conventional asynchronous replication with tooling attached: it uses group communication, transaction certification and distributed membership, in single-primary or multi-primary mode, single-primary being the more common choice and avoiding several multi-writer constraints. The second architecture is one you assemble yourself around GTID-based asynchronous or semisynchronous replication, a proxy, monitoring and orchestration. The catch is that these are two different decisions under one heading, with different effort and risk. (Oracle’s ClusterSet documentation)

Why teams choose this path:

• Retain Oracle MySQL.
• Keep control of infrastructure and topology.
• Use Oracle’s first-party HA tools or your own.
• Tailor the architecture to your requirements.

Best suited to: Teams that must retain Oracle MySQL and either want Oracle’s first-party HA tools or already have the expertise to run a complete availability architecture.

Where it is less compelling: If your aim is to reduce operational burden rather than take on more. The custom route assumes dedicated platform engineering for the system’s life.

What the move requires: With InnoDB Cluster you build and seed a new environment, adopt Group Replication, and retire every Galera-specific runbook for MySQL Shell and Router workflows. Budget for retraining, not just the build. ClusterSet gives cross-site DR, though Oracle is explicit that emergency failover can lose transactions that had not reached the replica cluster, and may require manual reconciliation if the former primary has developed a divergent transaction history. The custom route buys flexibility and hands you the bill: failure detection, promotion safety, fencing, traffic redirection, recovery and failback, all built and maintained by you across components that were never one product.

Path 4: Move to Managed Cloud MySQL

Managed services hand infrastructure, backups, patching and local failover to the provider, but the label covers materially different things. Amazon RDS, Azure Database for MySQL, Google Cloud SQL and OCI MySQL HeatWave run managed MySQL, each with its own control plane and extensions. Amazon Aurora goes further, implementing MySQL compatibility over AWS’s own distributed storage. The catch is that compatibility, failover and DR then have to be checked service by service.

Why teams choose this path:

• Reduce infrastructure and maintenance responsibility.
• Use provider-managed local HA and backups.
• Integrate with an existing cloud environment.
• Shift day-to-day operations to the provider.

Best suited to: Teams prepared to standardize on one cloud provider and adapt applications and procedures to it.

Where it is less compelling: If you need hybrid or multi-cloud, if regulation or latency keeps part of the estate on-premises, or if your RPO target is tighter than unplanned regional failover allows.

What the move requires: A small cloud-native database moves easily; a large on-premises estate does not: a long initial load, replication-based sync, then a cutover. Applications move to provider endpoints, and you reassess networking, security, retries and cost. Read the regional DR fine print, because providers diverge there. Aurora typically replicates across regions in under a second, but that is not a guaranteed bound: planned switchover is RPO zero, unplanned failover is not. Azure gives automatic local HA and cross-region read replicas. Cloud SQL promotes a cross-region replica, then you reconfigure connections and DR topology. HeatWave gives local HA across fault domains but keeps read replicas in-region, so cross-region recovery leans on replication channels and backups.

Path 5: Replace Galera with Tungsten Cluster

Tungsten Cluster replaces the clustering layer and leaves the database in place: you keep a supported Oracle MySQL, Percona Server for MySQL or MariaDB. Tungsten Replicator moves and records transactions, Manager watches cluster health and coordinates role changes, and Connector is the endpoint applications talk to. Disclosure: Galera’s core developers worked at Continuent on m/cluster, our own synchronous product, before we moved to the asynchronous design that became Tungsten Cluster. (Tungsten Clustering documentation)

Why teams choose this path:

• Retain a supported Oracle MySQL, Percona Server for MySQL or MariaDB database.
• Use one platform for replication, routing and cluster management.
• Support local HA, DR and multi-region deployment.
• Follow an established Galera migration process with vendor support.

Best suited to: Teams that want to keep control of their database and infrastructure while replacing Galera with one platform for HA, routing, recovery, maintenance and DR.

Where it is less compelling: A stable single-region cluster that genuinely benefits from multi-primary writes and needs no broader DR. That is what Galera was built for, and we would rather say so than sell you a migration you do not need.

What the move requires: A typical migration builds Tungsten alongside your live cluster: restore a backup, replicate from Galera in real time, then repoint applications during a controlled cutover. Nearly all of it happens while Galera still serves traffic; the final interruption is limited to quiescing writes, confirming sync, redirecting connections and validating the new path. Continuent engineers can work alongside your team through the build and cutover, so connection changes, monitoring baselines and rollback are planned in advance. The architecture is asynchronous, so achievable RPO depends on replication progress when the failure hits: no asynchronous platform recovers transactions that never reached a replica. Tungsten records extracted transactions in a durable history log and promotes by node health, replication state and policy, selecting the most advanced eligible replica. (Galera-to-Tungsten migration guide)

Choose the Destination, Not Only the Migration

If you want to keep Galera and can move to MariaDB, MariaDB Galera Cluster is the most direct maintainer-led path. If you must stay in the MySQL ecosystem, PXC is likely the least disruptive transition; its long-term suitability depends on Percona’s independent maintenance. Choose it with that dependency written down.

InnoDB Cluster and native replication keep you on Oracle MySQL and self-managed, at the cost of a new operating model or a larger integration burden. Managed cloud services reduce infrastructure responsibility but introduce provider-specific compatibility, cost, failover and portability tradeoffs.

Tungsten Cluster is strongest when your goal reaches past preserving Galera. It swaps the clustering layer for an integrated platform covering HA, routing, recovery, maintenance and DR, with a documented migration process.

One more outcome deserves naming: some organizations will still be running MySQL Galera Cluster on October 1. If so, treat it as a time-bounded exception, not a decision. Freeze dependencies, document rollback, document vendor escalation paths, and fund a dated migration schedule.

Whatever you choose, choose the architecture your team can run confidently at 3 a.m. three years from now. September 30, 2026 is a deadline for software; the decision you make around it will outlast that date by years.

See how Continuent can help you assess your Galera environment, choose the right target architecture and plan a controlled migration.

Frequently Asked Questions About MySQL Galera Cluster EOL

What is MySQL Galera Cluster?

MySQL Galera Cluster is a virtually synchronous, multi-primary clustering solution based on write-set replication and certification, combining Oracle MySQL with the Galera library originally developed by Codership. Several nodes can accept writes and converge on the same data. It is distinct from MariaDB Galera Cluster and Percona XtraDB Cluster, which pair the same Galera technology with MariaDB and Percona Server for MySQL.

When does MySQL Galera Cluster reach end of life?

Maintenance and regular binary releases for all current MySQL Galera Cluster versions end on September 30, 2026. Existing clusters can continue running, but the MySQL Galera build will no longer have a maintained path for future fixes and releases.

Will MySQL Galera Cluster stop working after September 30, 2026?

No. The software will not automatically stop on the EOL date. The concern is that organizations continuing to use it will be operating an unmaintained clustering layer, increasing their exposure to future defects and compatibility problems.

What are the main alternatives to MySQL Galera Cluster?

The main options are MariaDB Galera Cluster, Percona XtraDB Cluster, MySQL InnoDB Cluster, native MySQL replication, managed cloud MySQL services and Tungsten Cluster. The right choice depends on whether you must preserve Galera, retain Oracle MySQL, reduce infrastructure ownership or adopt a broader HA and DR platform.

Can MySQL Galera Cluster be migrated in place?

MariaDB documents a node-by-node in-place migration from MySQL Galera Cluster to MariaDB Galera Cluster, alongside a replication-based method. This can limit disruption, but it also changes the underlying database from MySQL to MariaDB. Applications, connectors, privileges, tooling and database behavior still require testing.

Is Percona XtraDB Cluster a safe long-term replacement for MySQL Galera Cluster?

PXC is likely the most familiar option for organizations that must remain within the MySQL ecosystem and want to preserve Galera and wsrep concepts. Its longer-term suitability depends on Percona’s independent Galera maintenance. MariaDB now owns Codership and employs the core Galera team, and has said all new feature development will land exclusively in MariaDB Galera Cluster. Percona maintains its own open fork, commits to continued releases and patches, and shipped its final PXC 8.0 release in July 2026, making 8.4 the current series. Evaluate Percona’s engineering capacity, patching commitments and support horizon directly.

I already run Percona XtraDB Cluster. Does this EOL affect me?

Not directly, but it is worth reviewing. The September 30, 2026 date applies to MySQL Galera Cluster, not PXC, and Percona continues to support and release PXC. Two things are worth tracking: Galera is now owned by MariaDB, which has said new feature development lands only in MariaDB Galera Cluster; and Percona shipped its final PXC 8.0 release in July 2026, making 8.4 the current series. Confirm your version is still in support, and ask Percona about engineering capacity and support horizon.

Can Continuent migrate Galera to Tungsten Cluster with minimal downtime?

Continuent’s documented process builds and seeds the Tungsten environment while the existing Galera cluster remains online. Real-time replication keeps the destination synchronized before applications are repointed during a controlled cutover, limiting the final interruption to quiescing writes, confirming synchronization, redirecting connections and validating the new path.

What is the difference between Galera and Tungsten Cluster?

Galera is built around multi-primary write-set replication between database nodes. Tungsten Cluster instead combines asynchronous transaction replication with integrated cluster management and application routing. This architecture supports local HA, recovery, failback, disaster recovery and multi-region deployment without requiring a Galera-enabled database server.

Does moving to Tungsten Cluster require switching from MySQL to MariaDB?

No. Tungsten Cluster works with supported MySQL, MariaDB and Percona Server for MySQL databases, so replacing the Galera availability layer need not also become a move from MySQL to MariaDB. The specific version must still be checked against Continuent’s current support matrix.

Can Tungsten Cluster support on-premises, cloud and multi-cloud deployments?

Yes. Tungsten Cluster can be deployed on-premises, in the cloud and across hybrid-cloud or multi-cloud infrastructure, supporting local high availability and geographically distributed disaster recovery without tying the availability layer to one cloud provider. Network latency, security architecture and the chosen replication topology still shape what is practical.

Does Continuent have experience migrating production Galera environments?

Yes. Continuent has production experience migrating Galera environments, including the published VMware use case. VMware synchronized its multi-region Galera environment with Tungsten Replicator and moved applications through a controlled endpoint cutover with minimal downtime.

When does Tungsten Cluster make more sense than another Galera platform?

Tungsten Cluster is most relevant when the requirement extends beyond preserving Galera. It is designed for organizations needing integrated replication, application routing, failover, recovery, maintenance and disaster recovery across their chosen infrastructure, through one platform and one vendor relationship.