CloudNativePG

A Kubernetes operator that runs highly available PostgreSQL with no Patroni and no StatefulSets: the Kubernetes API itself holds the cluster’s state.

What it is: Relational databases,Container orchestration
Type: Open source
Made by: CloudNativePG community (started at 2ndQuadrant and EDB)
License: Apache 2.0
Facts checked: 6 October 2026

What it is

CloudNativePG adds a Cluster resource to Kubernetes. You declare how many instances you want, the Postgres image and the storage, and the operator creates one pod and one or more persistent volume claims per instance: a primary and streaming replicas. It doesn’t use a StatefulSet, because that controller treats every pod the same; CloudNativePG runs its own pod controller so it can update replicas before the primary, resize volumes, and keep WAL and data volumes in step. Inside every pod the first process (PID 1) is the instance manager, which starts postgres, answers Kubernetes’ health probes, exports metrics and archives WAL. There is no Patroni, repmgr or etcd of its own: the operator keeps the cluster’s status in the Kubernetes API and uses it as the only source of truth.

Applications connect through three Services the operator keeps up to date: -rw always points at the primary, -ro at the replicas and -r at any instance. When the primary fails its readiness probe, the operator shuts it down, waits for the replicas to stop receiving WAL, and promotes one of them; since 1.30 an instance must also hold a Kubernetes Lease before it can promote. The old primary comes back as a replica, resynchronised with pg_rewind. Backups go to object storage (Amazon S3, Google Cloud Storage, Azure Blob Storage or S3-compatible stores) through the Barman Cloud plugin, or to Kubernetes volume snapshots. With a WAL archive the project promises a recovery point of 5 minutes or less. It is free under Apache 2.0, a CNCF Sandbox project since January 2025, and EDB sells support and a commercial build.

Why teams pick it

Kubernetes-native design: no external failover tool or separate consensus store to run, and kubectl shows the cluster’s state in the Cluster resource
Its own pod controller handles what a StatefulSet can’t: replicas first, then a switchover for the primary, volume resizing, and separate WAL volumes
Batteries included: PgBouncer poolers, Prometheus metrics on port 9187, declarative databases, roles, publications and subscriptions, and replica clusters in another Kubernetes cluster for disaster recovery
Vendor-neutral governance under the CNCF, a new minor release every few months, and commercial support from several companies, including EDB and Percona

Watch out for

Kubernetes and vanilla PostgreSQL only: no VMs, no other databases, and no Postgres forks unless their features come as extensions
Backups are mid-migration: the built-in Barman Cloud support has been deprecated since 1.26 (May 2025) and is due to be removed in 1.31, so existing clusters must move to the plugin, which also needs cert-manager or your own certificates
Asynchronous replication is the default; zero-data-loss failover needs synchronous replication, which adds write latency
Only physical backups are managed; pg_dump is left to you, and the docs warn it isn’t enough for business continuity
Each minor release is supported only until three months after the next one, so you upgrade the operator several times a year

Alternatives

What all relational databases have in common →

Alibaba Cloud PolarDBCommercialAlibaba Cloud’s cloud-native relational databases: MySQL- and PostgreSQL-compatible clusters whose compute nodes share one copy of the data on distributed storage, plus PolarDB-X, a distributed MySQL-compatible edition.

CedarDBCommercialA PostgreSQL-compatible database rebuilt from scratch at TU Munich, running transactions and analytics on one copy of the data on a single server.

Cloudflare D1CommercialCloudflare’s serverless SQL database that speaks SQLite, runs each database inside a Durable Object, and bills by rows read and written rather than by the hour.

CockroachDBCommercialA distributed SQL database that speaks the PostgreSQL wire protocol, replicates every slice of data with Raft and keeps transactions serializable across nodes and regions.

MySQLOpen sourceThe long-standing open-source SQL database behind much of the web, built on the InnoDB engine.

NeonCommercialServerless Postgres that keeps data in a shared storage layer, so compute can scale to zero and a branch of the database is a pointer, not a copy.

PatroniOpen sourceA Python agent beside each Postgres server that elects one primary through etcd, Consul, ZooKeeper or Kubernetes, and fails over when it dies.

Percona OperatorsOpen sourceFour free Kubernetes operators from Percona that run its builds of MySQL, PostgreSQL and MongoDB, each using the engine’s own replication and backup tools.

PGO (Crunchy Postgres for Kubernetes)Open sourceCrunchy Data’s Postgres operator: Patroni in every pod for failover, pgBackRest for backups, and a declarative `PostgresCluster` resource on top.

PlanetScaleCommercialManaged MySQL on Vitess and managed Postgres, with schema changes shipped through branches and deploy requests.

PostgreSQLOpen sourceThe open-source relational database that most new projects start on, extensible enough to grow into many niches.

ScramDBCommercialA brand-new, closed-source database that speaks the PostgreSQL protocol and promises transactions, analytics and vector search on one copy of the data; first builds shipped in summer 2026.

SQLiteOpen sourceA complete SQL database in a library and a single file, with no server to run.

TursoOpen sourceA from-scratch Rust rewrite of SQLite with concurrent writes, plus libSQL (an open-contribution SQLite fork) and Turso Cloud, which hosts many small databases on S3.

VitessOpen sourceA proxy layer, born at YouTube, that shards MySQL across many servers while the app still sees one database.

How it fits with other technologies

What CloudNativePG uses

What uses CloudNativePG

pgBackResthas an experimental plugin forCloudNativePGBackup & restore

A three-instance cluster that archives WAL to S3 through the Barman Cloud plugin, with a nightly backup · yaml

apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
  name: s3-store
spec:
  retentionPolicy: "30d"            # keep 30 days of point-in-time recovery
  configuration:
    destinationPath: s3://acme-pg-backups/
    s3Credentials:
      accessKeyId:     { name: aws-creds, key: ACCESS_KEY_ID }
      secretAccessKey: { name: aws-creds, key: ACCESS_SECRET_KEY }
    wal:
      compression: gzip
---
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: orders
spec:
  instances: 3                       # one primary, two streaming replicas
  storage:
    size: 50Gi
  plugins:
  - name: barman-cloud.cloudnative-pg.io
    isWALArchiver: true
    parameters:
      barmanObjectName: s3-store
---
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: orders-nightly
spec:
  schedule: "0 0 0 * * *"          # six fields: seconds come first
  cluster:
    name: orders
  method: plugin
  pluginConfiguration:
    name: barman-cloud.cloudnative-pg.io

# apps connect to orders-rw (primary), orders-ro (replicas) or orders-r (any)

Three common ways to run Postgres on Kubernetes#

All three are free operators that give you a primary, streaming replicas, automatic failover and backups to object storage. They differ in who decides failover, what does the backups, and the terms on the images you run.

	CloudNativePG	PGO (Crunchy Data)	Percona Operator for PostgreSQL
Who decides failover	The operator and each pod’s instance manager, through the Kubernetes API and a `Lease`	Patroni in each pod, racing for a lease kept on a Kubernetes Endpoints object	Patroni, as in PGO (Percona’s operator is based on PGO)
Pods run by	Its own pod controller	One `StatefulSet` per instance	Inherited from PGO
Backups	Barman Cloud plugin to object storage, or volume snapshots	pgBackRest, up to four repositories (volume, S3, GCS, Azure)	pgBackRest
Code licence	Apache 2.0	Apache 2.0	Apache 2.0
Default images	Community images from the project	Crunchy’s images: free in production only for organisations under 50 employees	Percona’s images, with no licence fees
Steward	CNCF Sandbox project (started by EDB)	Crunchy Data, which is joining Snowflake	Percona

Other options include Zalando’s Postgres Operator (Patroni and WAL-G inside its Spilo images), StackGres and Kubegres.
PGO can run images you build yourself from PGDG packages, which avoids Crunchy’s image terms.

See it in a real stack

No architecture uses CloudNativePG yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2019–2026

For years the advice was not to run databases on Kubernetes. Two things changed that for the Postgres team at 2ndQuadrant: local persistent volumes became generally available in Kubernetes 1.14 in April 2019, and the operator pattern became the standard way to automate stateful software. In August 2019 Simon Riggs, then 2ndQuadrant’s CEO, asked Gabriele Bartolini, whose team had created the Barman backup tool, to lead a Kubernetes initiative. By December their benchmarks showed Postgres on bare-metal Kubernetes performing almost exactly like Postgres on bare-metal Linux.

They set strict rules for the operator: light, immutable images with only postgres inside, a fully declarative API, and failover decided through the Kubernetes API server rather than by repmgr (which some of the team had worked on), Patroni or Stolon. Work on Cloud Native Postgres started in February 2020. EDB bought 2ndQuadrant that September, shipped a first stable release in February 2021 and built its BigAnimal cloud service on it.

On April 21, 2022, EDB renamed the operator CloudNativePG, opened its repository with more than 1,400 commits of history under Apache 2.0, released version 1.15.0 and applied to the CNCF, handing governance to a community of maintainers. The CNCF accepted it into the Sandbox on January 21, 2025. Since 1.26 the project has been moving backups out of the core into plugins through its CNPG-I interface, starting with Barman Cloud.

Why it’s built this way

No Patroni or external consensus store: Kubernetes already has a consistent store, the API server. Using it as the only source of truth means one fewer distributed system to run, and the cluster’s state is visible with ordinary Kubernetes tools.
Its own pod controller instead of a StatefulSet: A StatefulSet treats pods as interchangeable and can’t resize volumes. Postgres has one primary, some changes must reach replicas first and others the primary first, so the operator needs to know each instance’s role.
Immutable application containers: Each image runs a single postgres of one version, with no SSH or systemd. Updates mean a new image and a rolling replacement, which is repeatable and fits GitOps.
Backups as plugins: Moving WAL archiving and base backups behind the CNPG-I interface lets the core stay backup-agnostic, so Barman Cloud, snapshots or other tools can be maintained and released separately.

Timeline

2019
2ndQuadrant starts its Kubernetes initiative in August after Kubernetes 1.14 adds local persistent volumes
2020
Cloud Native Postgres development begins in February; EDB acquires 2ndQuadrant in September
2021
First stable release of Cloud Native Postgres, in February
2022
Renamed CloudNativePG and open-sourced under Apache 2.0 with version 1.15.0, April 21
2025
Accepted into the CNCF Sandbox in January; 1.26 in May deprecates built-in Barman Cloud for the plugin
2026
1.30 in June adds a Kubernetes Lease that gates primary promotion

Sources29 · facts checked 6 October 2026

Improve this page on GitHub