PostgreSQL Kubernetes Operators Compared: CloudNativePG, Zalando, Crunchy PGO, Percona, StackGres and EDB

The short answer

For most new deployments, start with CloudNativePG. It is Apache 2.0, a CNCF Sandbox project, handles failover with its own instance manager rather than Patroni, and backs up to object storage or volume snapshots. Choose Zalando's operator if you want Patroni with an MIT-licensed operator and are comfortable pinning Spilo images yourself. Choose Crunchy PGO or Percona's operator, which is built on PGO, if you prefer pgBackRest and Patroni, and read the image terms first. StackGres suits teams that want a web console and the widest version range, under AGPLv3. EDB's operator is the CloudNativePG route with a commercial subscription and EDB Postgres Advanced Server.

This post compares operators for running PostgreSQL clusters. If the immediate problem is a Bitnami chart that no longer pulls its images, read alternatives to the Bitnami PostgreSQL Helm chart first; it covers the migration out of the chart.

PostgreSQL operators compared

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

CloudNativePG

CloudNativePG manages a Cluster resource and promotes a replica through its own instance manager when the primary fails, so there is no Patroni or etcd layer to operate. Backups go to object storage through the Barman Cloud Plugin, which replaced the built-in barmanObjectStore settings from 1.26, or to Kubernetes volume snapshots. Each minor line has a short life: 1.30.x was released on 29 June 2026 and reaches end of life around December 2026, so plan to upgrade the operator a few times a year. PostgreSQL 13 has been unsupported since 13 November 2025.

Best for: new clusters, teams that want a CNCF community project, and anyone who prefers fewer moving parts in the failover path.

Zalando postgres-operator

Zalando's operator manages a postgresql resource and runs each pod on Spilo, an image that bundles PostgreSQL, Patroni and WAL-G or WAL-E. The v2.0 line supports PostgreSQL 14 to 18 and v2.0.3 shipped on 2 October 2026. The Spilo project does not make regular releases or publish latest images, so pin the Spilo image that each operator release names and rebuild or update it on your own schedule.

Best for: teams that know Patroni and want a permissively licensed operator with a long production history.

Crunchy PGO

PGO manages a PostgresCluster resource, uses Patroni for failover and pgBackRest for backups, and supports PostgreSQL 14 to 18 in its 6.0 releases. The operator code is Apache 2.0. The container images are where to slow down: the README says images from the Crunchy Data Developer Portal fall under the Crunchy Data Developer Program terms, and those terms require a support subscription for production use at organisations with 50 or more employees and do not allow redistribution. Plan to buy that subscription, or build and host your own images.

Best for: teams that want pgBackRest and Patroni with a vendor behind the operator, and accept the image terms.

Percona Operator for PostgreSQL

Percona's operator is based on PGO, so its architecture is the same: Patroni for failover, pgBackRest for backups, and pgBouncer for pooling. The differences are in licensing and packaging. The operator is Apache 2.0 and its images are Percona's own builds. Version 3.0.0 moved the inherited Crunchy custom resources to Percona's own API group so the two operators can run side by side, and documents a migration path from Crunchy PGO. Version 3.1.0 added transparent data encryption with pg_tde on PostgreSQL 17 and 18, with HashiCorp Vault as the key provider. Percona tests 3.1.0 with its own distribution of PostgreSQL 14 to 18, and with community images including 19 as a tech preview. Operator 2.8.x has already reached end of life, so check the operator version as well as the database version.

Best for: teams that like PGO's design but want open images, or want data-at-rest encryption without a commercial PostgreSQL distribution.

StackGres

StackGres, from OnGres, bundles PostgreSQL with Patroni, WAL-G, PgBouncer, Envoy and a logging stack, and adds a web console. Patroni uses the Kubernetes API for leader election, so no separate etcd or Consul is needed. Its images are based on Red Hat's Universal Base Image. StackGres 1.19.3 ships PostgreSQL 12 to 18, plus Babelfish builds for SQL Server compatibility. The source is AGPLv3, and OnGres offers a commercial licence without the GPL clauses.

Best for: platform teams that want a full stack with a UI, and estates that still run PostgreSQL 12 or 13 and need an operator that ships them. Those versions are past community end of life, so an operator that ships them does not make them patched.

EDB Postgres AI for CloudNativePG Cluster

EDB's operator, formerly EDB Postgres for Kubernetes and before that Cloud Native PostgreSQL, is a fork based on CloudNativePG with its own API group. It adds EDB Postgres Advanced Server for Oracle compatibility and transparent data encryption, IBM Power and Linux on IBM Z support, cold backups with Kasten and Velero, and an annual long-term support release maintained for 18 months; 1.28 is the current LTS. It is licensed under the EDB End User License Agreement, and EDB states that a valid subscription is required for production use.

Best for: estates already on EDB Postgres Advanced Server, or that need a vendor-supported LTS cadence for the operator itself.

How to choose

• Licence and images first. The operator licence is rarely the constraint. The images are. Crunchy's image terms and EDB's subscription requirement are explicit; CloudNativePG, Zalando, Percona and StackGres attach no subscription requirement to their images in the terms we reviewed.
• Failover model. If your team already runs Patroni and trusts it, Zalando, PGO, Percona and StackGres keep that knowledge useful. If you would rather not run Patroni, CloudNativePG and EDB avoid it.
• Backup tool. pgBackRest (PGO, Percona), WAL-G (Zalando, StackGres) and Barman (CloudNativePG, EDB) all do point-in-time recovery. Choose the one your team can restore with under pressure, and test restores, not just backups. Our guide to PostgreSQL backup, recovery and high availability covers what to test.
• Operator upgrade cadence. CloudNativePG minor lines last about six months; EDB's LTS lines last 18. Every operator here expects you to upgrade it, separately from PostgreSQL.
• PostgreSQL version. Only StackGres ships 12 and 13. For the others, a cluster on 13 or older means a major upgrade as part of the move. The major version upgrade guide covers the methods.

Where OSSeva fits

OSSeva for PostgreSQL supports PostgreSQL wherever it runs, including Kubernetes, and ships patched, signed builds for 11, 12 and 13, and for 14 after 12 November 2026, as packages, tarballs and container images. OSSeva Operate includes 24/7 replication and failover monitoring, Patroni and DCS quorum monitoring, and point-in-time recovery testing. If you run one of the operators above, bring it to the discovery call: whether OSSeva's images and runbooks fit that operator is a question to answer for your cluster, not one to assume. PostgreSQL sits under one contract with MySQL, MariaDB, Redis, Valkey and Kafka, priced per cluster. Book a discovery call for a quote.

Frequently asked questions

What is the best PostgreSQL Kubernetes operator?

For most new deployments, CloudNativePG: Apache 2.0, CNCF Sandbox, built-in failover without Patroni, and object-storage backups. Zalando, Crunchy PGO, Percona and StackGres are strong Patroni-based alternatives, and EDB's operator suits estates that want a commercial subscription.

CloudNativePG vs Zalando: which should I choose?

CloudNativePG if you want failover without Patroni, frequent releases and the Barman Cloud Plugin. Zalando if you already know Patroni and Spilo, prefer WAL-G, and are happy to pin and maintain Spilo images.

CloudNativePG vs Crunchy PGO?

Both are Apache 2.0 code. PGO uses Patroni and pgBackRest; CloudNativePG uses its own instance manager and Barman. The deciding factor is often images: Crunchy's require a subscription for production use at organisations with 50 or more employees.

CloudNativePG vs Percona Operator for PostgreSQL?

Percona's operator is built on PGO, so the comparison is Patroni and pgBackRest against CloudNativePG's own failover and Barman. Percona adds open images, pg_tde encryption on 17 and 18, and a documented migration path from Crunchy PGO.

Is Crunchy PGO free to use?

The operator code is Apache 2.0. Crunchy's images fall under its Developer Program terms, which require a support subscription for production use at organisations with 50 or more employees.

Which PostgreSQL operators support PostgreSQL 13 or 12?

Of the six, StackGres ships 12 and 13. The others support 14 to 18. Both 12 and 13 are past community end of life, so running them still needs a source of patched builds.