MySQL Galera Cluster will not stop working on October 1, 2026. Applications will still connect, replication will still run, and monitoring may remain green. What changes on September 30 is less visible: maintenance and regular binary releases for current MySQL Galera Cluster versions end.
From that point forward, organizations that remain on the platform increasingly own the consequences of running software that is no longer moving with the ecosystem around it.
For many teams, that is only half of the lifecycle problem. MySQL 8.0 itself reached end of life in April 2026. Organizations still running MySQL Galera on 8.0 therefore already have an unsupported database version underneath a clustering layer that is approaching its own EOL.
The practical goal is not necessarily to complete a production migration by September 30. It is to reach that date with a destination selected, a funded migration plan, and a clear understanding of the risk being carried until cutover.
Why Galera Users Are Dealing With Two Lifecycle Decisions
A MySQL Galera deployment depends on two vendors, not one. Oracle develops MySQL, but a Galera cluster does not run Oracle's version of it. It runs MySQL-wsrep, a modified build of MySQL Server paired with the Galera replication library, created by Codership and published today by MariaDB. The software underneath your cluster therefore follows MariaDB's release schedule rather than Oracle's.
Those two schedules are now pulling apart:
- MySQL 8.0 reached EOL in April 2026. Version 8.0.46 was the final release; Oracle now places 8.0 under Sustaining Support and points users to 8.4 LTS or 9.7 LTS. Galera cannot follow onto 9.7, since wsrep builds stop at 8.4.
- MySQL Galera Cluster maintenance ends September 30, 2026. MariaDB, which acquired Codership in 2025, has committed to maintaining current MySQL Galera Cluster versions through that date. This EOL does not apply to MariaDB Galera Cluster or Percona XtraDB Cluster.
- MySQL 8.4 has a much longer support horizon. Oracle Premier Support for MySQL 8.4 runs through April 2029, followed by Extended Support through April 2032. But upgrading the database does not remove the separate EOL of the MySQL Galera integration.
That last point is the one most likely to be misunderstood. Moving a Galera cluster from MySQL 8.0 to MySQL 8.4 addresses the immediate MySQL end-of-life issue, but it does not resolve Galera’s separate end-of-life. Once MySQL Galera maintenance ends, there is no assured path for keeping Galera aligned with future MySQL releases.
Your Urgency Depends on Where You Are Today
The same September deadline creates different levels of urgency depending on the database version underneath the cluster.
| Current state | What is supported | What it means |
|---|---|---|
| MySQL Galera + MySQL 8.0 | MySQL 8.0 is EOL; MySQL Galera maintenance continues only through September 30. | Both the database-version and clustering-platform decisions are active now. |
| MySQL Galera + MySQL 8.4 | MySQL-wsrep is built and maintained by MariaDB, not Oracle, and that maintenance ends September 30, 2026. | The MySQL 8.4 line has runway. Your Galera build does not. |
| Migrated off MySQL Galera | Support depends on the destination selected. | Your future patching and platform lifecycle are determined by the new architecture. |
For an organization still on MySQL 8.0, the exposure is already active. The July 2026 Oracle Critical Patch Update includes MySQL Server fixes for supported 8.4 and 9.x releases, but not MySQL Server 8.0. That is a concrete example of what EOL means in practice: the system may continue operating normally while the supported patch stream moves on without it.
The gap is already visible on 8.4. The newest wsrep build stops at MySQL 8.4.8 while Oracle has since shipped 8.4.11. July's Critical Patch Update lists 8.4.0 through 8.4.10 among the affected versions, which includes every current Galera 8.4 cluster. Rebases stop on September 30.
What Waiting Changes
The Business Risk Grows Over Time
The risk after EOL is gradual, which is precisely why it is easy to underestimate. There is no single October 1 failure event. The database continues to run. What changes is the level of support, flexibility, and control the organization has around it.
Security and Supportability Begin to Erode
Once a release leaves normal maintenance, organizations can no longer rely on a maintained vendor path for newly discovered issues. That does not mean every new vulnerability will affect an older release. It does mean that when one does, the options for addressing it may be limited.
For organizations with security, compliance, or customer requirements, running unsupported infrastructure can also become increasingly difficult to justify to auditors, customers, and internal risk teams.
Operating Complexity and Cost Increase
The rest of the technology environment does not stand still. Operating systems, backup products, monitoring tools, connectors, and other dependencies continue to evolve.
Over time, maintaining an unsupported component can require exceptions, older dependencies, additional testing, and specialized operational knowledge. Each workaround may be manageable, but together they increase cost, complexity, and the risk of making changes to a business-critical system.
Eventually, the Schedule Stops Being Yours
This is perhaps the most important business risk.
A migration planned on your own timetable can be scheduled around budgets, staffing, release cycles, testing, and business priorities. A migration forced by a security issue, audit finding, production defect, or unsupported dependency cannot.
Waiting does not guarantee a crisis. It does, however, increase the likelihood that an external event—not your organization—will determine when you have to act.
That is the compounding risk of EOL: support options narrow, operational exceptions accumulate, and the eventual migration becomes more difficult. At the same time, the organization may have less time to evaluate alternatives, test thoroughly, and execute the transition safely.
The business objective, therefore, is not simply to avoid running unsupported software - it is to make the transition while you still control the timeline.
What Should Be Decided by September 30
With roughly five weeks remaining as of August 21st, 2026, completing a complex production migration before the EOL date may not be realistic for every organization. Making the decision should be.
By September 30, a team that is not yet migrated should ideally have three things in hand:
- A destination architecture selected, including whether the organization intends to preserve Galera or change the availability model.
- A funded migration plan with ownership, validation work, and a target cutover window.
- A documented interim exception that identifies the unsupported components, dependencies that should remain frozen, rollback expectations, and escalation paths until migration is complete.
That reframes September 30 in a more useful way. It is the software maintenance deadline, but it does not have to become an artificial deadline for a rushed production cutover. The objective is to stop drifting and make the remaining time intentional.
Where to Go From Here
The next decision is architectural, and every option on the table is a migration.
MySQL Galera Cluster is what ends, so nothing leaves your stack as it is. The options differ in how much of it you keep. Percona XtraDB Cluster keeps you on MySQL and changes who builds and maintains the cluster. MariaDB Galera Cluster keeps the Galera replication model and changes the database engine underneath it. Or you can treat the deadline as a reason to reconsider availability altogether, with another self-managed MySQL architecture, a managed cloud service, or Tungsten Cluster, a multi-site MySQL HA platform.
Those choices solve different problems and carry different migration costs. Part 2, “MySQL Galera Cluster EOL: Your Practical Paths Forward,” compares the major paths, what each preserves, and where the trade-offs are most likely to matter.
The important point for Part 1 is simpler: MySQL Galera Cluster does not become unusable on October 1. It becomes increasingly yours to support. Decide what you are doing about that while the timing is still under your control.
See how Continuent can help you assess your Galera environment, choose a target architecture, and plan a controlled migration.
Frequently Asked Questions About MySQL Galera Cluster EOL
When does MySQL Galera Cluster reach end of life?
Maintenance and regular binary releases for current MySQL Galera Cluster versions end on September 30, 2026. Existing clusters can continue running after that date, but the maintained path for future MySQL Galera fixes and releases ends.
Will MySQL Galera Cluster stop working after September 30, 2026?
No. EOL does not disable a running cluster. The concern is supportability: future defects, compatibility changes, and database updates may no longer have a maintained MySQL Galera build that incorporates them.
Do I need to migrate MySQL Galera Cluster before September 30, 2026?
Not necessarily. For many production environments, completing a safe migration before the deadline may be unrealistic. The more important goal is to reach September 30 with a destination selected, a funded migration plan, and a clear understanding of the interim risk until cutover.
What should organizations do before MySQL Galera Cluster reaches EOL?
At minimum, teams should select a destination architecture, assign ownership and funding for the migration, and define a target cutover window. If the migration will happen after September 30, the unsupported components, frozen dependencies, rollback expectations, and escalation paths should also be documented.
Does upgrading to MySQL 8.4 solve the Galera EOL problem?
No. It solves a separate lifecycle problem. MySQL 8.4 itself has a long support horizon, but a Galera cluster runs MySQL-wsrep, and MariaDB's maintenance of that build ends September 30, 2026. Upgrading puts you on the newest Galera build available, which is a better place to plan from than 8.0, but it does not remove the need for a longer-term clustering decision.
What does MySQL 8.0 EOL mean for MySQL Galera Cluster users?
MySQL 8.0 reached EOL in April 2026 with 8.0.46 as its final release. Teams still running MySQL Galera on 8.0 therefore face two lifecycle issues at once: an unsupported database version and a clustering layer approaching its own EOL. Supported MySQL release lines continue receiving fixes that are no longer issued as new MySQL Server 8.0 releases.
Does this EOL affect MariaDB Galera Cluster or Percona XtraDB Cluster?
No. The September 30, 2026 date applies to MySQL Galera Cluster. MariaDB Galera Cluster and Percona XtraDB Cluster are separate products with their own maintainers and support lifecycles, and both may be migration options for organizations that want to preserve Galera concepts.
Is it safe to keep running MySQL Galera Cluster after September 30, 2026?
There is no universal yes-or-no answer. A cluster may continue operating normally, but the longer it remains on an unmaintained platform, the more the organization may need to manage security, compatibility, audit, vendor-support, and operational exceptions itself. The practical risk depends on your database version, dependencies, compliance requirements, and how long the exception is expected to last.
Comments
Add new comment