$ kubectl get operators --sort-by=.metadata.creationTimestamp
PostgreSQL Operators on Kubernetes:
The Honest Comparison
4 Active Operators. No Marketing Fluff. 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.
CrunchyData PGO was a major player but is no longer actively developed as an open-source project. It's mentioned where relevant but excluded from the active comparison.
🐘
Percona Operator v2.9.0
Enterprise-grade operator built on top of Crunchy's PGO foundation. Part of the broader Percona ecosystem covering MySQL, MongoDB, and PostgreSQL.
Docs →☁️
CloudNativePG v1.29
Born at EDB, donated to the community. CNCF Sandbox project. Kubernetes-native from the ground up — no StatefulSets, custom pod controller, Level V operator.
Docs →🦩
Zalando Operator v1.13+
The OG PostgreSQL operator. Battle-tested at Zalando scale (thousands of clusters). Patroni-based HA. Lean scope — delegates monitoring and tuning to external tools.
Docs →🏔️
StackGres latest
Full-stack PostgreSQL distribution. Opinionated — ships with connection pooling, monitoring, logging, sharding, and a web console. "Enterprise Postgres made easy."
Docs →↓ Scroll to explore the comparison
$ helm test --compare-all
The Radar View
Click an operator to highlight its strengths. Click a dimension to see the detailed breakdown below. Scores are based on documented features, not marketing claims.
Percona
CloudNativePG
Zalando
StackGres
High Availability
Backup & Recovery
Day-2 Operations
Community & Governance
Extensions & Ecosystem
Monitoring & Observability
$ kubectl describe operators --verbose
Deep Dive: What Actually Matters
Each card unpacks a critical dimension. Click to expand and see how each operator handles it differently.
High Availability & Failover How fast does the system recover when things break?▾
High Availability & Failover How fast does the system recover when things break?
Percona
- Patroni-based HA with DCS (distributed consensus storage)
- 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 ~15-30s.
CloudNativePG
- No external DCS needed — uses Kubernetes API directly for leader election
- Quorum-based failover for enhanced safety
- Synchronous replication with configurable quorum
- Replica clusters across multiple K8s clusters (distributed topology)
- Delayed replicas for point-in-time access to historical data
- HA replication slots with automatic synchronization
Most K8s-native approach. No StatefulSets, no external deps. Fastest failover (~5-10s).
Zalando
- Patroni-based HA — the original Patroni operator
- Uses Kubernetes endpoints as DCS (or etcd)
- Battle-tested at Zalando (2000+ clusters)
- Synchronous replication configurable via manifest
- No built-in cross-cluster replication
Reliable HA via Patroni. Proven at massive scale, but less configurable than newer operators.
StackGres
- Patroni-based HA with full Patroni configuration exposed
- Sync, async, and group replication modes
- Built-in Envoy proxy for connection routing during failover
- Cross-cluster support via standby clusters
Solid Patroni HA with nice extras (Envoy routing). Advanced replication modes available.
Backup & Recovery Can you restore to any point in time? How complex is setup?▾
Backup & Recovery Can you restore to any point in time? How complex is setup?
Percona
- pgBackRest — the gold standard for PostgreSQL backups
- Full, differential, and incremental backups
- Point-in-Time Recovery (PITR)
- S3, GCS, Azure Blob storage supported
- PVC snapshots for fast cloning
- Backup encryption and retention policies
- Backup from standby to reduce primary load
Best-in-class backup via pgBackRest. Every feature you'd expect from enterprise PostgreSQL.
CloudNativePG
- Plugin architecture (CNPG-I) — pluggable backup providers
- Barman Cloud plugin (community supported)
- Volume snapshots for fast backup/restore
- WAL archiving to object stores (S3, GCS, Azure)
- PITR supported
- Backup from standby
- Retention policies via recovery windows
Flexible plugin architecture. Barman Cloud works well, but pgBackRest not native (yet).
Zalando
- WAL-E / WAL-G for WAL archiving
- Basebackups to S3
- PITR via WAL replay
- Clone from existing cluster or S3 backup
- No built-in backup scheduling UI
- No PVC snapshots
Functional but minimal. Requires more manual configuration than alternatives. No incremental backups.
StackGres
- WAL-G with automated lifecycle management
- Full and PITR recovery
- S3, GCS, Azure Blob supported
- Automated backup scheduling via CRD
- Backup retention policies
- Web console for backup management
Good automation through CRDs. Web console makes backup management accessible.
Day-2 Operations Upgrades, scaling, vacuum, repack — the stuff that matters at 3 AM.▾
Day-2 Operations Upgrades, scaling, vacuum, repack — the stuff that matters at 3 AM.
Percona
- Minor version rolling upgrades
- Major version upgrade (pg_upgrade in-place or via backup/restore)
- Operator upgrade with backwards compatibility
- Horizontal scaling (add/remove replicas)
- Cluster pause/resume
- Extension upgrades
Solid day-2 coverage. Major upgrades require planning but are well-documented.
CloudNativePG
- Online and offline import (including major upgrades via logical replication)
- Rolling updates for minor versions
- In-place offline major upgrades
- Scale up/down dynamically
- Cluster hibernation (stop all pods, keep PVCs)
- Fencing (isolate misbehaving instances)
- Declarative role/database/extension management
Most declarative approach. Online import via logical replication is a killer feature for major upgrades.
Zalando
- Rolling updates for pod image changes
- Scaling via manifest change
- Database and role provisioning via manifest
- No built-in major version upgrade tooling
- No vacuum or repack automation
- Minimal lifecycle management beyond provisioning
Lean scope by design. Good for provisioning, but day-2 often means external tooling or manual work.
StackGres
- DbOps CRD — declarative day-2 operations
- Automated minor and major version upgrades
- Automated vacuum, repack, restart as CRD operations
- Rollout strategy (in-place or reduced-impact)
- Security patches via container upgrades
- Web console for all operations
The DbOps CRD is genius. Vacuum, repack, upgrades all declarative. Best day-2 automation.
Monitoring & Observability Out-of-the-box metrics, logs, and dashboards — or bring-your-own?▾
Monitoring & Observability Out-of-the-box metrics, logs, and dashboards — or bring-your-own?
Percona
- Percona Monitoring and Management (PMM) integration
- Query Analytics (QAN) — deep query-level insights
- Pre-built Grafana dashboards
- Prometheus exporter included
- PostgreSQL-specific advisors and checks
PMM is a complete monitoring solution. Query Analytics alone is worth the setup.
CloudNativePG
- Prometheus-compatible metrics exporter (port 9187)
- JSON-structured logging to stdout
- Custom metrics via ConfigMap
- No bundled dashboards (community provides them)
- Integrates with any Prometheus/Grafana stack
Clean, standard approach. Metrics exposed, you bring your own dashboards. No vendor lock-in on monitoring.
Zalando
- Sidecars for monitoring (configurable globally)
- No built-in monitoring stack
- Designed to work with ZMON (Zalando's internal tool) or Prometheus
- Basic pod metrics via Kubernetes
- Logging via Patroni output
Deliberately out of scope. You're expected to bring your own observability stack entirely.
StackGres
- Full observability stack included
- Prometheus postgres_exporter + custom metrics
- Envoy proxy metrics (connection-level visibility)
- FluentBit for distributed log collection
- OTEL Collector for metrics, logs, traces
- Pre-built Grafana dashboards
- Web console with cluster health overview
Most batteries-included monitoring. FluentBit + OTEL + Envoy metrics + Grafana = full picture out of the box.
Extensions, Pooling & Extras PostGIS? Sharding? Connection pooling? What comes in the box?▾
Extensions, Pooling & Extras PostGIS? Sharding? Connection pooling? What comes in the box?
Percona
- pgBouncer for connection pooling (built-in)
- Custom extensions management via CR
- PostGIS supported
- Percona Distribution includes common extensions
- No sharding support
- LDAP authentication supported
CloudNativePG
- PgBouncer connection pooler (native integration)
- Declarative extension management
- Tablespace support (including temporary)
- No sharding support
- Plugin architecture (CNPG-I) for extensibility
- Foreign Data Wrappers declaratively managed
Zalando
- Connection pooling via external configuration
- Extensions loaded from Spilo image
- No extension lifecycle management
- No sharding
- Database and role provisioning via manifest
StackGres
- 150+ PostgreSQL extensions available
- PgBouncer for connection pooling (integrated)
- Sharding support (Citus-based horizontal scaling)
- Babelfish for T-SQL compatibility
- CDC streaming with Debezium
- Cluster profiles (production, testing, development)
Security & Compliance TLS, encryption at rest, RBAC, audit logging — the non-negotiables.▾
Security & Compliance TLS, encryption at rest, RBAC, audit logging — the non-negotiables.
Percona
- TLS everywhere (client, replication, backup)
- cert-manager integration
- Backup encryption (AES-256)
- LDAP authentication
- Percona-certified container images with SBOMs
- Private registry support (air-gapped)
CloudNativePG
- TLS by default (auto-generated or custom certs)
- cert-manager integration
- Client certificate authentication
- Signed images with SBOM and provenance attestations
- Distroless and UBI9 image options
- Pod security standards compliance
Zalando
- TLS support (configurable)
- Pod-level RBAC
- No built-in backup encryption
- Team-based access control via manifest
- Spilo images (community-maintained)
StackGres
- TLS for all connections
- Secret management integration
- Web console with authentication
- RBAC for cluster operations
- Container image security scanning
$ git log --all --oneline --graph
The Evolution Timeline
Who shipped what, and when? Hover over milestones to see the details. The most active projects push the most commits.
2017 2018 2019 2020 2021 2022 2023 2024 2025 2026
Zalando
StackGres
Percona
CloudNativePG
CrunchyData PGO
⚠️ No longer actively developed
Current Development Velocity (2025-2026)
CloudNativePGMonthly releases, 100+ PRs/month
PerconaQuarterly releases, steady cadence
StackGresFrequent releases, feature-rich updates
ZalandoInfrequent, maintenance-focused
CrunchyData PGOEffectively dormant
$ gh repo stats --compare
Community Health & Business Viability
An operator's features mean nothing if the project dies in 2 years. Here's what the signals look like for long-term bets.
Percona Operator Strong
Backing Company Percona LLC (est. 2006)
Business Model Open-source + paid support & managed services
License Apache 2.0
Release Cadence ~quarterly (8 releases in last 18 months)
GitHub Stars ~700+
Contributors Mostly Percona employees; external PRs accepted
Ecosystem Part of OpenEverest (multi-DB platform) + PMM monitoring
Analysis
Percona is a profitable, established database company with 18+ years of history. The operator is strategic to their business (powers their managed service and OpenEverest platform). Low risk of abandonment. However, community contributions are limited — this is primarily a corporate project.
Funded company Regular releases Enterprise support Corporate-driven
CloudNativePG Excellent
Governance CNCF Sandbox project (Linux Foundation)
Origin Built by EDB, donated to community
License Apache 2.0
Release Cadence Monthly patches, minor releases every 3-4 months
GitHub Stars ~5,000+
Contributors 60+ contributors; diverse company representation
Commercial Support EDB, multiple consultancies
Analysis
The strongest community story. CNCF governance means no single company can kill it. Multiple vendors provide commercial support. Most active development velocity in the space. The safe long-term bet from a governance perspective.
CNCF governed Multi-vendor Most active repo Diverse contributors
Zalando Operator Watch
Backing Company Zalando SE (e-commerce)
Business Model Internal tool open-sourced; no commercial offering
License MIT
Release Cadence Irregular (~2-3 per year, sometimes gaps)
GitHub Stars ~4,300+
Contributors Mix of Zalando employees + community; PR backlog exists
Commercial Support None official; community-only
Analysis
The OG operator with massive real-world usage. But: Zalando is an e-commerce company, not a database company. The operator exists because Zalando needs it internally — if they change strategy, the project could stagnate. No official commercial support available. PR merge velocity has slowed. Still functional and battle-tested, but watch the signals.
Battle-tested at scale MIT license Irregular releases No commercial support Single-company dependent
StackGres Good
Backing Company OnGres Inc (PostgreSQL consultancy)
Business Model Open-core (AGPL) + enterprise license + support
License AGPL 3.0 (free) / Commercial license available
Release Cadence Regular (multiple releases per quarter)
GitLab Stars ~1,200+ (hosted on GitLab)
Contributors Primarily OnGres team; some community contributions
Commercial Support OnGres provides enterprise support + consulting
Analysis
Small but focused team. StackGres is the company's primary product — they are highly motivated to keep it alive and competitive. The AGPL license is a consideration for some organizations. Startup risk exists, but their PostgreSQL expertise is deep and the feature velocity is impressive.
Core product Enterprise support Active development AGPL license Small company
CrunchyData PGO (formerly postgres-operator)
Was a major player (GitHub stars: ~3,900+). CrunchyData shifted focus to their commercial product (Crunchy Bridge) and effectively stopped open-source development. The operator still works but receives no meaningful updates. This is the cautionary tale: even popular operators can be abandoned when the backing company's strategy changes.
Effectively abandoned No new features$ solanica recommend --interactive
Which Operator Is Right for You?
Pick what matters most to your team. We'll highlight the best fit.
Select your top 3 priorities:
$ solanica verdict --honest
The Honest Verdicts
No "it depends" cop-out. Here's when each operator is the right choice — and when it isn't.
CloudNativePG Best Overall K8s-Native Choice
✓ Choose CNPG when:
- You want the most Kubernetes-native approach (no external DCS, no StatefulSets)
- Long-term project safety matters — CNCF governance protects you
- You value declarative everything: roles, databases, extensions, schemas
- You need distributed topologies across multiple K8s clusters
- Clean architecture > maximum bundled features
✗ Don't choose CNPG when:
- You need a web console for team onboarding — there isn't one
- You want out-of-the-box monitoring dashboards — you'll build your own
- You need sharding or Babelfish — not in scope
- You manage MySQL and MongoDB too — CNPG is PostgreSQL-only
Percona Operator Best for Multi-DB Enterprise Teams
✓ Choose Percona when:
- You run PostgreSQL and MySQL and/or MongoDB on Kubernetes
- You want enterprise support with SLAs from a database company
- PMM (Percona Monitoring) is valuable — query analytics, advisors
- pgBackRest (gold-standard backup tool) is non-negotiable
- You're evaluating OpenEverest as a unified database platform
✗ Don't choose Percona when:
- You prefer community-driven governance over corporate-driven
- You only run PostgreSQL and want maximum K8s-native design
- You want to avoid any Patroni-based HA (CNPG is the alternative)
- Minimal footprint is the priority — Percona's stack is heavier
StackGres Best Batteries-Included Experience
✓ Choose StackGres when:
- You want everything in one package: monitoring, pooling, logging, backups, web console
- Day-2 operations as CRDs (DbOps) is a game-changer for your team
- You need sharding (Citus) or Babelfish (T-SQL) compatibility
- 150+ extensions out of the box matters
- A web console helps your team adopt Kubernetes databases
✗ Don't choose StackGres when:
- AGPL licensing is a problem for your legal team
- You prefer minimalism — StackGres is opinionated and full-stack
- You're uncomfortable with smaller-company risk (OnGres)
- You want CNCF-level governance guarantees
Zalando Operator Best for Lean, Proven, Large-Scale
✓ Choose Zalando when:
- You've run Patroni before and want the same model on Kubernetes
- MIT license with no strings attached is important
- You have your own monitoring, backup, and operations tooling already
- Proven at massive scale (thousands of clusters) gives you confidence
- You don't need the operator to do everything — just provisioning and HA
✗ Don't choose Zalando when:
- You need a supported, actively-evolving project with fast release cycles
- Enterprise support or SLAs are required
- You want declarative day-2 operations (upgrades, vacuum, repack)
- Backup tooling beyond WAL-G basics is needed
- You're worried about single-company dependency with no commercial backing
$ helm install openeverest openeverest/openeverest \
--set operators.postgresql=true \
--set operators.mysql=true \
--set operators.mongodb=true
# ✓ Unified control plane deployed
# ✓ PostgreSQL, MySQL, MongoDB operators ready
# ✓ Single pane of glass for all databases
$ █
Don't just pick an operator. Get a platform.
Solanica + OpenEverest: The Operator Problem, Solved
OpenEverest wraps Percona's operators into a unified control plane — giving you PostgreSQL, MySQL, and MongoDB on any Kubernetes cluster with a single management interface, enterprise support, and no operator sprawl.
One Control Plane Manage PostgreSQL, MySQL, MongoDB from a single API and UI. No operator sprawl.
Apache 2.0 Licensed No AGPL concerns. Use, modify, distribute freely. No license traps.
Any Cloud, Any Cluster EKS, GKE, AKS, on-prem, edge. Same platform everywhere.
Enterprise Support 24/7 support from database engineers. SLAs. Escalation paths. Peace of mind.
✓ This comparison was written by Solanica — we use Percona operators inside OpenEverest
✓ We scored all operators honestly, including our own. See the methodology above.
✓ Last updated: May 2026. We keep this page current.