PostgreSQL operators on Kubernetes: an honest comparison
Four active operators and their real trade-offs
Running PostgreSQL on Kubernetes means choosing an operator, and the wrong choice can cost you months.
We compared Percona, CloudNativePG, Zalando, and StackGres across features, community health, business viability, and day-2 operations. No vendor paid for placement on this page.
Crunchy Data PGO was a major player, but it is no longer actively developed. Crunchy Data was acquired by Snowflake in 2025, and the operator now only gets maintenance releases. It is mentioned where relevant but left out of the scored comparison.
The four operators
| Operator | Latest | License | Maintainer | Since | In short |
|---|---|---|---|---|---|
| Percona Operator | v3.1 | Apache 2.0 | Percona LLC | 2022 | Enterprise-grade operator built on the Crunchy PGO foundation. Part of Percona's ecosystem for MySQL, MongoDB, and PostgreSQL. |
| CloudNativePG | v1.30 | Apache 2.0 | CNCF Sandbox | 2022 | Started at EDB and donated to the community. Kubernetes-native from the ground up: no StatefulSets, its own pod controller, a Level V operator. |
| Zalando Operator | v2.0 | MIT | Zalando SE | 2017 | The original PostgreSQL operator, tested at Zalando's scale of thousands of clusters. Patroni-based HA with a lean scope that leaves monitoring and tuning to other tools. |
| StackGres | 1.19 | AGPL 3.0 | OnGres Inc | 2019 | A full-stack, opinionated PostgreSQL distribution with connection pooling, monitoring, logging, sharding, and a web console. |
Scores at a glance
Scores are out of 10 and based on documented features, not marketing claims. Pick an operator to highlight it.
| Dimension | Percona | CNPG | Zalando | StackGres |
|---|---|---|---|---|
| High availability | 9 | 10 | 8 | 8 |
| Backup and recovery | 9 | 8 | 6 | 8 |
| Day-2 operations | 8 | 9 | 6 | 9 |
| Community | 7 | 10 | 7 | 6 |
| Extensions | 7 | 6 | 5 | 9 |
| Monitoring | 9 | 7 | 5 | 9 |
Deep dive: what actually matters
Each section covers one dimension and how each operator handles it. Open a section to compare.
High availability and failoverHow fast does the system recover when things break?
Percona
- Patroni-based HA with a distributed consensus store (DCS)
- Automated failover with configurable timeouts
- Synchronous replication supported
- Cross-cluster standby with streaming replication
- pgBouncer included for connection pooling during failover
Production-proven HA with Patroni at the core. Failover in about 15–30 seconds.
CloudNativePG
- No external DCS: leader election through the Kubernetes API
- Quorum-based failover for extra safety
- Synchronous replication with configurable quorum
- Replica clusters across multiple Kubernetes clusters
- Delayed replicas for access to historical data
- HA replication slots with automatic synchronization
The most Kubernetes-native approach, with no StatefulSets and no external dependencies. Fastest failover, about 5–10 seconds.
Zalando
- Patroni-based HA, from the original Patroni operator
- Kubernetes endpoints or etcd as the DCS
- Tested at Zalando with 2,000+ clusters
- Synchronous replication configurable in the manifest
- No built-in cross-cluster replication
Reliable HA through Patroni, proven at massive scale, but less configurable than newer operators.
StackGres
- Patroni-based HA with the full Patroni configuration exposed
- Sync, async, and group replication modes
- Built-in Envoy proxy for connection routing during failover
- Cross-cluster support through standby clusters
Solid Patroni HA with useful extras such as Envoy routing and advanced replication modes.
Backup and recoveryCan you restore to any point in time, and how complex is the setup?
Percona
- pgBackRest, the gold standard for PostgreSQL backups
- Full, differential, and incremental backups
- Point-in-time recovery (PITR)
- S3, GCS, and Azure Blob storage
- PVC snapshots for fast cloning
- Backup encryption and retention policies
- Backups from a standby to reduce load on the primary
Best-in-class backups through pgBackRest, with every feature you would expect from enterprise PostgreSQL.
CloudNativePG
- Plugin architecture (CNPG-I) with pluggable backup providers
- Barman Cloud plugin (community supported)
- Volume snapshots for fast backup and restore
- WAL archiving to S3, GCS, or Azure
- PITR supported
- Backups from a standby
- Retention policies through recovery windows
A flexible plugin architecture. Barman Cloud works well, but pgBackRest is not native yet.
Zalando
- WAL-E or WAL-G for WAL archiving
- Base backups to S3
- PITR through WAL replay
- Clone from an existing cluster or an S3 backup
- No built-in backup scheduling UI
- No PVC snapshots
Functional but minimal. It needs more manual configuration than the alternatives and has no incremental backups.
StackGres
- WAL-G with automated lifecycle management
- Full and PITR recovery
- S3, GCS, and Azure Blob storage
- Backup scheduling through a CRD
- Backup retention policies
- Web console for backup management
Good automation through CRDs, and the web console makes backup management accessible.
Day-2 operationsUpgrades, scaling, vacuum, and repack: the work that matters at 3 AM.
Percona
- Rolling upgrades for minor versions
- Major version upgrades with in-place pg_upgrade or backup and restore
- Backwards-compatible operator upgrades
- Horizontal scaling by adding or removing replicas
- Cluster pause and resume
- Extension upgrades
Solid day-2 coverage. Major upgrades need planning but are well documented.
CloudNativePG
- Online and offline import, including major upgrades through logical replication
- Rolling updates for minor versions
- In-place offline major upgrades
- Dynamic scale up and down
- Cluster hibernation that stops all pods and keeps the PVCs
- Fencing to isolate misbehaving instances
- Declarative management of roles, databases, and extensions
The most declarative approach. Online import through logical replication is a standout for major upgrades.
Zalando
- Rolling updates for pod image changes
- Scaling through a manifest change
- Database and role provisioning in the manifest
- No built-in major version upgrade tooling
- No vacuum or repack automation
- Little lifecycle management beyond provisioning
Lean by design. Good for provisioning, but day-2 work often means external tools or manual steps.
StackGres
- DbOps CRD for declarative day-2 operations
- Automated minor and major version upgrades
- Vacuum, repack, and restart as CRD operations
- In-place or reduced-impact rollout strategies
- Security patches through container upgrades
- Web console for all operations
The DbOps CRD makes vacuum, repack, and upgrades declarative. The best day-2 automation of the four.
Monitoring and observabilityMetrics, logs, and dashboards out of the box, or bring your own?
Percona
- Percona Monitoring and Management (PMM) integration
- Query Analytics (QAN) for query-level insight
- Pre-built Grafana dashboards
- Prometheus exporter included
- PostgreSQL-specific advisors and checks
PMM is a complete monitoring solution, and Query Analytics alone is worth the setup.
CloudNativePG
- Prometheus-compatible metrics exporter on port 9187
- JSON-structured logging to stdout
- Custom metrics through a ConfigMap
- No bundled dashboards; the community provides them
- Works with any Prometheus and Grafana stack
A clean, standard approach. Metrics are exposed and you bring your own dashboards, with no lock-in on monitoring.
Zalando
- Monitoring sidecars, configured globally
- No built-in monitoring stack
- Designed for ZMON (Zalando's internal tool) or Prometheus
- Basic pod metrics through Kubernetes
- Logging through Patroni output
Deliberately out of scope. You are expected to bring your own observability stack.
StackGres
- Full observability stack included
- Prometheus postgres_exporter plus custom metrics
- Envoy proxy metrics for connection-level visibility
- FluentBit for distributed log collection
- OpenTelemetry Collector for metrics, logs, and traces
- Pre-built Grafana dashboards
- Web console with a cluster health overview
The most complete monitoring out of the box: FluentBit, OpenTelemetry, Envoy metrics, and Grafana together.
Extensions, pooling, and extrasPostGIS, sharding, connection pooling: what comes in the box?
Percona
- pgBouncer connection pooling built in
- Custom extension management through the custom resource
- PostGIS supported
- Percona Distribution includes common extensions
- No sharding support
- LDAP authentication supported
CloudNativePG
- Native PgBouncer pooler integration
- Declarative extension management
- Tablespace support, including temporary tablespaces
- No sharding support
- Plugin architecture (CNPG-I) for extensibility
- Declaratively managed foreign data wrappers
Zalando
- Connection pooling through external configuration
- Extensions loaded from the Spilo image
- No extension lifecycle management
- No sharding
- Database and role provisioning in the manifest
StackGres
- 150+ PostgreSQL extensions available
- Integrated PgBouncer connection pooling
- Sharding with Citus-based horizontal scaling
- Babelfish for T-SQL compatibility
- CDC streaming with Debezium
- Cluster profiles for production, testing, and development
Security and complianceTLS, encryption, RBAC, and audit logging: the non-negotiables.
Percona
- TLS for clients, replication, and backups
- cert-manager integration
- AES-256 backup encryption
- LDAP authentication
- Percona-certified container images with SBOMs
- Private registry support for air-gapped installs
CloudNativePG
- TLS by default, with generated or custom certificates
- cert-manager integration
- Client certificate authentication
- Signed images with SBOM and provenance attestations
- Distroless and UBI9 image options
- Pod Security Standards compliance
Zalando
- Configurable TLS
- Pod-level RBAC
- No built-in backup encryption
- Team-based access control in the manifest
- Community-maintained Spilo images
StackGres
- TLS for all connections
- Secret management integration
- Web console with authentication
- RBAC for cluster operations
- Container image security scanning
How the operators evolved
Who shipped what, and when. The bars show each project's active years. Select a point to see what shipped.
Select a point on the timeline to see what shipped.
Development velocity, 2025–2026
| Operator | Activity | Notes |
|---|---|---|
| CloudNativePG | Regular patch and minor releases, 100+ PRs a month | |
| Percona | Quarterly releases, steady cadence | |
| StackGres | Frequent, feature-rich releases | |
| Zalando | Picked up in 2026 with v2.0 and regular patch releases | |
| Crunchy Data PGO | Maintenance releases only |
Community health and business viability
An operator's features mean nothing if the project dies in two years. These are the signals that matter for a long-term bet.
| Percona | CloudNativePG | Zalando | StackGres | |
|---|---|---|---|---|
| Backed by | Percona LLC, founded 2006 | CNCF Sandbox project (Linux Foundation), started at EDB | Zalando SE, an e-commerce company | OnGres Inc, a PostgreSQL consultancy |
| Business model | Open source, plus paid support and managed services | Community project with support from several vendors | Internal tool, open-sourced, with no commercial offering | Open core (AGPL) with an enterprise license and support |
| License | Apache 2.0 | Apache 2.0 | MIT | AGPL 3.0, or a commercial license |
| Release cadence | About quarterly (7 releases in the last 18 months) | Patch releases every few weeks, minor releases every 3–4 months | Irregular: two releases in 2025, then v2.0 and three patches in 2026 | Regular, several releases a quarter |
| GitHub stars | About 390 | About 9,500 | About 5,200 | About 1,400 on the GitHub mirror (developed on GitLab) |
| Contributors | Mostly Percona employees; external PRs accepted | 60+ contributors from many companies | Zalando employees and community; there is a PR backlog | Mostly the OnGres team, with some community contributions |
| Commercial support | Percona; also part of OpenEverest and PMM | EDB and several consultancies | None official; community only | OnGres enterprise support and consulting |
PerconaStrong
Percona is a profitable database company with over 18 years of history. The operator is strategic to its business, powering its managed service and available in the OpenEverest platform, so the risk of abandonment is low. Community contributions are limited, though. This is mainly a corporate project.
Funded company, regular releases, enterprise support. Corporate-driven.
CloudNativePGExcellent
The strongest community story. CNCF governance means no single company can kill it, several vendors offer commercial support, and it has the most active development in the space. From a governance point of view, it is the safe long-term bet.
CNCF-governed, multi-vendor, most active repository, diverse contributors.
ZalandoWatch
The original operator, with massive real-world use. But Zalando is an e-commerce company, not a database company. The operator exists because Zalando needs it internally, and if that changes the project could stall. There is no official commercial support. Release activity picked up in 2026 with v2.0, but it still depends on one company. It works and is proven, so keep an eye on the signals.
Proven at scale, MIT license. Irregular releases, no commercial support. Depends on a single company.
StackGresGood
A small but focused team. StackGres is the company's main product, so OnGres is highly motivated to keep it competitive. The AGPL license is a concern for some organizations, and there is startup risk, but the team's PostgreSQL expertise is deep and its feature velocity is impressive.
Core product, enterprise support, active development. AGPL license, small company.
Crunchy Data PGO
Once a major player, with about 4,400 GitHub stars. After Snowflake acquired Crunchy Data in 2025, the operator stopped being actively developed. It still gets maintenance releases with dependency and image updates, but no new features. It is a reminder that even popular operators can stall when the backing company's strategy changes.
Which operator is right for you?
Pick the three priorities that matter most to your team, and we will rank the operators.
Selected 0 of 3.
Our ranking for your priorities
Verdicts
When each operator is the right choice, and when it isn't.
CloudNativePGBest overall Kubernetes-native choice
Choose it when:
- You want the most Kubernetes-native approach, with no external DCS and no StatefulSets
- Long-term project safety matters, and CNCF governance protects you
- You want everything declarative: roles, databases, extensions, and schemas
- You need distributed topologies across multiple Kubernetes clusters
- Clean architecture matters more to you than the most bundled features
Look elsewhere when:
- You need a web console for onboarding your team; there isn't one
- You want monitoring dashboards out of the box; you will build your own
- You need sharding or Babelfish, which are out of scope
- You also manage MySQL and MongoDB; CloudNativePG is PostgreSQL-only
Percona OperatorBest for multi-database enterprise teams
Choose it when:
- You run PostgreSQL along with MySQL or MongoDB on Kubernetes
- You want enterprise support with SLAs from a database company
- PMM's query analytics and advisors are valuable to you
- pgBackRest is a must-have for your backups
- You are evaluating OpenEverest as a unified database platform
Look elsewhere when:
- You prefer community-driven over corporate-driven governance
- You only run PostgreSQL and want the most Kubernetes-native design
- You want to avoid Patroni-based HA; CloudNativePG is the alternative
- A minimal footprint is the priority, since Percona's stack is heavier
StackGresBest batteries-included experience
Choose it when:
- You want everything in one package: monitoring, pooling, logging, backups, and a web console
- Day-2 operations as CRDs (DbOps) would change how your team works
- You need sharding with Citus or T-SQL compatibility with Babelfish
- 150+ extensions out of the box matter to you
- A web console would help your team adopt databases on Kubernetes
Look elsewhere when:
- AGPL licensing is a problem for your legal team
- You prefer minimalism; StackGres is opinionated and full-stack
- You are uncomfortable with the risk of a smaller company
- You want CNCF-level governance guarantees
Zalando OperatorBest for lean, proven, large-scale setups
Choose it when:
- You have run Patroni before and want the same model on Kubernetes
- An MIT license with no strings attached is important
- You already have your own monitoring, backup, and operations tooling
- Being proven at massive scale, with thousands of clusters, gives you confidence
- You only need the operator for provisioning and HA
Look elsewhere when:
- You need a supported, fast-moving project with frequent releases
- You require enterprise support or SLAs
- You want declarative day-2 operations such as upgrades, vacuum, and repack
- You need backup tooling beyond the WAL-G basics
- You are worried about depending on one company with no commercial backing
One platform instead of one operator
OpenEverest runs PostgreSQL with either CloudNativePG or the Percona operator, and runs MySQL, MongoDB, and a growing list of other databases from the same control plane. Solanica adds enterprise support on top.
- One control plane. Manage every database from one API and UI, without operator sprawl.
- Apache 2.0. Use, modify, and distribute it freely.
- Any cloud, any cluster. EKS, GKE, AKS, on-prem, or edge, with the same platform everywhere.
- Enterprise support. 24/7 support from database engineers, with SLAs and escalation paths.
This comparison is written by Solanica. OpenEverest ships providers for both CloudNativePG and the Percona operator. We scored every operator on documented features, including the ones we ship. Last updated October 2026.