Skip to main content

MySQL operators for Kubernetes compared (2026)

· 9 min read
Tristan Smagghe
Tristan Smagghe
CNMSQL maintainer

To run MySQL on Kubernetes you usually pick an operator: a controller that provisions the database, keeps replication healthy, fails over when the primary dies and takes backups. Several are actively maintained, and they differ in which MySQL they run, how they stay available and how far back you can restore.

We maintain CNMSQL, so we are not neutral. Every fact below comes from each project's own documentation, listed under Sources, and there is a full section on what CNMSQL cannot do. If something is wrong or out of date, open an issue.

The short version​

  • A vendor-maintained operator with a GA release: one of Percona's two operators. One runs Percona XtraDB Cluster (Galera), the other runs Percona Server with Group Replication.
  • Oracle MySQL, InnoDB Cluster or the Enterprise edition: Oracle's MySQL Operator.
  • More writes than one primary can take: Vitess.
  • MariaDB with Galera or MaxScale: mariadb-operator.
  • Plain semi-sync replication, no proxy: MOCO or CNMSQL.
  • One platform for many database engines: KubeDB (commercial) or KubeBlocks (AGPL-3.0).
  • CloudNativePG-style operations for MySQL: CNMSQL. It offers continuous binlog archiving with point-in-time recovery to a time or a GTID, and one API for Percona Server and MariaDB. It is four months old, so read what it does not do first.

Feature comparison​

Checked on 16 October 2026. Numbers in the table refer to the notes under it.

  • Supported
  • Partial, with caveats, or tech preview
  • Not supported
  • Not found in the docs we checked

Scroll sideways to see every project.

MySQL operators for Kubernetes: feature comparison
FeatureCNMSQLPercona XtraDB Cluster operatorPercona Server operatorOracle MySQL OperatorMOCOVitess Operatormariadb-operatorKubeDBKubeBlocks
Project
LicenseApache-2.0Apache-2.0Apache-2.0UPL 1.0Apache-2.0Apache-2.0MITCommercial1AGPL-3.0
Latest release0.8.0 (Sep 2026)21.20.0 (Jun 2026)1.2.0 (Jul 2026)26.7.0-2.3.0 (Jul 2026)0.37.0 (Sep 2026)2.17.1 (Sep 2026)26.10.1 (Sep 2026)v2026.10.121.0.2 (Feb 2026)
Database engines
MySQLPercona Server 8.0, 8.4Percona XtraDB Cluster 5.7, 8.0, 8.4Percona Server 8.0, 8.4MySQL 8.4, 9.7, 26.7MySQL 8.0, 8.4MySQL, through Vitess 24MariaDB onlyYesMySQL 5.7, 8.0, 8.4
MariaDB10.11, 11.4, 12.3NoNoNoNoNo10.6 and laterSeparate resourceSeparate addon
High availability
Async or semi-sync, with failoverAsync or semi-syncGalera insteadAsync, tech preview3Group Replication onlySemi-sync, up to 5 instancesFailover by VTOrcAsyncSemi-syncYes
Group ReplicationSingle-primary4NoGAInnoDB ClusterNoNoNot in MariaDBAlso InnoDB ClusterYes
GaleraNoYes5NoNoNoNoYesSeparate resourcesNot documented
ShardingNoNoNoNoNoYesNoNoNo
Standby cluster in another regionPlanned6Multi-site replicationGroup Replication only (1.2.0)Not documentedReplicates from an external MySQLZones in one Kubernetes cluster7Multi-cluster replicationRemote replicaNot documented
Client routing
Native routingRead-write, read-only and any-instance Services8Proxy by default9Not documentedThrough MySQL RouterPrimary and replica Services8Through vtgatePrimary and secondary ServicesNot documentedNot documented
ProxyNoHAProxy or ProxySQLHAProxy or MySQL RouterMySQL RouterNovtgateMaxScale, optionalNot documentedNot documented
Connection poolingNoWith ProxySQLNot documented10Not documented10Novttablet poolsNot documentedNot documentedNot documented
Backup and recovery
Physical backupsXtraBackup or mariadb-backupXtraBackupXtraBackup, incremental, encryptedLogical dumps onlyLogical dumps onlyBuiltin or XtraBackup enginemariadb-backup, volume snapshotsNot documentedXtraBackup
Logical backupsmysqldump or mariadb-dumpXtraBackup onlyXtraBackup onlyMySQL Shell dumpMySQL Shell dumpMySQL Shell engine, experimentalmariadb-dumpThrough KubeStashmydumper
Backup storageS3-compatible only11S3-compatible, Azure, volumeS3-compatible, GCS, AzureS3, Azure, OCI, volumeS3-compatible, GCS, AzureS3, GCS, Ceph, fileS3-compatible, Azure, volumeS3, GCS, Azure, volumeS3, GCS, Azure and others
Point-in-time recoveryTo a time or a GTID12Yes13Tech previewNot documentedUp to the last backup run14To a time or a GTIDSince 26.3.0Continuous archivingNot documented
Day-2 operations
Declarative users and databasesDatabase and DatabaseUser resourcesUsers in the cluster resource (1.16+)15System users onlyNot documentedOperator accounts onlyKeyspaces and vtgate usersUser, Grant and Database resourcesNot documentedNot documented
In-place major version upgrade8.0 to 8.416Only minor upgrades documentedOnly minor upgrades documentedNot documentedRolling, one instance at a timeNot documentedNot documentedUpdateVersion requestNot documented
  1. Free only for databases created and destroyed within 30 days, such as dev or CI clusters. Production use needs a paid license.
  2. First release (0.1.0) on 18 June 2026. The API is still v1alpha1, and the repository lists three contributors.
  3. Percona labels asynchronous replication a tech preview and does not recommend it for production.
  4. MySQL 8.0.22 and later. Multi-primary mode is rejected, and a running cluster cannot switch between async replication and Group Replication.
  5. Galera needs primary keys and InnoDB tables, and large or conflicting transactions can fail certification. Commits wait for the cluster.
  6. The spec.replica field exists in the API, but the operator rejects it today. Cross-region recovery means restoring from the object store.
  7. The operator documentation describes replicating across availability zones within one Kubernetes cluster.
  8. Clients connect straight to the database Pod, with no extra hop. The application picks the read-write or read-only Service itself and reconnects after a failover.
  9. HAProxy is the default. The operator can also expose the XtraDB Cluster Pods directly.
  10. MySQL Router 8.4 can share and reuse server connections. We did not find an operator setting that turns it on.
  11. Any S3-compatible store, including AWS S3, MinIO, Ceph RGW, Cloudflare R2 and Backblaze B2. GCS works through its S3 interoperability API with HMAC keys. Azure Blob Storage and volumes are not supported.
  12. Binary logs are archived continuously to S3-compatible storage. Recovery cannot bring back transactions that were never archived and are missing from the new primary.
  13. A dedicated Pod uploads binary logs to S3-compatible or Azure storage at a configurable interval.
  14. Binary logs are collected at each backup run, not streamed. If the whole cluster is lost, up to one backup interval of writes can be lost.
  15. Users and grants are declared in the users section of the cluster resource. Removing a user from the resource does not drop it from the database.
  16. One series at a time, with a rolling restart and a switchover. MariaDB follows 10.11, 11.4, 12.3. Downgrades are not supported.

What CNMSQL does not do​

Some of these are on the roadmap. Others are design choices.

AreaLimitation
MaturityFirst release in June 2026. The API is v1alpha1 and can change between minor releases; read the upgrade notes before every upgrade.
ScaleNo sharding and no multi-primary writes. One primary takes every write.
Disaster recoveryNo standby cluster in another region yet. Cross-region recovery means restoring from the object store.
Backup storageS3-compatible object storage only. GCS works through its S3 interoperability API; Azure Blob Storage and volumes are not supported.
RoutingNo proxy. Applications choose between Kubernetes Services. There is no read/write splitting or connection pooling.
EnginesPercona Server 8.0 and 8.4 only for MySQL. No Oracle MySQL images, no 5.7. On MariaDB: no Galera or Group Replication.
Changes in placeA cluster cannot switch between async replication and Group Replication, or between MySQL and MariaDB. Downgrades are not supported.
RecoveryGroup Replication quorum loss needs a human to run kubectl cnmsql group recover. A diverged replica is re-initialized by hand, which discards its data.
Dependenciescert-manager is required. No NetworkPolicy examples ship yet.

Details: Group Replication, Replication and failover, Point-in-time recovery, MariaDB flavor.

The other options, in brief​

Percona XtraDB Cluster operator​

The longest-running operator in this list (since 2018). It runs Galera-based synchronous replication behind HAProxy or ProxySQL.

  • Pick it if: you want a mature vendor operator, still run 5.7, or need synchronous replication.
  • Watch out for: Galera's rules on primary keys and large transactions, and the extra commit latency.

Percona Server operator​

Percona's operator for standard Percona Server. Group Replication has been GA since 1.0.0 (November 2025), and 1.2.0 added cross-site replication and encrypted backups.

  • Pick it if: you want Group Replication with a vendor behind it.
  • Watch out for: async replication and point-in-time recovery are still tech previews.

Oracle MySQL Operator​

Runs InnoDB Cluster (Group Replication plus MySQL Router) on Oracle's Community or Enterprise images.

  • Pick it if: you are standardized on Oracle MySQL or need the Enterprise edition.
  • Watch out for: backups are logical dumps only, point-in-time recovery is not documented, and only one cluster-wide operator can be installed.

MOCO​

Cybozu's operator for GTID semi-sync replication on MySQL 8.0 and 8.4, up to five instances. It does not do Group Replication by design.

  • Pick it if: you want plain MySQL replication from a small, focused operator.
  • Watch out for: binlogs are collected at backup time, not streamed, and old backups are not deleted for you.

Vitess Operator​

Runs Vitess, a CNCF graduated project that shards MySQL behind the vtgate proxy.

  • Pick it if: one primary cannot keep up with your writes or data size.
  • Watch out for: more components to run, and SQL limits on sharded keyspaces such as no CREATE PROCEDURE through Vitess and no unique auto_increment across shards.

mariadb-operator​

MariaDB only, with async replication or Galera, optional MaxScale, and point-in-time recovery since 26.3.0.

  • Pick it if: you run MariaDB and want Galera or MaxScale.
  • Compared with CNMSQL on MariaDB: CNMSQL has neither Galera nor MaxScale. It makes sense for MariaDB only if you want one operator for MariaDB and Percona Server.

KubeDB​

AppsCode's commercial platform for many engines. For MySQL it supports Group Replication, InnoDB Cluster, semi-sync and remote replicas.

  • Pick it if: you want one supported product across many databases.
  • Watch out for: a paid license is needed for anything that lives longer than 30 days.

KubeBlocks​

ApeCloud's multi-engine platform. Its MySQL addon supports replication, Group Replication and Orchestrator topologies on 5.7, 8.0 and 8.4.

  • Pick it if: you want one platform for several engines.
  • Watch out for: the AGPL-3.0 license, which some organizations do not allow.

Inactive projects​

Bitpoke mysql-operator (last release May 2023) and RadonDB MySQL Kubernetes (last release November 2024) are not archived, but we would not start a new deployment on either.

Managed services​

If the database does not have to run inside your cluster, Amazon RDS, Google Cloud SQL or Azure Database for MySQL remove the need for an operator, at the cost of price, provider lock-in and control over versions.

How to choose​

  1. Engine. Oracle MySQL, Percona Server, Percona XtraDB Cluster or MariaDB? This alone rules out several options.
  2. Write scale. If one primary cannot keep up, look at Vitess.
  3. Disaster recovery. Need a standby in another region today? Look at the Percona operators, mariadb-operator or KubeDB.
  4. Data loss. Compare the point-in-time recovery row, and check whether it is GA or a tech preview.
  5. Proxy or not. A proxy adds read/write splitting and one more component to run.
  6. License. AGPL-3.0 (KubeBlocks) and commercial (KubeDB) need sign-off in many companies.
  7. Maturity. GA vendor operators, community projects with years of releases, and pre-1.0 projects like CNMSQL carry different levels of risk.

Where CNMSQL fits​

CNMSQL applies the design of CloudNativePG to MySQL: an instance manager in each Pod, failover decided by the operator with leases and fencing, and Kubernetes Services instead of a proxy. On top of the features in the table, it has a namespaced install mode, HPA and VPA support, and slim rootless images.

If the limitations above don't rule it out, the quickstart gets a three-instance cluster running in a few minutes. Issues and pull requests are welcome on GitHub.

Sources​

Every source, checked on 16 October 2026

Release dates come from each project's GitHub releases page unless a source below gives one.