Cloudnativepg

CloudNativePG is now a CNCF Incubating project, and it is a long way from the days when running PostgreSQL in Kubernetes was called an anti-pattern. This is a personal look at the road that led here: a cloud native initiative started at 2ndQuadrant in 2019, its quality-first mindset, the long-term support of EDB after the acquisition and the open sourcing of the project, a rejected Sandbox application in 2022 and the decision we took at KubeCon Atlanta. It also explains what Incubation means for PostgreSQL on Kubernetes, how the project governance and maintainer team are evolving, and our plan to apply for Graduation in 2027.

A first look at what CloudNativePG 1.31 will bring to PostgreSQL credentials: a DatabaseRole can now generate its own password, keep it in a Secret the operator owns, shape it with criteria and rotate it on a schedule, with PostgreSQL enforcing the lifetime through VALID UNTIL. The feature is merged but not yet released, so this recipe anticipates 1.31 and shows how to try it today on the latest development snapshot.

A walkthrough of running OpenBao on Kubernetes with CloudNativePG as its PostgreSQL storage backend. Every layer of this stack is open source, with no vendor lock-in: Kubernetes and CloudNativePG are both CNCF projects, authenticated entirely over TLS client certificates via the 1.30 DatabaseRole CRD, with no passwords anywhere in the stack. Co-authored with Rob Kenefeck from ControlPlane.

CloudNativePG lets the ClusterImageCatalog carry extension images alongside the operand, a capability every currently supported release already has, so a Cluster manifest only needs to name an extension and nothing else. This recipe deploys the community’s extension catalog and shows the operator resolving pgvector’s image, paths and dependencies from a single, versioned source of truth per PostgreSQL major version. More importantly, it is the piece of infrastructure that turns extension distribution into a real ecosystem: once an extension lands in the catalog, every Cluster that references it inherits it for free, with no manifest ever needing to change again.

CloudNativePG 1.30 introduces the DatabaseRole CRD and built-in TLS client certificate issuance, letting application teams own their PostgreSQL credentials declaratively and connect without ever handling a password.

This article compares CloudNativePG and Crunchy PGO, two of the most adopted open-source operators for running PostgreSQL on Kubernetes. It covers architecture, image design, backup strategy, major version upgrades, observability, licensing and community health. As a co-founder and maintainer of CloudNativePG, I make no claim to neutrality, and I say so upfront. What I can offer is informed bias, grounded in years of daily work on the project and a genuine respect for what Crunchy Data built in this space.

A step-by-step guide to migrating a PostgreSQL 17 cluster managed by Crunchy PGO v6 to PostgreSQL 18 under CloudNativePG. Two paths are covered: a fully declarative offline migration using CloudNativePG’s built-in pg_dump import, and an online migration using native PostgreSQL logical replication for a near-zero-downtime cutover.

Yesterday, David Steele announced the end of life of pgBackRest — a PostgreSQL backup tool he maintained for thirteen years. The reasons are structural, not personal, and they are a reminder of a pattern we see too often in open-source infrastructure. This article reflects on what that means, on the architectural rivalry between pgBackRest and Barman, and on why CloudNativePG users can take confidence from both the project’s CNCF governance and the virtuous cycle of commercial support that sustains it.

This article examines how managed database services deliberately suppress access to the physical replication stream, turning operational convenience into permanent lock-in. It makes the case for a cloud-neutral stack — PostgreSQL, Kubernetes, and CloudNativePG — as the only architecture that returns full operational sovereignty to the organisation that owns the data.

In this article I walk you through the journey of adding the pg_crash extension to the new CloudNativePG extensions project. It explores the transition from legacy standalone repositories to a unified, Dagger-powered build system designed for PostgreSQL 18 and beyond. By focusing on the Image Volume feature and minimal operand images, the post provides a step-by-step guide for community members to contribute and maintain their own extensions within the CloudNativePG ecosystem.