MySQL Operators on Kubernetes:
The Honest Comparison
4 Active Operators. Different Replication Models. Real Trade-offs.
Running MySQL on Kubernetes is not "just pick an operator" — your choice of operator locks you into a replication model (Galera, Group Replication, semi-sync) that's hard to change later. We compared the Percona XtraDB Cluster Operator, Percona Server for MySQL Operator, Oracle MySQL Operator, and MOCO across HA, backups, day-2 ops, and community health. No vendor paid for placement on this page.
The longest-running production-grade MySQL operator. Galera-based synchronous multi-primary replication via Percona XtraDB Cluster. Battle-tested with deep Percona ecosystem integration (PMM, xtrabackup).
GitHub →Percona's newer operator. Built on upstream MySQL replication — supports both Group Replication (single/multi-primary) and classic async replication. The strategic future direction of Percona's MySQL-on-K8s stack.
GitHub →Official operator from Oracle. Uses InnoDB Cluster — Group Replication plus MySQL Router and MySQL Shell for automation. The "blessed path" if you want vendor-stock MySQL behavior with zero forks.
GitHub →Lean, Kubernetes-native operator built by Cybozu for their internal SaaS. Uses loss-less semi-sync replication — which Oracle has marked deprecated. Simple, focused, but its core replication model is fading from the upstream roadmap.
GitHub →The Radar View
Click an operator to highlight its strengths. Click a dimension to see the detailed breakdown below. Scores are based on documented features and real-world operational signals, not marketing claims.
Deep Dive: What Actually Matters
Each card unpacks a critical dimension. Click to expand and see how each operator handles it differently.
Replication Model & Topology This is the biggest decision — and it's locked in by your operator choice. ▾
- Galera — synchronous multi-primary replication
- All nodes accept writes (with conflict resolution at certify time)
- Cluster requires odd node count (typically 3, 5, 7) to avoid split-brain
- Cross-site replication via async streaming replicas
- HAProxy / ProxySQL for read/write splitting (included)
- Group Replication (single-primary or multi-primary mode)
- Plus classic async replication for standby/DR clusters
- HAProxy and MySQL Router both supported
- Cross-region read replicas via async streaming
- Choose your replication topology per workload
- InnoDB Cluster — Group Replication + MySQL Router + Shell
- Single-primary mode strongly recommended (multi-primary supported but discouraged)
- MySQL Router does read/write splitting automatically
- InnoDB ReplicaSet — alternative for async-only setups
- Cross-cluster async replication for DR
- Loss-less semi-synchronous replication (rpl_semi_sync_slave_enabled)
- Single primary; one or more replicas
- Custom controller handles failover (promote replica with most applied transactions)
- No multi-primary mode
- No Galera, no Group Replication
High Availability & Failover How fast does the system recover when things break? ▾
- Galera = synchronous — no data loss on node failure
- Automated failover via cluster reconfiguration (no leader to "elect")
- HAProxy/ProxySQL routes traffic away from failed nodes
- Auto-recovery and auto-rejoin for failed nodes
- SST (snapshot state transfer) for re-joining nodes
- Group Replication consensus-based failover
- Quorum-based — handles network partitions safely
- Orchestrator-style logic baked into operator for async replicas
- HAProxy and MySQL Router both supported
- Async standby clusters for DR
- Group Replication for primary cluster HA
- MySQL Router automatically updates routing on failover
- Quorum-based, handles partition safely
- InnoDB ClusterSet for cross-region DR
- Limited to GR's recovery and certification semantics
- Custom failover controller — promotes the most up-to-date semi-sync replica
- Cluster-aware, integrated with Kubernetes APIs (no external DCS)
- Configurable replica count (1, 3, or 5 nodes)
- Switchover and failover as CR operations
Backup & Recovery Can you restore to any point in time? How complex is setup? ▾
- Percona XtraBackup — the gold standard for hot MySQL backups
- Full + binlog backups
- Point-in-Time Recovery (PITR) via binlogs
- S3, GCS, Azure Blob storage supported
- Scheduled backups via CR (cron)
- Backup encryption at rest
- Percona XtraBackup integrated
- Full and incremental backups + encrypted
- PITR via binlog archiving
- S3, GCS, Azure Blob supported
- Scheduled backups via CR
- Restore to new cluster supported
- mysqldump and mysqlsh dump utility
- No xtrabackup — Oracle doesn't ship it
- MySQL Enterprise Backup (MEB) available, but requires commercial license
- Object storage (S3) supported via OCI Object Storage primarily
- PITR via binlogs (manual setup required)
- mysqldump-based logical backups
- Stored to object storage (S3, GCS)
- Scheduled backups via BackupPolicy CR
- PITR via binlog archiving
- No physical/hot backup integration
Day-2 Operations Upgrades, scaling, schema changes — the stuff that matters at 3 AM. ▾
- Rolling minor upgrades via image bump
- Major version upgrades (handled, but require careful planning)
- Horizontal scale (add/remove Galera nodes) declaratively
- Cluster pause/resume
- Online DDL via gh-ost / pt-online-schema-change (manual)
- TLS rotation supported
- Rolling upgrades for minor versions
- Horizontal scaling of GR cluster and async replicas
- Switchover via CR action
- Cluster pause/resume
- Online schema change tooling supported externally
- TLS rotation supported
- Rolling upgrades via MySQL Shell automation
- Scale-out via adding GR members (declarative)
- InnoDB Cluster lifecycle managed via MySQL Shell scripts
- Limited backup lifecycle CRDs
- Read replica scaling via Router configuration
- Rolling upgrades for minor versions
- Switchover and failover as MySQLCluster operations
- Replication user / clone-source automation
- Volume expansion supported
- No backup encryption / PITR UI
Monitoring & Observability Out-of-the-box metrics, query analytics, dashboards — or bring-your-own? ▾
- Percona Monitoring and Management (PMM) integration
- Query Analytics (QAN) — per-query insights
- Pre-built Grafana dashboards for MySQL and Galera
- Prometheus mysqld_exporter sidecar
- Pre-built advisors for MySQL tuning
- PMM integration (same as PXC)
- Query Analytics (QAN)
- Pre-built Grafana dashboards for GR and async replication
- Prometheus mysqld_exporter sidecar
- Replication lag monitoring built-in
- No built-in monitoring stack
- Prometheus mysqld_exporter can be added manually
- MySQL Enterprise Monitor — available with commercial license
- Performance Schema enabled by default
- No pre-built dashboards shipped
- Built-in Prometheus metrics endpoint on operator + MySQL pods
- mysqld_exporter included as sidecar
- Custom metrics on cluster state, replication lag, errors
- No bundled dashboards
- Designed to plug into existing Prometheus/Grafana
Security & Compliance TLS, encryption at rest, RBAC, audit logging — the non-negotiables. ▾
- TLS everywhere (client, replication, SST/IST)
- cert-manager integration
- Backup encryption (AES-256)
- LDAP authentication via Percona PAM plugin
- Percona-certified container images with SBOMs
- Private registry support (air-gapped)
- TLS everywhere (client, replication)
- cert-manager integration
- Backup encryption
- Percona Server auditing plugin available
- Distroless image options
- SBOMs and signed images
- Private registry support (air-gapped)
- TLS support (configurable)
- Native MySQL accounts and roles (no extra plugin)
- Audit plugin requires MySQL Enterprise Edition
- Transparent Data Encryption (TDE) requires Enterprise keyring plugins
- Official Oracle container images
- TLS for client and replication
- Secret management integration
- Kubernetes RBAC integration for operator
- No built-in audit logging
- Minimal, well-audited Go codebase
The Evolution Timeline
Who shipped what, and when? Hover over milestones to see the details. The most active projects ship the most often — and the dying ones tell their own story.
Current Development Velocity (2025-2026)
Community Health & Business Viability
An operator's features mean nothing if the project dies in 2 years. Here's what the signals look like for long-term bets — including who's behind it, how often they ship, and whether you can actually buy support.
The longest-running production-grade MySQL operator. Percona is a profitable, established database company with 18+ years of history. Low risk of abandonment. Caveat: Percona is now investing more heavily in the newer PS-MySQL operator — the PXC operator continues to receive maintenance and feature releases, but the strategic direction is shifting away from Galera over the medium term.
Percona's strategic bet on upstream MySQL replication primitives (Group Replication + async). Younger and less battle-tested than the PXC operator, but it's the project actively absorbing new investment. This is where Percona's future MySQL-on-K8s work is going. Strong choice if you're starting fresh in 2026 and want both GR and async-replica patterns.
The official Oracle operator — and "official" matters if you need vendor-blessed MySQL behavior or commercial MySQL Enterprise integration. But this is a side project relative to Oracle's primary push: MySQL HeatWave on OCI. PRs and issue triage move at Oracle pace (slow), and community contributions are minimal. Don't expect aggressive feature velocity. Don't expect it to disappear either.
Clean, well-engineered, Kubernetes-native operator — but built around loss-less semi-sync replication, which Oracle has flagged as deprecated in upstream MySQL. The whole foundation of MOCO's HA story is on a slow path to removal. Cybozu is a strong engineering company, but they're not a database vendor, and there's no commercial support path. Use it with eyes open.
One of the most popular community MySQL operators in 2019-2021, built on async replication and used heavily for WordPress-on-Kubernetes deployments. Presslabs was acquired and rebranded to Bitpoke, and the operator's development effectively stopped. The repo still exists but receives no meaningful updates. Even GitHub-star-heavy operators can die when the backing business pivots.
Effectively abandoned No new features github.com/bitpoke/mysql-operator →Vitess is a fundamentally different category — a sharding and horizontal-scaling layer on top of MySQL, originally built at YouTube and now CNCF-graduated. If your problem is "my single MySQL cluster can't fit my data anymore", Vitess is the right answer and no other operator on this page solves that. If your problem is "I need to run normal MySQL on Kubernetes with HA and backups", Vitess is massive overkill. It's a sharding platform, not a drop-in operator.
CNCF Graduated Different use case github.com/vitessio/vitess →Which Operator Is Right for You?
Pick what matters most to your team. We'll highlight the best fit.
Select your top 3 priorities:
The Honest Verdicts
No "it depends" cop-out. Here's when each operator is the right choice — and when it isn't.
- You're starting fresh in 2026 and want both Group Replication and async standby in one operator
- You need DR with cross-region async replicas alongside your sync HA cluster
- You want enterprise support from a database company with SLAs
- You want xtrabackup (gold-standard hot physical backups) and PMM (query analytics) included
- You're evaluating OpenEverest as a unified database platform
- You need a multi-primary cluster — go PXC for true Galera multi-master
- You're already operating PXC in production and have no compelling reason to migrate
- Your organization requires the official Oracle-blessed MySQL path
- You need a battle-tested operator with 5+ years of production scars — PS is newer
- You need synchronous multi-primary replication — every node can take writes
- You've operated Galera before and want the same model on Kubernetes
- Zero-data-loss HA via Galera certification semantics is non-negotiable
- You want the most production-proven MySQL operator (longest track record)
- You need enterprise support and a multi-database story (with OpenEverest)
- You want async replicas / DR clusters as first-class citizens — PS is better suited
- You're committed to upstream MySQL Group Replication patterns
- Your application can't tolerate Galera's flow control or write-set certification overhead
- You want to ride the Percona strategic roadmap — that's moving toward the PS operator
- You require the official, Oracle-blessed MySQL operator
- You're already a MySQL Enterprise / HeatWave customer and want consistency
- You want InnoDB Cluster (GR + Router + Shell) exactly as documented by Oracle
- You don't trust forks — only upstream MySQL Server bits
- Vendor support via Oracle is a hard requirement
- You need free hot physical backups (xtrabackup) — Oracle ships dumps only without paid MEB
- You want comprehensive monitoring out of the box (no PMM equivalent in the free path)
- You expect fast feature iteration or strong community velocity
- You need a multi-database operator (MySQL + Postgres + Mongo) under one platform
- You want a small, clean, Kubernetes-native operator with minimal surface area
- Semi-sync replication is a known and acceptable trade-off for your workload
- You already have your own backup tooling, monitoring, and operations stack
- You value a clean Go codebase you can read end-to-end
- You don't need enterprise vendor support
- You need long-term alignment with upstream MySQL — semi-sync is deprecated
- You want hot physical backups for multi-TB databases
- You need vendor support with SLAs
- You require multi-primary or sophisticated DR topologies
- You're worried about single-company dependency with no commercial backstop
Vitess is the right answer if (and only if) your problem is "my single MySQL cluster can't fit my data". It's a query proxy + sharding layer + control plane that lets you scale MySQL horizontally across thousands of shards, with online resharding. CNCF Graduated, used at YouTube, Slack, GitHub. It is not a drop-in MySQL operator — it's an application-aware sharding platform with its own SQL dialect surface and operational model. Use Vitess in addition to one of the operators above, when sharding is mandatory.
Was a great operator from 2018-2021. Today, it's a cautionary tale. Development effectively stopped after Presslabs rebranded to Bitpoke and pivoted away from the OSS operator business. Do not start new deployments on this operator. If you're already running it, plan a migration. Any of the four active operators above is a safer landing spot depending on your replication model.
Solanica + OpenEverest: The Operator Problem, Solved
OpenEverest wraps Percona's MySQL operators into a unified control plane — giving you MySQL (PXC and PS), PostgreSQL, and MongoDB on any Kubernetes cluster with a single management interface, enterprise support, and no operator sprawl.
