MySQL Kubernetes Operators Compared: Oracle MySQL Operator, Percona, Vitess and mariadb-operator

The short answer

Pick the operator that matches the replication model you want. For InnoDB Cluster with MySQL Router, from the MySQL team itself, use Oracle's MySQL Operator for Kubernetes. For Galera-style synchronous clustering, use Percona's Operator for MySQL based on Percona XtraDB Cluster. For group replication on Percona Server, use Percona's newer Operator for MySQL. For horizontal sharding across many MySQL instances, use the Vitess operator. For MariaDB, with Galera or asynchronous replication, use mariadb-operator, and check the MaxScale licence before you rely on it in production.

Each operator ties you to a particular server build and topology, so the choice is also a choice of database distribution.

MySQL operators compared

Checked against each project's own repository and documentation on 7 October 2026.

Oracle MySQL Operator for Kubernetes

Built by the MySQL team at Oracle, the operator manages an InnoDBCluster resource: a set of MySQL server instances in Group Replication plus MySQL Router instances that send clients to the current primary. A minimal cluster is three servers and one router. Backups are defined as profiles that use MySQL Shell's dumpInstance() or volume snapshots, stored on a persistent volume claim, in OCI Object Storage, S3 or Azure Blob Storage. The custom resource also has fields for MySQL Enterprise Backup and the enterprise server edition, which need Oracle's commercial licence. The operator is released under the Universal Permissive License, its version tags follow the MySQL release they ship with, and bugs are tracked at bugs.mysql.com.

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mycluster
spec:
  secretName: mypwds
  tlsUseSelfSigned: true
  instances: 3
  router:
    instances: 1

Best for: teams that want stock MySQL Community Edition in the topology Oracle documents and supports, and an upgrade path that tracks MySQL LTS releases.

Percona Operator for MySQL based on Percona XtraDB Cluster

This is the longer-established Percona operator. It runs Percona XtraDB Cluster, a Galera-based synchronously replicated MySQL, with HAProxy or ProxySQL in front. Backups are physical, taken with Percona XtraBackup either from a separate backup pod using a state snapshot transfer or from a sidecar in each database pod. Release 1.20.0 is tested with PXC 8.0.45 and 5.7.44, with 8.4.8 as a tech preview. Note that MySQL 8.0 and 5.7 are both past Oracle's end of life, so the 8.4 line matters here.

Best for: teams that want every node writable and synchronous replication, and are comfortable with Galera's trade-offs for write-heavy workloads.

Percona Operator for MySQL (Percona Server)

The newer Percona operator runs Percona Server for MySQL. Group replication, with HAProxy or MySQL Router, has been GA since 1.0.0. The asynchronous replication mode, managed by Orchestrator, is still a tech preview, and Percona does not recommend it for production yet. Release 1.2.0 is tested with Percona Server 8.4.10 and 8.0.46.

Best for: teams that want group replication with Percona's tooling and images. Stick to the group replication cluster type in production.

Vitess Operator

Vitess is a CNCF graduated project and a clustering system for horizontal scaling of MySQL; it was a core part of YouTube's database infrastructure from 2011. It shards data across many MySQL instances and routes queries through its own layer, so applications see one logical database. PlanetScale's Vitess Operator, Apache 2.0, manages a VitessCluster resource. Each operator minor release pairs with one Vitess major release and follows its one-year life, so the operator and Vitess are upgraded together.

Best for: datasets or write volumes that have outgrown one primary. For a single database that fits on one server, Vitess adds more machinery than it removes.

mariadb-operator

mariadb-operator is an MIT-licensed community project that runs MariaDB with asynchronous replication or Galera multi-primary clustering, and can put MaxScale in front for load balancing, failover and switchover. Backups are flexible: physical with mariadb-backup or Kubernetes VolumeSnapshots, logical with mariadb-dump, to S3-compatible storage, Azure Blob Storage or volumes, with scheduling, retention, and restore of the backup closest to a target time. It supports MariaDB Community 10.6 and later. MariaDB also sells a separate MariaDB Enterprise Operator.

One licensing detail deserves attention. MaxScale is not open source: MaxScale 24.08 is under the Business Source License, which allows free production use only when an application uses it with fewer than three server instances, and converts to GPLv2 on 9 September 2027. A three-node Galera cluster behind MaxScale may well exceed that grant, so read the terms and either license MaxScale or use the operator's Galera and replication support without it.

Best for: MariaDB estates, especially Galera clusters, that want a well-featured open source operator.

How to choose

• Server distribution. Oracle's operator runs MySQL Community or Enterprise; the Percona operators run Percona Server or PXC; mariadb-operator runs MariaDB. Moving a cluster between them is a migration, not an operator swap.
• Replication model. Group Replication and InnoDB Cluster (Oracle, Percona Server), Galera (PXC, MariaDB), or sharding (Vitess). Choose the model first and the operator follows.
• Version support. MySQL 8.0 reached end of life in April 2026, and 5.7 in 2023. Check that the operator you choose is tested with 8.4 and has a path to 9.7. Our MySQL 8.0 to 8.4 upgrade guide covers the database side.
• Proxy licence. MySQL Router, HAProxy and ProxySQL are open source; MaxScale is under the Business Source License.
• Coming from the Bitnami chart. The Bitnami mysql chart's replication variables have no equivalent in the official image, and an operator replaces that replication logic rather than reusing it. Our Bitnami MySQL alternative page covers what changes.

Where OSSeva fits

OSSeva for MySQL supports MySQL Community Edition 8.4 and 9.7 LTS, and ships patched, signed 5.7 and 8.0 builds after Oracle's end of life. OSSeva Assure includes a review of replication, Group Replication and InnoDB Cluster topologies, and OSSeva Operate covers 24/7 replication, failover and backup monitoring with rolling upgrades replica by replica. OSSeva for MariaDB covers Galera Cluster review and monitoring. Coverage is for MySQL Community and MariaDB servers; if you run Percona Server, PXC or Vitess, or rely on a particular operator, raise it on the discovery call rather than assuming it is covered. MySQL and MariaDB sit under one contract with PostgreSQL, Redis, Valkey and Kafka, priced per cluster. Book a discovery call for a quote.

Frequently asked questions

What is the best MySQL Kubernetes operator?

It depends on the topology. Oracle's MySQL Operator for InnoDB Cluster with stock MySQL, Percona's XtraDB Cluster operator for Galera-style clustering, Percona's Operator for MySQL for group replication on Percona Server, and Vitess for sharding.

Is the Oracle MySQL Operator free?

Yes. It is released under the Universal Permissive License and runs MySQL Community Edition. Fields for MySQL Enterprise Backup and the enterprise edition need Oracle's commercial licence.

Percona MySQL operator: which of the two should I use?

The XtraDB Cluster operator for Galera-based synchronous clusters, or the Operator for MySQL for group replication on Percona Server. Avoid the Operator for MySQL's asynchronous mode in production while it remains a tech preview.

Which MySQL versions does the Oracle operator run?

Its tags pair a MySQL release with an operator version, such as 9.7.0-2.2.8 and 26.7.0-2.3.0. Check the tag list for the LTS release you want before deploying, and start new clusters on 8.4 LTS or later, since 8.0 is past end of life.

Is there a Kubernetes operator for MariaDB?

Yes. mariadb-operator is an MIT-licensed community operator for MariaDB 10.6 and later, with replication, Galera and MaxScale support. MariaDB also sells an enterprise operator.

Do I need Vitess to run MySQL on Kubernetes?

No. Vitess is for horizontal sharding. A single MySQL cluster with replicas is better served by one of the other operators.