CloudNativePG 1.30: declarative Postgres roles and safer failover on Kubernetes

Summary. The CloudNativePG community shipped version 1.30.0 on July 6, 2026. The release adds a DatabaseRole custom resource for declarative, GitOps-friendly role management, a Kubernetes Lease primitive that makes primary promotion safer, and fixes for three security advisories, including a privilege-escalation flaw. It also raises the default PostgreSQL to 18.4 and adds support for Kubernetes 1.36. Two dates force the timeline: the 1.28.x series reached end of life on June 30, 2026, and 1.29.x is confirmed for September 29, 2026, so most teams should be planning a move to 1.29 or 1.30 now. CloudNativePG has become the default way to run Postgres on Kubernetes, a CNCF Sandbox project since January 15, 2025 with more than 7,700 GitHub stars and over 132 million operator-image downloads. Compared with managed Postgres such as Amazon Aurora, which starts near $60/month for a small instance and runs $400 to $900/month for a mid-sized production setup, the operator route trades a managed bill for control you have to run yourself. This guide covers what 1.30 changes, the configuration that matters, the security fixes you should not skip, and how to plan the upgrade.

CloudNativePG is the Kubernetes operator that manages the full lifecycle of a PostgreSQL cluster: bootstrap, configuration, high availability, connection routing, backup and recovery. Version 1.30 is a minor release, but two of its additions change how you model roles and how the cluster behaves during a failover, so it deserves more than a routine bump.

"CloudNativePG is the only PostgreSQL operator project for Kubernetes that is community-owned and governed under a transparent, vendor-neutral model," wrote Gabriele Bartolini, VP and Chief Architect for Kubernetes at EDB and a CloudNativePG maintainer, in his 2025 year in review. That governance model is part of why it has become a safe default: the roadmap is shaped by users, not a single vendor.

What 1.30 changes at a glance

Two of these, the DatabaseRole CRD and the Primary Lease, are the reason to read the release notes rather than skim them.

Declarative roles with the DatabaseRole CRD

Until 1.30, you declared Postgres roles inline, inside the Cluster's .spec.managed.roles stanza. That works, but it couples every role to the Cluster manifest and gives roles no independent lifecycle. The new DatabaseRole custom resource manages a role as a standalone Kubernetes object, so each role has its own lifecycle, status and RBAC. Role definitions can live next to the applications that own them, which is exactly what a GitOps workflow wants. Migrating an existing role is a matter of moving its stanza into a dedicated manifest.

The shape looks like this. Treat the exact fields as illustrative and confirm them against the 1.30 release notes, since a CRD schema is the kind of thing you should copy from the reference, not from a blog.

            # Illustrative - verify field names against the CloudNativePG 1.30 API reference
apiVersion: postgresql.cnpg.io/v1
kind: DatabaseRole
metadata:
  name: app-writer
spec:
  cluster:
    name: pg-prod
  ensure: present
          

The more interesting part is authentication. A DatabaseRole can include a clientCertificate block. When it does, the operator automatically generates and renews a TLS client certificate signed by the cluster's client certificate authority and stores it in a <databaserole-name>-client-cert Secret. That gives you password-free PostgreSQL cert authentication, and the Secret is cleaned up automatically when the feature is disabled or the resource is deleted. For teams that have been rotating database passwords by hand, this removes a whole class of toil and a whole class of secrets in logs.

If you already model your platform declaratively, the DatabaseRole CRD slots into the same pattern you use for the rest of your data platform engineering: the role is a resource, its certificate is managed, and the whole thing is reconciled by the operator.

Safer failover with the Primary Lease

The headline reliability change is a new Kubernetes Lease object, named after the cluster, that acts as a mutex serializing primary promotion. The instance manager must hold the lease before it acts as primary and releases it on a clean shutdown, so replicas can promote without waiting out the full lease TTL. You tune the timings through a new .spec.primaryLease stanza.

            # Illustrative - see the 1.30 docs for the exact primaryLease keys
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: pg-prod
spec:
  instances: 3
  primaryLease:
    # promotion timing controls live here
          

One nuance matters for anyone reasoning about split-brain. The maintainers are precise about it: the lease is a promotion gate, not a fence. Primary isolation, where a primary that loses connectivity self-fences and stops accepting writes, is still what does the fencing. The lease closes the window for an uncoordinated promotion during a transition. Read the two features as complementary: isolation stops a stale primary from taking writes, and the lease stops two nodes from both believing they are primary during the handover. If you run stateful workloads on Kubernetes, this is the same defensive posture you want across stateful services and their failure modes.

Three security fixes you should not skip

Version 1.30 backports its security fixes to the 1.29.2 and 1.28.4 maintenance releases too, so there is no reason to sit on a vulnerable build. Three advisories stand out.

The ECDSA hardening is new in 1.30.0 and is not backported. If you stay on an earlier release for now, the maintainers' guidance is to keep restricting the instance status port with a NetworkPolicy until you upgrade. The privilege-escalation fix (CVE-2026-55769) is the one to prioritise, because it is exploitable by any database owner, a role many application teams hold.

Other changes worth knowing

Beyond the two headline features, 1.30 lands several operational improvements. In-place major upgrades with pg_upgrade now work for clusters using Image Volume extensions: the operator mounts the source-version and target-version extension images side by side, so a failed upgrade reverts cleanly instead of leaving you stranded. PgBouncer image management moves to Image Catalogs, so a Pooler can reference an ImageCatalog or ClusterImageCatalog entry through spec.pgbouncer.imageCatalogRef and roll out automatically when the catalog changes. The Pooler metrics endpoint can now serve TLS via .spec.monitoring.tls.enabled, with certificates reloaded on every handshake. A Cluster can be a target for a Vertical or Horizontal Pod Autoscaler through a new status.selector on the scale subresource. And the operator now emits a PrimaryStatusCheckFailed warning event, visible through kubectl describe cluster, when a primary pod looks ready to the kubelet but fails the operator's own status check.

One API change can bite an unwary GitOps pipeline: the cluster reference is now immutable on the Database, Pooler, Publication, Subscription and ScheduledBackup resources. Re-pointing any of these at a different cluster is rejected by a CEL validation rule at the API server, because it had no well-defined semantics. If a pipeline ever mutated that field, fix it before you upgrade.

Upgrade path and end-of-life dates

The support calendar is the part you cannot ignore. The release ships alongside maintenance updates and retires the oldest series.

If you are on 1.28, you are already unsupported and should move now. If you are on 1.29, you have a runway to late September 2026 but no longer. Follow the operator's documented upgrade instructions, test the immutable-reference change against your manifests first, and roll the operator before you touch database images. The release also adds Kubernetes 1.36 support and moves the default PostgreSQL version to 18.4, so factor a minor Postgres bump into the same maintenance window if you track the default.

Self-managed on Kubernetes or managed Postgres?

CloudNativePG is free and open source, but "free" is the licence, not the total cost. Running Postgres yourself on Kubernetes means you own high availability, backups, upgrades and on-call. Managed Postgres moves that operational load to a provider and charges a premium for it. The trade is real in both directions.

The managed figures above are indicative, drawn from 2026 Aurora cost breakdowns, and your real bill depends on instance size, storage and I/O. The honest read: managed Postgres wins when you have no platform team and want the database to be someone else's pager; CloudNativePG wins when you already run Kubernetes, want portability across clouds, and can staff the operational side. If the decision is close, it usually comes down to whether you have the people, which is the same calculus behind any managed Kubernetes data-platform engagement versus a cloud-provider database.

India-specific considerations

For Indian teams, three points shape the choice. First, data residency: the Digital Personal Data Protection Act, 2023 makes where and how personal data is processed a design question, and running Postgres on your own Kubernetes clusters gives you direct control over region and topology rather than relying on a provider's defaults. Second, cost discipline: teams optimising cloud spend often find that a self-managed Postgres on existing Kubernetes capacity avoids a per-database managed premium, which matters when you run many small databases; the flip side is the engineering time it consumes, which belongs in any honest cloud FinOps calculation. Third, talent: global capability centres in Gurugram, Bengaluru and Hyderabad increasingly run their own platform teams, and CloudNativePG's declarative model fits a GitOps operating model those teams already use. The DatabaseRole CRD and password-free certificate auth also make it easier to demonstrate least-privilege access during a DPDP review.

FAQ

How eCorpIT can help

eCorpIT is a senior-led technology organisation in Gurugram, founded in 2021, that helps teams run stateful workloads like PostgreSQL on Kubernetes without gambling on reliability. We design the operator topology, wire declarative roles and certificate auth, set up quorum failover and the Primary Lease, and put backup, monitoring and upgrade playbooks in place so an on-call engineer is not improvising at 3 a.m. If you are weighing a self-managed Postgres platform against a managed service, see our managed Kubernetes AI platform and data platform engineering work, or contact us to plan the build.

References

1. PostgreSQL News, "CloudNativePG 1.30.0 Released!", July 6, 2026.

1. CloudNativePG, release notes for v1.30.

1. CloudNativePG, installation and upgrade instructions.

1. Gabriele Bartolini, "CloudNativePG in 2025: CNCF Sandbox, PostgreSQL 18, and a new era for extensions", December 31, 2025.

1. The New Stack, "PostgreSQL Operator CloudNativePG hits the CNCF Sandbox".

1. EDB, "CloudNativePG officially joins the CNCF Sandbox".

1. CloudNativePG security advisory, GHSA-x8c2-3p4r-v9r6 (CVE-2026-55769).

1. CloudNativePG security advisory, GHSA-w3gf-xc94-wvmj (CVE-2026-55765).

1. CloudNativePG security advisory, GHSA-7qwx-x8ff-3px9.

1. CloudNativePG, project repository on GitHub.

1. Bytebase, "Understanding AWS Aurora pricing (2026)".

1. Amazon Web Services, Amazon RDS pricing.

_Last updated: July 24, 2026._