Percona Operators

Four free Kubernetes operators from Percona that run its builds of MySQL, PostgreSQL and MongoDB, each using the engine’s own replication and backup tools.

What it is: Relational databases,Container orchestration
Type: Open source
Made by: Percona
License: Apache 2.0 (operators). The databases they deploy keep their own licences: Percona Server for MongoDB is source-available under the SSPL
Facts checked: 6 October 2026

What it is

Percona has sold support for open-source databases since 2006 and publishes its own free builds of them: Percona Server for MySQL, Percona XtraDB Cluster, Percona Server for MongoDB and Percona Distribution for PostgreSQL, plus tools such as Percona XtraBackup and Percona Monitoring and Management (PMM). Its operators run those builds on Kubernetes. There is one per engine, each with its own custom resource and release cycle. The Operator for MySQL based on Percona XtraDB Cluster runs Galera synchronous replication, where every node takes writes and every write is confirmed by all nodes, so Percona recommends three to five nodes and an odd number; HAProxy or ProxySQL sits in front. The Operator for MySQL based on Percona Server runs MySQL Group Replication behind HAProxy or MySQL Router (generally available since 1.0.0 in November 2025), with asynchronous replication managed by Orchestrator still a tech preview.

The Operator for PostgreSQL is based on Crunchy Data’s PGO, so it uses Patroni for failover, pgBackRest for backups and PgBouncer for pooling; version 3.0 (May 2026) moved PGO’s resources to Percona’s own API group so the two operators can run side by side, and Percona documents a migration from PGO. The Operator for MongoDB runs replica sets and sharded clusters and backs them up with Percona Backup for MongoDB, whose agent runs beside each mongod and supports physical, incremental and snapshot backups with point-in-time recovery. The XtraDB Cluster operator backs up with XtraBackup to S3, Azure, Google Cloud Storage or a volume, and can upload binary logs every minute or so for point-in-time recovery. All four are Apache 2.0, Percona charges no licence fees for them or its images, and PMM can monitor them through a sidecar. Percona Everest, its web console on top of the operators, became the independent OpenEverest project in January 2026 and joined the CNCF Sandbox that March.

Why teams pick it

One vendor and one style of operator across MySQL, PostgreSQL and MongoDB, with Apache 2.0 code and no licence fees for the images, unlike Crunchy’s PGO images
Each operator builds on the engine’s own machinery: Galera or Group Replication, Patroni, MongoDB replica sets and sharding, and XtraBackup, pgBackRest or Percona Backup for MongoDB
Monitoring through PMM, and a web console (OpenEverest) for teams who want self-service databases without writing YAML
A documented path from Crunchy’s PGO, since the PostgreSQL operator shares its design

Watch out for

Four separate operators with different resources, release cycles and maturity: the Percona Server for MySQL operator only reached GA in late 2025, and its asynchronous mode is still a tech preview
They deploy Percona’s distributions rather than upstream images, and Percona Server for MongoDB inherits MongoDB’s source-available SSPL licence
XtraDB Cluster’s synchronous replication adds latency to every write, and Percona advises against more than five nodes because each one adds more
The operators are steered by one company and aren’t in a foundation; only the OpenEverest console has moved to the CNCF

Alternatives

What all relational databases have in common →

Alibaba Cloud PolarDBCommercialAlibaba Cloud’s cloud-native relational databases: MySQL- and PostgreSQL-compatible clusters whose compute nodes share one copy of the data on distributed storage, plus PolarDB-X, a distributed MySQL-compatible edition.

CedarDBCommercialA PostgreSQL-compatible database rebuilt from scratch at TU Munich, running transactions and analytics on one copy of the data on a single server.

Cloudflare D1CommercialCloudflare’s serverless SQL database that speaks SQLite, runs each database inside a Durable Object, and bills by rows read and written rather than by the hour.

CloudNativePGOpen sourceA Kubernetes operator that runs highly available PostgreSQL with no Patroni and no StatefulSets: the Kubernetes API itself holds the cluster’s state.

CockroachDBCommercialA distributed SQL database that speaks the PostgreSQL wire protocol, replicates every slice of data with Raft and keeps transactions serializable across nodes and regions.

MySQLOpen sourceThe long-standing open-source SQL database behind much of the web, built on the InnoDB engine.

NeonCommercialServerless Postgres that keeps data in a shared storage layer, so compute can scale to zero and a branch of the database is a pointer, not a copy.

PatroniOpen sourceA Python agent beside each Postgres server that elects one primary through etcd, Consul, ZooKeeper or Kubernetes, and fails over when it dies.

PGO (Crunchy Postgres for Kubernetes)Open sourceCrunchy Data’s Postgres operator: Patroni in every pod for failover, pgBackRest for backups, and a declarative `PostgresCluster` resource on top.

PlanetScaleCommercialManaged MySQL on Vitess and managed Postgres, with schema changes shipped through branches and deploy requests.

PostgreSQLOpen sourceThe open-source relational database that most new projects start on, extensible enough to grow into many niches.

ScramDBCommercialA brand-new, closed-source database that speaks the PostgreSQL protocol and promises transactions, analytics and vector search on one copy of the data; first builds shipped in summer 2026.

SQLiteOpen sourceA complete SQL database in a library and a single file, with no server to run.

TursoOpen sourceA from-scratch Rust rewrite of SQLite with concurrent writes, plus libSQL (an open-contribution SQLite fork) and Turso Cloud, which hosts many small databases on S3.

VitessOpen sourceA proxy layer, born at YouTube, that shards MySQL across many servers while the app still sees one database.

How it fits with other technologies

What Percona Operators uses

What uses Percona Operators

pgBackRestbacks up Postgres clusters run byPercona OperatorsBackup & restore

A three-node Percona XtraDB Cluster behind HAProxy, with nightly XtraBackup backups and binlog uploads to S3 · yaml

apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBCluster
metadata:
  name: cluster1
spec:
  crVersion: 1.20.0
  secretsName: cluster1-secrets
  pxc:
    size: 3                    # Galera: use an odd number, 3 to 5
    volumeSpec:
      persistentVolumeClaim:
        resources:
          requests:
            storage: 50G
  haproxy:
    enabled: true
    size: 3
  backup:
    pitr:
      enabled: true
      storageName: s3-eu
      timeBetweenUploads: 60   # seconds between binlog uploads
    storages:
      s3-eu:
        type: s3
        s3:
          bucket: acme-mysql-backups
          credentialsSecret: cluster1-backup-s3
          region: eu-central-1
    schedule:
      - name: daily-backup
        schedule: "0 0 * * *"
        retention:
          type: count
          count: 5
          deleteFromStorage: true
        storageName: s3-eu

See it in a real stack

No architecture uses Percona Operators yet. Drop it into the playground and wire it up yourself.Open playground →

Worth exploring

Article· November 2024Kubernetes for databases: weighing the pros and consKate Obiidykhata, Percona, on the CNCF blog (first published on The New Stack)A short, high-level overview of why companies move databases onto Kubernetes (one platform across clouds and data centres, self-service, scaling, built-in failover) and the three ways to get there: a cloud DBaaS, a private DBaaS product, or an internal platform built from operators and monitoring. There is no technical depth or data. It is a CNCF member post by a Percona employee and ends by recommending Percona Everest, so read it as a vendor’s framing of the choice.

All resources →

Where it came from2006–2026

Peter Zaitsev and Vadim Tkachenko started Percona in 2006 to support MySQL. It went on to publish its own open builds and tools: XtraBackup for hot MySQL backups in 2009, Percona Server for MySQL in 2010, Percona XtraDB Cluster in 2012, Percona Server for MongoDB in 2015, and PostgreSQL support from 2018. Its business is support and services, so the software itself stays free.

As customers moved applications to Kubernetes, they wanted the databases there too. In 2019 Percona launched its Kubernetes operators: version 1.0.0 of the XtraDB Cluster and MongoDB operators both shipped on May 29, 2019. A PostgreSQL operator followed in 2021, built on Crunchy Data’s open-source PGO instead of from scratch, and an operator for Percona Server for MySQL with Group Replication, started the same year, reached general availability in November 2025.

By 2024 Percona was promoting Everest, a web console that provisions databases through these operators on any Kubernetes cluster. In January 2026 Percona handed it to an independent, multi-vendor project called OpenEverest, which the CNCF accepted into its Sandbox on March 15, 2026. That May the PostgreSQL operator’s 3.0 release renamed the resources it had inherited from PGO, so Percona’s and Crunchy’s operators can share a cluster and users can migrate between them.

Why it’s built this way

One operator per database engine: MySQL, PostgreSQL and MongoDB replicate and fail over in very different ways, so each operator wraps the engine’s own mechanism (Galera, Group Replication, Patroni, replica sets) instead of forcing one model on all three.
Build the PostgreSQL operator on PGO: Crunchy’s Apache-licensed operator already combined Patroni and pgBackRest, so Percona reused it and later renamed the inherited APIs to avoid clashing with PGO.
Back up with each engine’s own tool: XtraBackup, pgBackRest and Percona Backup for MongoDB already handle consistent physical backups and point-in-time recovery, and Percona maintains two of them.
Free images as well as free code: Percona makes money from support and services, and markets the operators as having no licence fees or lock-in, in contrast to vendors that restrict their production images.

Timeline

2006
Percona founded to support MySQL
2009
Percona XtraBackup launched
2019
XtraDB Cluster and MongoDB operators reach 1.0.0 on May 29
2021
Operator for PostgreSQL launched, based on Crunchy’s PGO
2025
Operator for Percona Server for MySQL reaches GA with Group Replication
2026
Everest becomes OpenEverest and joins the CNCF Sandbox; PostgreSQL operator 3.0

Sources18 · facts checked 6 October 2026

Improve this page on GitHub