CloudNativePG

What it is

CloudNativePG (CNPG) is a Kubernetes operator that runs PostgreSQL as a first-class citizen inside the cluster — not a bolted-on StatefulSet with a shell script wrapper. It handles provisioning, high availability via streaming replication, automated failover, rolling updates, backup/restore (via Barman Cloud), connection pooling (PgBouncer), and TLS out of the box. It replaces manual DBA runbooks with Kubernetes-native custom resources (Cluster, Pooler, Backup, ScheduledBackup). No external tools like Patroni or Zalando's postgres-operator stack are required — CNPG implements its own instance manager and controller logic in Go, directly against the Postgres process.

Who builds it and why

The project originated at EDB (EnterpriseDB), the company behind a large chunk of upstream PostgreSQL contribution, and remains primarily driven by EDB engineers, though it's taken outside contributions (238 contributors on GitHub). The motivation is straightforward: EDB sells Postgres expertise and support, and having a credible, vendor-neutral operator strengthens their cloud and enterprise story while making Postgres-on-Kubernetes a viable pattern instead of an anti-pattern. It's a CNCF Sandbox project, which means it's under CNCF governance for neutrality but hasn't yet cleared the bar (adoption breadth, security audits, maturity review) for Incubation.

Production readiness signal

Solid, active signal: 8,902 GitHub stars, commits as recent as July 2026, and a healthy 238-contributor base — not a single-vendor ghost-town project. Latest release is v1.30.0, indicating a long, iterative version history rather than a v1.0 still finding its feet. Apache-2.0 license, Go codebase (consistent with Kubernetes ecosystem norms, easier to audit/extend than a Python or shell-heavy operator).

The caveat: CNCF Sandbox status matters here. Sandbox is the entry tier — it signals "worth watching," not "battle-tested by the foundation's standards." Treat production readiness as a function of your own due diligence (read the failover/split-brain handling docs, test disaster recovery yourself) rather than the CNCF badge doing that work for you.

Who should use this

• Teams already committed to running stateful workloads on Kubernetes who need Postgres to behave like a native K8s resource (GitOps-managed, declarative, observable via kubectl).
• Platform teams building internal Postgres-as-a-Service on top of K8s who want backup/restore, failover, and pooling without stitching together Patroni + pgBackRest + custom operators.
• Organizations already using or evaluating EDB's commercial Postgres offerings, where CNPG is the on-ramp/foundation.
• Anyone tired of maintaining bespoke StatefulSet + sidecar Postgres setups and willing to invest in learning CNPG's CRDs and failover semantics.

Who should NOT use this

• Teams without existing Kubernetes operational maturity — running stateful databases on K8s adds real complexity (storage classes, PDBs, node affinity, volume expansion) that a broken cluster will expose brutally.
• Anyone needing extreme low-latency, tightly-tuned bare-metal Postgres performance — the operator abstraction and containerized storage layer add overhead versus dedicated hardware.
• Shops that already have working, battle-tested Postgres HA (e.g., Patroni + Consul/etcd) with years of institutional runbook knowledge — migrating for its own sake isn't worth the risk.
• Teams wanting a fully managed experience with vendor SLAs and 24/7 support baked in — CNPG is self-managed unless you're paying EDB (or another vendor) for support.
• Multi-database-engine shops looking for one operator to rule MySQL, Postgres, and MongoDB — CNPG is Postgres-only, by design.

Alternatives

• Zalando's postgres-operator — older, widely deployed, uses Patroni under the hood; more battle-tested in some shops but architecturally heavier.
• Crunchy Data's PGO — another vendor-backed operator with strong backup/DR tooling (pgBackRest), comparable enterprise support model to EDB's.
• StackGres — opinionated, batteries-included Postgres platform with built-in monitoring/pgbouncer, smaller community than CNPG.

Pricing

Fully open source, Apache-2.0, no license cost. Commercial support and managed offerings are available through EDB and other vendors, but the operator itself is free to run and modify.