MySQL operators on Kubernetes: an honest comparison
Four active operators, three replication models, and their real trade-offs
With MySQL, choosing an operator also means choosing a replication model: Galera, Group Replication, or semi-synchronous replication. That choice is hard to change later.
We compared the Percona Operator for MySQL based on Percona XtraDB Cluster, the Percona Operator for MySQL based on Percona Server, the Oracle MySQL Operator, and MOCO across replication, availability, backups, day-2 operations, monitoring, and community health. No vendor paid for placement on this page.
The Bitpoke (formerly Presslabs) MySQL Operator was once popular, but its last release was in 2023. Vitess solves a different problem, sharding, and MariaDB is a separate database. All three are covered below but left out of the scored comparison.
The four operators
| Operator | Latest | License | Maintainer | Since | In short |
|---|---|---|---|---|---|
| Percona XtraDB Cluster | v1.20 | Apache 2.0 | Percona LLC | 2019 | Galera-based synchronous clustering with HAProxy or ProxySQL in front. The longest-running MySQL operator in this comparison. |
| Percona Server for MySQL | v1.2 | Apache 2.0 | Percona LLC | 2022 | Group Replication with HAProxy or MySQL Router, generally available since November 2025. Asynchronous replication with Orchestrator is still a tech preview. |
| Oracle MySQL Operator | 2.3 | UPL 1.0 | Oracle | 2021 | The official operator for InnoDB Cluster: Group Replication, MySQL Router, and MySQL Shell. Physical backups and point-in-time recovery need the commercial MySQL Enterprise Backup. |
| MOCO | v0.37 | Apache 2.0 | Cybozu | 2020 | A lean operator built on GTID-based, loss-less semi-synchronous replication, with backups and point-in-time recovery through MySQL Shell dumps and binary logs. |
Scores at a glance
Scores are out of 10 and based on documented features, not marketing claims. Features still in tech preview count for less. Pick an operator to highlight it.
| Dimension | PXC | PS | Oracle | MOCO |
|---|---|---|---|---|
| High availability | 9 | 8 | 8 | 8 |
| Backup and recovery | 9 | 7 | 5 | 7 |
| Day-2 operations | 8 | 7 | 7 | 7 |
| Community | 7 | 6 | 5 | 6 |
| Topology options | 6 | 8 | 8 | 5 |
| Monitoring | 9 | 9 | 5 | 7 |
Deep dive: what actually matters
Each section covers one dimension and how each operator handles it. Open a section to compare.
Replication model and topologyThe biggest decision, and your operator choice locks it in.
Percona XtraDB Cluster
- Galera: virtually synchronous replication, with each transaction certified on every node at commit
- Every node can accept writes, but HAProxy sends writes to one node by default to avoid certification conflicts
- HAProxy by default, or ProxySQL for query-aware read/write splitting
- Cross-site asynchronous replication to another cluster
- Galera limits apply: InnoDB only, primary keys required, and a cap on transaction size
Mature synchronous clustering. Flow control slows the whole cluster down to its slowest node, so plan for it.
Percona Server for MySQL
- Group Replication in single-primary mode, generally available
- Asynchronous replication with Orchestrator, still a tech preview
- HAProxy or MySQL Router in front
- Cross-site replication for Group Replication clusters since v1.2
- Built on upstream MySQL replication, not a Galera fork
The most choice on paper. In production today, that means Group Replication.
Oracle
- InnoDB Cluster: Group Replication managed through MySQL Shell
- MySQL Router routes reads and writes automatically
- Read replicas outside the Group Replication group
- Can join an InnoDB ClusterSet for disaster recovery across clusters
The upstream pattern, exactly as Oracle documents it.
MOCO
- GTID-based, loss-less semi-synchronous replication
- One writable primary with 1, 3, or 5 instances in total
- Separate Kubernetes Services for the primary and the replicas, with no proxy
- Replication from an external MySQL server, useful for migrations
- Deliberately avoids Group Replication and its limitations
Standard MySQL replication with the fewest restrictions on schemas and transactions.
High availability and failoverHow fast does the system recover when things break?
Percona XtraDB Cluster
- No primary to elect: the remaining nodes keep serving as long as they have quorum
- HAProxy health checks move writes to another node within seconds
- Committed transactions are on every node, so a node failure loses no data
- Rejoining nodes catch up with an incremental or full state transfer
The simplest failover model of the four, proven in Galera deployments for over a decade.
Percona Server for MySQL
- Group Replication elects a new primary when a majority agrees
- HAProxy or MySQL Router follows the new primary
- Network partitions are handled safely by the quorum
- Orchestrator manages failover for asynchronous clusters (tech preview)
Solid consensus-based failover, generally available since late 2025.
Oracle
- Group Replication elects a new primary
- MySQL Router updates routing automatically
- The operator drives the cluster through the MySQL Shell AdminAPI
- ClusterSet adds a disaster recovery path to another cluster
Mature Group Replication failover. The logic lives in MySQL Shell, which is harder to inspect from Kubernetes.
MOCO
- Automatic failover promotes the most up-to-date replica
- Loss-less semi-sync means acknowledged commits are on a replica before the client sees them
- Detects and excludes instances with errant transactions
- Manual and automatic switchover, plus generated PodDisruptionBudgets
Careful, Kubernetes-native failover with no external store or proxy.
Backup and recoveryCan you restore to any point in time, and how complex is the setup?
Percona XtraDB Cluster
- Percona XtraBackup: hot, physical backups
- Point-in-time recovery from binary logs uploaded continuously, since 2021
- S3, Google Cloud Storage, Azure Blob, or a PVC
- Scheduled backups and retention through the custom resource
- No incremental backups
The most mature backup story here. Point-in-time recovery has been generally available for years.
Percona Server for MySQL
- Percona XtraBackup: hot, physical backups
- S3, Google Cloud Storage, or Azure Blob
- Backup compression and encryption
- Incremental backups, a tech preview since v1.1
- Point-in-time recovery with a binlog server, still a tech preview in v1.2
Strong foundations, but point-in-time recovery isn't production-ready yet.
Oracle
- Logical backups with MySQL Shell dump utilities
- S3, OCI Object Storage, Azure Blob, or a PVC
- Backup schedules in the custom resource
- Physical, incremental, and point-in-time recovery need MySQL Enterprise Backup, a commercial product
Fine for small databases on the free path. Large databases and point-in-time recovery need an Enterprise subscription.
MOCO
- Logical full backups with MySQL Shell's
dumpInstance - Binary logs saved with each backup for point-in-time recovery
- S3-compatible object storage
- Scheduled through a BackupPolicy resource
- Restores create a new cluster
Complete and automated, but logical restores get slow for multi-terabyte databases.
Day-2 operationsUpgrades, scaling, and storage: the work that matters at 3 AM.
Percona XtraDB Cluster
- Rolling upgrades, with optional automatic minor version updates
- Scale nodes and proxies declaratively
- Cluster pause and resume
- Automatic storage resizing and automated TLS certificate rotation since v1.20
- Percona XtraDB Cluster 8.4 by default since v1.19
The broadest day-2 coverage, refined over many releases.
Percona Server for MySQL
- Rolling upgrades for minor versions
- Scale the Group Replication cluster and routers
- PodDisruptionBudgets, and automatic storage resizing since v1.2
- OpenShift and OLM support
- Full MySQL 8.4 support
Catching up quickly with its older sibling.
Oracle
- Rolling upgrades by changing the version in the custom resource
- Scale instances, routers, and read replicas declaratively
- Cluster lifecycle handled through MySQL Shell
- Releases follow the MySQL server release train
Works well within the InnoDB Cluster model, with less room to deviate from it.
MOCO
- Rolling upgrades of MySQL versions
- A
kubectl mocoplugin for common tasks - Replicas initialized with the MySQL clone plugin
- Custom Pod, Service, and PVC templates
- Slow query logs redirected to a sidecar
Lean and predictable. It doesn't try to be a full platform.
Monitoring and observabilityMetrics, dashboards, and query analytics out of the box, or bring your own?
Percona XtraDB Cluster
- Percona Monitoring and Management (PMM) integration, including PMM 3
- Query Analytics for per-query insight
- Ready-made dashboards for MySQL and Galera
Complete monitoring with one setting.
Percona Server for MySQL
- PMM integration, including PMM 3
- Query Analytics
- Dashboards for Group Replication and replication lag
The same PMM experience as the XtraDB Cluster operator.
Oracle
- Optional metrics sidecar, with an exporter image you provide
- Can create a ServiceMonitor for Prometheus Operator
- No dashboards included
- MySQL Enterprise Monitor is a commercial product
Bring your own monitoring stack.
MOCO
- Built-in mysqld_exporter
- Operator metrics for cluster state and replication delay
- No dashboards included
Metrics-first and standard. You bring the dashboards.
SecurityTLS, encryption at rest, and certificates.
Percona XtraDB Cluster
- TLS for clients and replication
- cert-manager integration with configurable certificate lifetimes
- Data-at-rest encryption with HashiCorp Vault
- Custom CA certificates for S3 backups
Percona Server for MySQL
- TLS for clients and replication
- cert-manager integration
- Data-at-rest encryption with HashiCorp Vault
- Encrypted backups
Oracle
- TLS with your own or self-signed certificates
- Keyring configuration for data-at-rest encryption
- Audit logging needs MySQL Enterprise Edition
MOCO
- mTLS between the operator and its agents, through cert-manager
- Randomly generated passwords stored as Secrets
- Client TLS configured yourself through custom
my.cnf
How the operators evolved
Who shipped what, and when. The bars show each project's active years. Select a point to see what shipped.
Select a point on the timeline to see what shipped.
Development velocity, 2025–2026
| Operator | Activity | Notes |
|---|---|---|
| Percona Server | 7 releases since January 2025, including the 1.0 GA | |
| MOCO | 12 releases since January 2025, mostly small | |
| Percona XtraDB Cluster | 5 releases since January 2025, steady cadence | |
| Oracle | Follows the MySQL server release train, about quarterly | |
| Bitpoke | No releases since May 2023 |
Community health and business viability
An operator's features mean nothing if the project dies in two years. These are the signals that matter for a long-term bet.
| Percona XtraDB Cluster | Percona Server | Oracle | MOCO | |
|---|---|---|---|---|
| Backed by | Percona LLC, founded 2006 | Percona LLC | Oracle, the owner of MySQL | Cybozu, a Japanese software company |
| Business model | Open source, plus paid support and managed services | Open source, plus paid support and managed services | Free operator; commercial MySQL Enterprise Edition and HeatWave | Internal tool, open-sourced, with no commercial offering |
| License | Apache 2.0 | Apache 2.0 | UPL 1.0 | Apache 2.0 |
| Release cadence | Every 3–5 months | Every 2–4 months | With MySQL server releases, about quarterly | Frequent, small releases |
| GitHub stars | About 620 | About 230 | About 950 | About 380 |
| Contributors | Mostly Percona employees; external PRs accepted | Mostly Percona employees; external PRs accepted | The MySQL team at Oracle; contributions go through bugs.mysql.com | Mostly Cybozu engineers |
| Commercial support | Percona; also part of OpenEverest and PMM | Percona; also part of OpenEverest | Oracle, with a MySQL Enterprise subscription | None |
Percona XtraDB ClusterStrong
The longest-running production MySQL operator, from a profitable database company with nearly 20 years of history. It keeps shipping substantial features, such as 8.4 by default, encryption at rest, and automatic storage resizing in 2026. Percona now develops two MySQL operators, so it is worth watching where new features land first.
Funded company, regular releases, enterprise support, long track record. Corporate-driven.
Percona Server for MySQLStrong
Percona's newer operator, built on upstream Group Replication. It reached general availability in November 2025 and is the most actively developed of the four. It is also the least proven: point-in-time recovery, incremental backups, and asynchronous replication are still tech previews.
Active investment, enterprise support. Young in production, key features in tech preview.
Oracle MySQL OperatorGood
The official operator from the company that owns MySQL, so it won't disappear. Development happens inside Oracle: GitHub is a mirror, bugs and contributions go through bugs.mysql.com, and the free version leaves out physical backups, point-in-time recovery, and monitoring, which Oracle sells as MySQL Enterprise.
Official, here to stay. Closed development process, key features need a subscription.
MOCOGood
A well-engineered operator that Cybozu built for its own services and releases often. It uses standard semi-synchronous replication, which is fully supported in current MySQL versions; only the old master and slave names of its settings were deprecated. The risks are that it depends on one company that isn't a database vendor, and there is no commercial support.
Clean design, regular releases, standard replication. Single company, no commercial support.
Bitpoke MySQL Operator
Started as the Presslabs MySQL Operator in 2018 for hosting WordPress on Kubernetes, and was one of the most popular community operators. Its last release was in May 2023, and there have been no commits since 2024. Don't start new deployments on it, and plan a migration if you run it today.
Vitess
Vitess is a sharding layer for MySQL that started at YouTube and graduated from the CNCF in 2019. PlanetScale maintains its Kubernetes operator. If a single MySQL cluster can no longer hold your data or your write load, Vitess is the answer, and none of the operators above solves that. If you just need highly available MySQL with backups, it is far more than you need.
What about MariaDB?
MariaDB started as a MySQL fork but is now a separate database with its own features and replication. The mariadb-operator project is MIT-licensed, very active, and supports Galera, replication, and backups. If you run MariaDB, look there instead.
Which operator is right for you?
Pick the three priorities that matter most to your team, and we will rank the operators.
Selected 0 of 3.
Our ranking for your priorities
Verdicts
When each operator is the right choice, and when it isn't.
Percona XtraDB ClusterBest proven choice for synchronous HA
Choose it when:
- No committed transaction may be lost when a node fails
- You want the longest production track record of any MySQL operator
- You need point-in-time recovery that is generally available today
- You want PMM monitoring and enterprise support from a database company
- You are evaluating OpenEverest as a platform for several databases
Look elsewhere when:
- Your workload has very large transactions or tables without primary keys
- Writes are latency-sensitive and can't afford Galera's certification and flow control
- You want upstream MySQL replication rather than Galera
Percona Server for MySQLBest for new Group Replication deployments
Choose it when:
- You are starting fresh and want upstream Group Replication with an open source operator
- You want XtraBackup and PMM included, without paid add-ons
- You want enterprise support from a database company
- You can wait for point-in-time recovery to become generally available, or test it in staging now
Look elsewhere when:
- You need production-ready point-in-time recovery today
- You need asynchronous replication in production; it is still a tech preview
- You want years of production use behind the operator
Oracle MySQL OperatorBest for the official upstream path
Choose it when:
- You require the official operator from the company that owns MySQL
- You already have a MySQL Enterprise subscription, which adds Enterprise Backup and monitoring
- You want InnoDB Cluster and MySQL Router exactly as Oracle documents them
- You only want upstream MySQL Server binaries
Look elsewhere when:
- You need free physical backups or point-in-time recovery
- You want monitoring dashboards out of the box
- You want an open development process with pull requests on GitHub
- You want one platform for MySQL, PostgreSQL, and MongoDB
MOCOBest for lean, standard MySQL replication
Choose it when:
- You want standard MySQL semantics, without Group Replication or Galera restrictions
- You prefer a small, readable operator with no proxy layer
- You already have your own monitoring dashboards and operations tooling
- Your databases are small enough for logical backups and restores
Look elsewhere when:
- You need vendor support with SLAs
- You need fast physical restores for multi-terabyte databases
- You need cross-site or multi-cluster topologies
- You don't want to depend on a single company with no commercial backing
One platform instead of one operator
OpenEverest runs MySQL with either Percona operator: XtraDB Cluster or Percona Server with Group Replication. It also runs MariaDB with mariadb-operator, and PostgreSQL, MongoDB, and a growing list of other databases, all from the same control plane. Solanica adds enterprise support on top.
- One control plane. Manage every database from one API and UI, without operator sprawl.
- Apache 2.0. Use, modify, and distribute it freely.
- Any cloud, any cluster. EKS, GKE, AKS, on-prem, or edge, with the same platform everywhere.
- Enterprise support. 24/7 support from database engineers, with SLAs and escalation paths.
This comparison is written by Solanica. OpenEverest ships providers for both Percona MySQL operators. We scored every operator on documented features, including the ones we ship. Last updated October 2026.