Percona Operators for MySQL, PostgreSQL, and MongoDB Compared

Percona's Kubernetes operators for MySQL, PostgreSQL, and MongoDB are often evaluated as one product family, but they are four projects at different stages. There are two MySQL operators. The Group Replication one reached GA only in November 2025, and in release 1.3.0 its async replication, point-in-time recovery, and incremental backups are still tech preview. The PostgreSQL operator jumped to 3.0.0 in May 2026 as a hard fork of Crunchy Data's PGO, moving the inherited CRDs to a new API group, upstream.pgv2.percona.com, so 2.x runbooks need review. This guide compares the four on failover, proxies, backups and PITR, upgrades, TLS, PMM, licence, and maturity, and against the vendor alternatives.

Scope and review date: November 2026. Covers Percona Operator for MySQL based on Percona XtraDB Cluster 1.20.0 and based on Percona Server for MySQL 1.3.0, Percona Operator for PostgreSQL 3.1.0, and Percona Operator for MongoDB 1.23.1, plus CloudNativePG, MongoDB Controllers for Kubernetes, and Oracle's MySQL Operator. Versions, fields, and commands were checked against vendor documentation, release notes, and repositories on 9 November 2026, not run in a lab. Test them on a non-production cluster.

Which Percona Operators exist, and which versions are current?

There are four operators. Each installs its own custom resource definitions (CRDs) and watches its own custom resource (CR) kind. The table lists the latest release of each from Percona's release notes as of November 2026.

Sources: release notes for XtraDB Cluster 1.20.0, Percona Server 1.3.0 (GA for Group Replication since 1.0.0, 17 November 2025), PostgreSQL 3.1.0, and MongoDB 1.23.1.

# Which Percona operators are already installed in this Kubernetes cluster?
kubectl get crd -o name | grep -E 'percona\.com'

Interpretation: the groups pxc.percona.com, ps.percona.com, pgv2.percona.com, and psmdb.percona.com show which operators are present. After a PostgreSQL operator upgrade from 2.x, the renamed upstream.pgv2.percona.com CRDs sit next to the legacy ones.

Percona Everest, the web console for these operators, is no longer a Percona product. In January 2026 Percona moved it into an independent project, OpenEverest, developed by its subsidiary Solanica. Percona's MongoDB operator docs call it a CNCF Sandbox project and an optional install method. Everything in this post works through plain CRs.

How do the Percona Operators for MySQL, PostgreSQL, and MongoDB compare?

This card uses the XtraDB Cluster operator for MySQL; the next section compares the two MySQL operators.

Which MySQL operator should you pick: XtraDB Cluster or Group Replication?

Percona ships two MySQL operators with different replication engines. The XtraDB Cluster operator architecture uses Galera, which the docs describe as "virtually synchronous multi-primary replication": a commit returns only after the write set reaches all nodes and passes certification. The Percona Server operator runs MySQL Group Replication, or asynchronous replication managed by Orchestrator as a tech preview.

The default CRs show the difference in practice. Both excerpts come from each operator's deploy/cr.yaml at the current release tag.

# XtraDB Cluster operator 1.20.0: deploy/cr.yaml (excerpt)
apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBCluster
spec:
  crVersion: 1.20.0
  pxc:
    size: 3
  haproxy:
    enabled: true
    size: 3
  proxysql:
    enabled: false

Interpretation: HAProxy is on and ProxySQL is off by default. Enable only one of them. HAProxy sends writes to one node through the cluster1-haproxy Service, and reads can use cluster1-haproxy-replicas. Pod anti-affinity is required by default, so three PXC Pods need three schedulable Kubernetes nodes.

# Percona Server operator 1.3.0: deploy/cr.yaml (excerpt)
apiVersion: ps.percona.com/v1
kind: PerconaServerMySQL
spec:
  crVersion: 1.3.0
  mysql:
    clusterType: group-replication   # "async" is tech preview
    size: 3
  proxy:
    haproxy:
      enabled: true
    router:
      enabled: false                 # Group Replication only
  orchestrator:
    enabled: false                   # used by async clusters

Interpretation: the default is Group Replication behind HAProxy. Release 1.3.0 can switch replication type on a running cluster, but that feature is also tech preview, so pick the type at creation.

How do failover and the proxy layer work in each operator?

No operator adds its own consensus layer. Each delegates failover to the engine or a bundled tool, then points a Service or proxy at the new primary.

• XtraDB Cluster: every Galera node holds the full data set. When the writer fails, HAProxy or ProxySQL picks another node as the single writer.
• Percona Server: Group Replication's membership protocol elects a new primary. In async clusters, Orchestrator promotes a replica, and release 1.3.0 recovers missing binary log transactions before it promotes one.
• PostgreSQL: Patroni coordinates leader election and updates its endpoints on failover. The cluster1-primary Service follows the leader, and PgBouncer (cluster1-pgbouncer) sits in front.
• MongoDB: the replica set holds an election. Drivers find the new primary themselves; sharded clusters route through mongos.

# PostgreSQL operator 3.1.0: deploy/cr.yaml (excerpt; patroni block shown with its defaults)
apiVersion: pgv2.percona.com/v2
kind: PerconaPGCluster
spec:
  crVersion: 3.1.0
  postgresVersion: 18
  instances:
  - name: instance1
    replicas: 3
  proxy:
    pgBouncer:
      replicas: 3
  patroni:
    syncPeriodSeconds: 10           # default: 10
    leaderLeaseDurationSeconds: 30  # default: 30

Interpretation: three PostgreSQL instances (one primary and two replicas) and three PgBouncer Pods are the defaults. The cr.yaml comments say the Patroni container's probe timings are derived from these two values. Lowering them speeds up failure detection but makes a short network pause more likely to trigger a failover.

# MongoDB operator 1.23.1: deploy/cr.yaml (excerpt)
apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDB
spec:
  crVersion: 1.23.1
  replsets:
  - name: rs0
    size: 3
  sharding:
    enabled: true
    configsvrReplSet:
      size: 3
    mongos:
      size: 3

Interpretation: the sample CR enables sharding with three config servers and three mongos routers. For an unsharded replica set, set sharding.enabled: false. Clients then connect with the connection string the operator writes to a Secret, and no proxy sits in the path.

How do backups and point-in-time recovery work in each operator?

All four operators take on-demand or scheduled backups through a CR and write them to object storage outside the Kubernetes cluster. PITR adds a continuous log stream on top of a full backup: binary logs, WAL, or the oplog.

MySQL: the binlog collector

In the XtraDB Cluster operator, enabling PITR starts a separate Pod that uploads binary logs to backup storage. The PITR documentation says to use S3-compatible or Azure-compatible storage for both the binlogs and the full backup, and that PITR does not work with other storage types.

# XtraDB Cluster operator: deploy/cr.yaml
spec:
  backup:
    pitr:
      enabled: true
      storageName: s3-us-west      # must match a name under backup.storages
      timeBetweenUploads: 60       # seconds between binlog uploads

Interpretation: timeBetweenUploads limits how much recent history a restore can reach if the whole Kubernetes cluster is lost. The collector exposes pxc_binlog_collector_* metrics on the cluster1-pitr Service, so alert on them.

PostgreSQL: pgBackRest and WAL

The PostgreSQL operator runs pgBackRest with up to four repositories and full, differential, or incremental backups, and takes an initial full backup when it creates a cluster. A point-in-time restore replays archived WAL on top of the latest full backup that finished before the target.

# deploy/restore.yaml: in-place point-in-time restore
apiVersion: pgv2.percona.com/v2
kind: PerconaPGRestore
metadata:
  name: restore1
spec:
  pgCluster: cluster1
  repoName: repo1
  options:
  - --type=time
  - --target="2026-11-03 10:15:00+00"

# The newest time a restore can safely target
kubectl get pg-backup <backup_name> -n <namespace> \
  -o jsonpath='{.status.latestRestorableTime}'

Interpretation: target a time at or before latestRestorableTime. It advances only when archived WAL contains commits, so on an idle test cluster, make a small write and wait for the next WAL switch (archive_timeout, 60 seconds by default). See our pgBackRest guide for the tool itself.

MongoDB: oplog slices

The MongoDB operator runs Percona Backup for MongoDB (PBM) as a sidecar. Logical and physical full backups are GA. Physical incremental backups (from 1.20.0) and PVC snapshot backups (from 1.23.0) are tech preview, and PVC snapshot backups do not support PITR.

# MongoDB operator: deploy/cr.yaml
spec:
  backup:
    pitr:
      enabled: true
      # oplogSpanMin: 10   # default upload interval, in minutes

Interpretation: per the MongoDB operator's PITR page, the first oplog slice arrives after one interval, about 10 minutes by default. Check status.latestRestorableTime on a psmdb-backup object, as for PostgreSQL above: empty means nothing has been uploaded yet.

How do upgrades work, and what does Smart Update do?

An upgrade has three layers: the CRDs, the operator deployment, and the database images. Upgrade them in that order. The XtraDB Cluster, Percona Server, and MongoDB operators support updateStrategy: SmartUpdate, the default in their sample CRs. The XtraDB Cluster update guide says Smart Update "restarts Pods in a specific order, with the primary instance updated last". The alternatives are RollingUpdate, run by the StatefulSet controller, and OnDelete, where you delete each Pod yourself.

# XtraDB Cluster operator 1.20.0: deploy/cr.yaml
spec:
  updateStrategy: SmartUpdate
  upgradeOptions:
    versionServiceEndpoint: https://check.percona.com
    apply: disabled          # or Recommended, Latest, 8.0-recommended, an exact version
    schedule: "0 4 * * *"

Interpretation: with apply: disabled, nothing changes until you edit the image. Recommended moves the cluster to the version service's recommended minor version on the schedule, without a change ticket, which suits staging better than production. The MongoDB operator's CR has the same block.

PostgreSQL minor and major upgrades

The PostgreSQL operator's docs don't use the term Smart Update. A minor upgrade is a kubectl patch pg that sets the new crVersion and image tags from the certified images list. The minor upgrade guide warns it can cause downtime and a failover when the primary restarts. It also warns that a base image change can change glibc or ICU collations, which means reindexing text indexes.

Major upgrades have been GA since operator 2.9.0 and use a separate resource. The major upgrade guide says the whole cluster is shut down for the upgrade, data is duplicated on each PVC, and pgaudit must be dropped and recreated in each database afterwards.

# deploy/upgrade.yaml
apiVersion: pgv2.percona.com/v2
kind: PerconaPGUpgrade
metadata:
  name: cluster1-17-to-18
spec:
  postgresClusterName: cluster1
  image: docker.io/percona/percona-distribution-postgresql-upgrade:<tag>
  fromPostgresVersion: 17
  toPostgresVersion: 18
  toPostgresImage: docker.io/percona/percona-distribution-postgresql:<tag>
  toPgBouncerImage: docker.io/percona/percona-pgbouncer:<tag>
  toPgBackRestImage: docker.io/percona/percona-pgbackrest:<tag>

Interpretation: if the upgrade fails, the cluster stays paused and starts on the old version when you resume it. Check PVC free space first, because the old data stays until you delete it.

How do TLS and PMM monitoring differ between the operators?

By default, each operator generates its own TLS certificates if you supply none, and those are not renewed automatically. Each can instead use cert-manager for short-lived, automatically renewed certificates, or take certificates you supply in Secrets. In the XtraDB Cluster operator, HAProxy passes the TLS handshake through to the PXC node, so clients behind HAProxy verify against the internal certificate's CA. The external certificate applies only with ProxySQL. The MongoDB operator controls TLS with a mode setting.

# MongoDB operator: deploy/cr.yaml
spec:
  tls:
    mode: requireTLS   # default is preferTLS: TLS internally, plain client connections still accepted

Interpretation: the MongoDB operator's TLS page lists allowTLS, preferTLS (default), requireTLS, and disabled. Move to requireTLS only after every client connects with TLS.

Monitoring uses Percona Monitoring and Management (PMM). Each CR has the same pmm block, and the PMM Client runs as a sidecar in every database Pod. PMM3 authenticates with a Grafana service account token. The Secret key name differs by operator, which trips up teams that copy one operator's setup to another.

# Same block in all four sample CRs (disabled by default)
spec:
  pmm:
    enabled: true
    serverHost: monitoring-service

# XtraDB Cluster operator: token goes in the cluster Secret
#   cluster1-secrets  ->  pmmservertoken: <token>
# PostgreSQL operator: token goes in a dedicated Secret
#   cluster1-pmm-secret  ->  PMM_SERVER_TOKEN: <token>

Interpretation: upgrade PMM Server before the PMM Client images. The PostgreSQL operator has dropped PMM2, and the XtraDB Cluster operator will drop it in 1.22.0, so a PMM2 server is a blocker to clear first. Our PMM setup guide covers the server side.

How do Percona Operators compare with CloudNativePG, MCK, and Oracle's MySQL Operator?

Each engine also has a strong alternative operator. The choice is mostly about which tooling you want to run and who you buy support from.

Sources: the CloudNativePG repository (its backup docs deprecate the in-core object store integration from 1.26), the MCK repository, and the MySQL Operator backup manual. MongoDB's old Community Operator repository is archived, and its best-effort support ended in November 2025.

In practice: CloudNativePG suits teams that want a Kubernetes-native design without Patroni, MCK suits MongoDB Enterprise Advanced customers, and the Percona operators suit teams that want one vendor's tooling (XtraBackup, pgBackRest, PBM, PMM) across all three engines.

How do you evaluate and pilot a Percona Operator?

A pilot should prove four things on your own platform: the cluster deploys, a backup restores to a point in time, the application tolerates a failover, and an upgrade completes. First compare your Kubernetes version with the tested platforms in the release notes.

Frequently asked questions

Key takeaways

Run Percona Operators in production with JusDB

JusDB's MySQL on Kubernetes team can help you choose between the XtraDB Cluster and Percona Server operators, review your CRs, and plan a pilot with restore, failover, and upgrade drills. For other engines, see our PostgreSQL on Kubernetes and MongoDB on Kubernetes pages.

Bring your Kubernetes platform and version, your target database versions, your backup storage, and your recovery requirements. Your team approves every production change.

Related reading

• pgBackRest: Enterprise PostgreSQL Backup and Recovery
• MySQL Group Replication vs Galera Cluster: A 2025 Comparison
• Percona Monitoring and Management (PMM): Full Setup Guide
• Percona documentation: Percona Operator for PostgreSQL architecture