CloudNativePG is a CNCF Incubating project as of today. The CNCF Technical Oversight Committee vote passed on 2 November 2026, closing a review that opened when the project applied for Incubation at KubeCon North America in Atlanta on 12 November 2025. For teams running PostgreSQL on Kubernetes, this is the most consequential community milestone of the quarter — not because a badge changes the operator’s code, but because it changes who is allowed to control the operator’s direction.

The announcement came in Gabriele Bartolini’s own post, CloudNativePG reaches CNCF Incubation, published on Planet PostgreSQL today. Here is the short version of a long climb, and what it actually means for a production DBA.

From anti-pattern to acceptable default

The timeline is worth keeping straight, because the project has been called “new” for six years:

• 1 August 2019 — the initiative starts at 2ndQuadrant; the first commit lands on 18 February 2020.
• Autumn 2020 — EDB acquires 2ndQuadrant and keeps the team on a long-term roadmap.
• April 2022 — EDB open sources the operator under Apache 2.0. A first CNCF Sandbox application was rejected in July 2022.
• January 2025 — accepted into the CNCF Sandbox, after two more years of work on volume snapshot integration with CNCF TAG Storage.
• 2 November 2026 — accepted as an Incubating project, roughly a year after applying.

While that was happening, the argument flipped. Bartolini’s line is that the question in the room is no longer “should we run PostgreSQL on Kubernetes?” but “which operator, and how do we run it well?” For anyone who sat through the 2019-era conference talks declaring databases too stateful for containers, that is a real shift in community consensus, not marketing.

What the TOC actually reviewed

Incubation is a due-diligence exercise, not a popularity contest. The review covers security posture, release maturity, governance, and adoption by multiple independent organisations. The numbers the project brought to that review:

• 9,500+ GitHub stars and 247 million operator image downloads.
• About 775 commits on main so far in 2026 — on pace for a sixth consecutive year above 800.
• 14 maintainers across four organisations (EDB, GEICO, Upbound, Verito Digital), up from 7 at application time.
• All five Security Slam 2026 badges, plus a public threat assessment, an OpenSSF Best Practices baseline, and a SECURITY-INSIGHTS.yml file.

That last item is underrated. If your organisation falls under the EU Cyber Resilience Act supply-chain questions, a maintained security-insights manifest and a published threat model are the artefacts auditors ask for, and you get them without commissioning anything.

What changes for a DBA team

Three things, and they are structural rather than cosmetic.

Governance stops being a promise. Over the next six months the project will reform its Steering Committee with an organisationally balanced voting system and a hard cap of two seats per company — an explicit guarantee that no single vendor, EDB included, can steer the project alone. If CloudNativePG is the substrate under a regulated workload, that cap is the thing you cite in an architecture review.

The project is being split so the core stays small. The GitHub organisation now carries more than 30 active repositories, organised into four subprojects: Core, Supply Chain, Community/Docs & Ecosystem, and Extensibility. Extensions, image catalogs, Helm charts and dashboards move at community speed; resilience and database primitives stay with the core team. One example already shipping on the plugin interface (CNPG-I) is Klio, a multi-tiered backup and recovery plugin.

Incubation unlocks distribution, not just credibility. Official CNCF co-located events come with the tier, and the project is planning an official CloudNativePG Day at KubeCon. More operators and DBAs meeting in a room with maintainers usually means faster answers for the odd cases — split-brain under network partition, restore of a huge cluster, snapshot behaviour on your storage class.

What has not changed

Two things, and they matter more than the announcement.

First, incubation is not graduation. The project’s stated plan is to apply in 2027 with a goal of graduating during 2028, and EDB remains by far the largest contributor. A cap of two steering seats does not by itself diversify a contributor base; watch the maintainer count and the commit mix over the next four quarters if vendor independence is a hard requirement for you.

Second, an operator still does not back itself up. CloudNativePG gives you declarative failover, but the recovery story is yours: object storage, retention, and a restore you have actually executed. Our restore verification runbook walks through the checks we run before trusting a standby promotion in a cutover window.

A minimal cluster manifest has not changed either — this is still the whole declarative surface you need to start:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: trading-ledger
spec:
  instances: 3
  storage:
    size: 100Gi
    storageClass: local-path
  postgresql:
    parameters:
      shared_buffers: 4GB

And before you pin an operator version in a platform repo, check what the cluster is actually running and how it is behaving:

kubectl get clusters.postgresql.cnpg.io -A
kubectl cnpg status trading-ledger -n postgres

Also in this week’s release queue

The community news does not stop for the CNCF. Three items with dates attached:

• PostgreSQL 19 RC 1 has been out since 15 October 2026. Release candidates are not for production, but running your real workload against one is exactly what the project asks for — and it is the cheapest bug you will ever find. Our notes on the RC 1 landing and the GA slip cover what to test first.
• PostgreSQL 14 reaches end of life on 12 November 2026 — ten days from today. After that date there are no more fixes, security or otherwise, for 14.x — the community versioning policy gives every major exactly five years. If a 14 cluster is still serving traffic in your estate, this week is the week to schedule the upgrade, not the week after.
• Maintenance releases currently stand at 18.6, 17.11, 16.15, 15.19 and 14.24 (13 August 2026), with pgAdmin 4 v9.19 and a security update to E-Maj 5.0.1 both landing on 31 October.

KubeCon + CloudNativeCon North America runs 9–12 November in Salt Lake City, which means the Incubation announcement lands a week before the largest audience the project will see this year. Expect the CloudNativePG sessions to be standing room.

The Houston read

Most Houston shops we talk to are not choosing between Kubernetes and nothing — they are choosing between a managed Postgres service and a platform they control. Vendor-neutral governance is what makes the second option defensible in a five-year plan: it means the operator’s roadmap cannot be repriced or reprioritised by a single company’s quarterly targets, and it means your team’s operational knowledge transfers between clouds, colos and on-prem clusters in the same metro.

That is worth more than a star count. If you are weighing CloudNativePG against a managed service for a workload you intend to run for a decade, a CloudNativePG readiness review for your Postgres platform is the conversation to have before you commit to either — failover behaviour, backup and restore, upgrade path, and the on-call cost nobody budgets for.