Postgres Belongs on Kubernetes: CloudNativePG Reaches CNCF Incubation

An independent review of security, engineering, and governance, and what comes next for running Postgres in production on Kubernetes.

Two roles shape this post. I am a cofounder and maintainer of CloudNativePG, and at EDB I am VP and Distinguished Engineer. Last week the CNCF Technical Oversight Committee voted to promote CloudNativePG to Incubation status. Behind the official announcement sits a public, yearlong due diligence review of the project’s security, engineering, and governance, including interviews with organisations running it in production. I want to explain what the review found, what it asked of us, and where we intend to take the project.

What Incubation means

The CNCF groups its projects into three maturity levels, and the differences matter when you are deciding what to depend on.

• Sandbox is for experimental projects in their early stages of development. The CNCF itself warns that Sandbox projects can change significantly, including breaking changes.
• Incubation is the middle stage. A project has moved beyond experimentation and changes more slowly, with fewer breaking changes and stable, versioned APIs. This is also where the CNCF begins to examine adoption seriously: The reviewers interview real users of the project and verify that it runs in practice.
• Graduation is for highly mature projects whose adopters have demonstrated production readiness, with comprehensive security and a community that no single organisation steers.

Crossing the Chasm (Credit: CNCF)

The diagram borrows from Geoffrey Moore’s model of how technology spreads. Early adopters will try something promising because they can see the potential. The pragmatic majority wait for proof: independent validation, a track record, and some assurance that the project will outlive its sponsor. The gap between the two is the chasm. A project crosses it by earning that proof.

Incubation is another important step towards the standardisation of Postgres workloads on Kubernetes. As the chasm model anticipates, we expect growth to accelerate from here, as more of the pragmatic majority gain the confidence to adopt.

A commitment made in 2022, and kept

EDB created CloudNativePG, is its largest contributor, has led it through every stage to Incubation, and is ready to lead the work towards Graduation. When we open sourced the operator in April 2022, we said what we would do: Release it under the Apache 2.0 licence, hand its governance to a community of contributors under the principle of “community over product/company,” and take it through the CNCF maturity stages. In January 2025, CloudNativePG was accepted into the Sandbox, marking the first time a PostgreSQL project formally entered the CNCF, and we announced this in a press release and a blog. We said then that Incubation was the next goal. Today it is done.

The next step is Graduation. We will apply in 2027 and aim to graduate in 2028.

The whole lifecycle, defined declaratively

Running a database in production is more than keeping it up. It means recovering from an unplanned failure, proving what happened, protecting the data and the supply chain around it, and doing all of this at scale across hundreds of clusters, without hundreds of runbooks. Most approaches solve one of these problems and leave you to assemble the rest.

CloudNativePG covers the full lifecycle in one place, and the principle that holds it together has been the same since the 2022 announcement: It is entirely declarative. You describe the desired state in Kubernetes resources and the operator reconciles towards it. Clusters, backups, scheduled backups, databases, roles, connection poolers, publications, subscriptions, and image catalogs are all resources. Nothing about the database’s life depends on someone logging in to run a command, and everything can live in version control.

Within that model, the operator acts as the control plane for the database:

• Availability: Promotion decisions based on replication position, protection against split-brain, and a primary that fences itself when it loses the network
• Disaster recovery: Continuous archiving to object storage, point-in-time recovery, CSI volume snapshots for near-instant backup and cloning, and replica clusters that span Kubernetes clusters
• Observability: A built-in Prometheus exporter, ready-made dashboards, and structured logs, so the database shows up in the monitoring you already run
• Security: Non-root, immutable containers with a read-only file system, TLS managed through standard Kubernetes tooling, secret rotation, and signed releases with software bills of materials and build provenance
• Extensibility: A plugin interface that lets backup providers and other capabilities evolve at their own pace, without changes to the core operator

The project documents this at the highest level of the operator capability model, which covers exactly this: not just installing a database but running it on its own.

For a platform owner, this means one operating model for applications and data. Upgrades and patching are declarative changes that fit GitOps and change management. The behavior is the same on any conformant cluster, so your exit options stay open. And the layers that keep data safe are part of the same system, not extra products to integrate and audit.

What the reviewers found

The due diligence is public, and I encourage you to read it. The findings most relevant to a risk assessment:

• 51 documented adopters across more than 7 industries and 10 countries, including government agencies, a pharmaceutical group, and an automotive manufacturer, listed in the public adopters file
• Google Cloud, Microsoft Azure, and IBM each build commercial products on CloudNativePG, which is unusual validation for an open source operator
• A passing OpenSSF Best Practices badge and a published security self-assessment, backed by an end-to-end test suite that includes failure scenarios
• Up to three release branches supported concurrently, with coordinated patch releases, which gives you a predictable maintenance window

The reviewers interviewed adopters independently of the project. They praised documentation quality, high availability, and a dependable upgrade path. One of them described the main benefit as bringing Kubernetes operating practices to the database tier: When a security patch is released, images are rebuilt and rolled out across the fleet without anyone logging in to a server, and backups and point-in-time recovery are configured as code.

The same pattern shows up in a regulated institution. Intesa Sanpaolo, Italy’s largest bank and an EDB customer, grew from 10 shared databases to more than 500 independent Postgres instances running on Kubernetes, with CloudNativePG managing the lifecycle: storage, replication, failover, and recovery. In its customer story, the bank’s database architect describes the goal as databases that “could operate at the same speed as our application platforms.” Failover is now automatic enough that teams review alerts the next morning instead of handling incidents live.

The reviewers also gave us homework, which brings me to the topic of governance.

Independence you can verify

A CIO signing off a long-lived dependency needs to know what happens if the sponsor’s priorities change. The honest answer is structural, not a promise from me.

The CloudNativePG trademarks and intellectual property are held by the CNCF, and the code is Apache 2.0. In the review, one adopter pointed to exactly this as its main protection against single-vendor risk. EDB will continue to invest heavily in the operator’s core and ecosystem, as we do in PostgreSQL itself and in other open source projects such as WarehousePG.

The project also has to stand on its own, and here the reviewers were clear about where we are. It now has 14 maintainers from four organisations (EDB, GEICO, Upbound, and Verito Digital), organised into four subproject committees, each owning its own repository. The ecosystem around the operator is already shared, and the contributor ladder is open to anyone: Contributors progress to subproject maintainer on merit, and each person’s employer is recorded so that organisational balance can be measured. The Steering Committee, however, is still made up of EDB maintainers today, and the changes already tracked in the governance repository will fix that.

EDB will continue to provide technical leadership for the operator engine, with the depth in PostgreSQL internals that a database demands. Because the community can increasingly own the surrounding tools, our engineers can concentrate on the resilience, performance, and database primitives of the operator itself. What changes is who decides the project’s direction. Over the next six months we will:

• Introduce organisationally balanced voting and a seat mechanism for the Steering Committee, with a cap of two seats per company, EDB included
• Hold the first meeting of the reconstituted Steering Committee and publish the minutes
• Report progress to the CNCF in public

These are tracked publicly, so you do not have to take my word for it.

Where we are heading

Graduation requires a project that no single organisation can steer, so it keeps us honest on the governance work above. Beyond that, the reviewers and adopters set clear priorities, and each one deepens a part of the lifecycle:

• Security assurance: The next OpenSSF level and an assessment in the format used by the CNCF security group
• Day-two operations: Clearer visibility into maintenance and audit events, troubleshooting tools, and better paths for bringing existing data into Kubernetes
• Disaster recovery at scale: A richer backup ecosystem through the plugin interface and better coordination across clusters and regions, which adopters asked for explicitly
• Integration blueprints for combining CloudNativePG with the other CNCF projects in a typical platform
• A high bar for code review, because a database project cannot trade correctness for contribution volume

We will also maintain the release cadence adopters depend on, since predictability is a feature in its own right.

What to do next

Incubation also lets the project apply to host official co-located events at KubeCon. I will definitely work with the CNCF to ensure we can host CloudNativePG events now that we are in Incubation, and I hope to see many of you there.

If you already run CloudNativePG, register your organisation in the public adopters file. It helps the next CIO make the same case you did. If you are choosing a database strategy for your platform, conduct due diligence, ask your teams to try the operator, and talk to us about how EDB can support you. CloudNativePG is also, as we said in our Sandbox press release, the foundation of EDB Postgres AI.

Postgres belongs on Kubernetes. The question that remains is how completely the platform can run it, and that is where we plan to keep improving.