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.

What CNMSQL does not do​

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

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​