PostgreSQL controlled through Kubernetes
CloudNativePG turns a PostgreSQL cluster into a Kubernetes resource. You declare the instance count, storage, PostgreSQL settings, and update policy. The operator creates supporting resources and reacts when the live cluster differs. A failed primary can be replaced by a replica, service endpoints are updated, and image changes roll through replicas before the primary switches.
This design avoids an external high-availability coordinator such as Patroni. Cluster status lives on the Cluster resource, and Kubernetes remains the control plane. The operator also manages databases, roles, poolers, backups, publications, and subscriptions. GitOps teams can review those objects beside application manifests.
CloudNativePG supports Kubernetes and vanilla PostgreSQL. MariaDB and other databases are outside scope, as are PostgreSQL forks unless their additions work as extensions or plugins. Shops seeking one operator for several database engines should walk away.
A quick trial is smaller than production
The quickstart uses Kind or Minikube, installs the operator, and applies a sample three-instance PostgreSQL cluster backed by the default storage class. kubectl is required. The docs reserve this path for practice: a local cluster can show reconciliation and failover, but it says little about production storage latency or restore time.
You can apply a published manifest, generate one with the cnpg plugin, install a Helm chart, or use Operator Lifecycle Manager. The controller normally runs as one deployment replica and supports leader election for multiple replicas.
Private GKE clusters may block control-plane traffic to the validating webhook on port 9443 unless the firewall or service port is adjusted. Database pods need persistent volumes with understood behavior. Production images should use specific versions or digests, since the docs warn against latest and bare major-version tags.
Failover automation still needs an operator
CloudNativePG automates promotion, replica creation, service changes, and controlled primary switches. Version 1.30.0 added a Kubernetes Lease as a mutex for primary promotion. The release notes call it a promotion check rather than fencing. Primary isolation still carries that responsibility.
An operator cannot make unreliable storage reliable or decide your tolerance for data loss. Teams need to test node disappearance, network partitions, and stalled volumes on their platform. An issue updated on 2026-08-21 describes failover blocked when a WAL sender survives on a damaged node. That specific report is reason to test isolation instead of only deleting a healthy pod.
Updating the controller triggers an instance-manager rollout across each cluster. The default unsupervised policy performs the final switchover automatically; supervised mode waits for a manual promotion through the plugin. Pin versions and read the matching release notes before changing them.
Backup choices are operational
CloudNativePG manages physical backup workflows. Logical pg_dump backups are outside its business-continuity path. For object storage, the official direction is the Barman Cloud Plugin through CNPG-I. Native Barman Cloud integration has been deprecated since 1.26, and v1.30.0 says removal moved to 1.31.0. Existing users need a migration task.
Kubernetes volume snapshots are the other main option when the storage class supports them. Object-store backups require WAL archiving and support hot backups. Snapshot behavior depends on the CSI implementation. The docs recommend WAL archiving in production because it enables point-in-time recovery. A WAL archive cannot restore a cluster without a physical base backup.
Object storage can improve portability across environments. Snapshots can restore large volumes quickly, but bind recovery to storage capabilities. Credentials, retention, cross-region access, and restore drills remain the operator's work.
What happened when we ran it
We cloned commit a95a534 into an unprivileged golang:1.24-bookworm container with 3 CPUs and 8 GB of RAM. The repository contained 1,839 files, about 217,431 lines of source, and occupied 60.5 MB. It had 21 CI workflow files, a Dockerfile, and a tests directory.
Installation succeeded in 55 seconds with 231 packages installed. The build succeeded in 167 seconds. Tests ran for 173 seconds and returned exit code 1. The Go summary counted 85 passing packages and 1 failing package out of 86.
The supplied tail shows successful packages under pkg/specs, pkg/system, and several pkg/utils paths, plus packages with no test files. It then ends with FAIL. Since that excerpt does not name the failed package or show its assertion, we cannot explain the failure beyond the aggregate result. The test result prevents a clean-run claim for this commit in our sandbox.
Documentation, releases, and activity
The docs are candid about production limits. The quickstart warns against using its local recipe in production. Installation pages cover firewall problems and rolling updates. Backup docs compare object storage with snapshots and explain the Barman transition.
Version 1.30.0 was released on 2026-06-29. It added declarative database roles, primary election changes, and fixes around backup, bootstrap, storage, certificates, and reconciliation. The last repository push was 2026-08-22, with issues and pull requests updated the same day. GitHub listed 422 open issues and pull requests combined. Activity around snapshots, failover, role management, and backports spans supported release lines.
CloudNativePG reduces handwritten database orchestration. It does not reduce the consequence of getting storage, isolation, or recovery wrong. Teams that accept that division of labor get a capable PostgreSQL operator with clear boundaries.