CloudNativePG reaches CNCF Incubation: another rung on the ladder

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.

Those who have been with me from the start know that I have always quoted an AC/DC song to remind everyone of the challenge ahead: “It’s a long way to the top (if you wanna rock ’n’ roll)”. The climb is long because our goal has never been just to ship, but to keep the quality of the project at its best. I closed my review of CloudNativePG in 2025 with that same line, and I wrote that we were ready for the climb. Today I am delighted to share that we have reached another rung of the ladder: CloudNativePG has been accepted as a CNCF Incubating project.

A milestone like this is never about a badge. It is about the people who, issue after issue and release after release, turned a bold idea into something organisations trust with their most valuable asset: their data. I will thank them properly at the end, but first let me tell you where we came from.

Where we came from #

When we started, running PostgreSQL in Kubernetes was widely considered an anti-pattern. Databases were pets, Kubernetes was for cattle, and the conventional wisdom was to keep your data far away from your clusters. I have lost count of the conference hallways where I was politely told that what we were building was a nice idea, but not for production.

It all started to take shape on 1 August 2019, when Simon Riggs called me to start a new cloud native initiative at 2ndQuadrant. Simon had a rare ability to see where PostgreSQL needed to go before everyone else did, and he trusted a small team to go and explore. Kubernetes was where we went. We lost Simon in March 2024. His dedication to making PostgreSQL the best database in the world is a large part of why I keep climbing, and I think of him whenever the project reaches a new stage.

Working with Simon also meant living by the mindset that gave 2ndQuadrant its spirit: the second quadrant of Stephen Covey’s time management matrix, as described in The 7 Habits of Highly Effective People. It is the space of what is important but not urgent. Urgent work shouts for attention every day, while important work, such as architecture, testing, security and documentation, is easy to postpone. Committing to the second quadrant forces you to build quality into the product and to aim for world-class quality, always. It is the reason the climb has been long and steady.

That mindset shaped what we set out to build, and at the start almost nobody we talked to understood it. Other PostgreSQL operators for Kubernetes already existed, so the obvious question was why we needed another one. Our feeling was that they were trying to bring Kubernetes to the PostgreSQL world: designed primarily for PostgreSQL people who see Kubernetes as a deployment platform. We wanted the opposite. Our approach was for Kubernetes people, and our motto was bringing PostgreSQL to Kubernetes. A cloud native approach would enable the full lifecycle integration of PostgreSQL inside Kubernetes, as an application like any other.

In June 2020 I published Local persistent volumes and PostgreSQL usage in Kubernetes, based on what we had learned running PostgreSQL on local storage. That article turned out to matter far beyond its technical content. It put me in touch with Evan Powell of MayaData, the company behind OpenEBS, which we had used in our tests, and that is how I first heard about a new community that was about to be founded: Data on Kubernetes. I have been part of the DoK community ever since, and it is where I found many of the people who share the conviction that stateful workloads belong in Kubernetes.

The first commit of what became CloudNativePG had been made on 18 February 2020. In the autumn of 2020 EDB acquired 2ndQuadrant, and the support we received from EDB after the acquisition made all the difference. In February 2021 the operator reached its first stable release as a product, Cloud Native PostgreSQL, and EDB let us carry on working the same way, with a long-term vision rather than a quarterly one. Then, in April 2022, EDB open sourced the project under the Apache License 2.0 and committed to contribute it to a vendor-neutral, openly governed community. I told that part of the story in Introducing CloudNativePG, published in May 2022, so I will not repeat it here.

What that article does not tell is a lesson we had learned the hard way. Barman started life as a proprietary tool, and when it went open source we restarted its public history from a single initial commit, made by Marco on 6 July 2012, which already contained the whole codebase: 36 files and about 5,500 lines. The story of how it had been built was lost. We did not want to repeat that mistake, so we rewrote the entire GitHub history of CloudNativePG before opening it, and more than 1,400 commits of history, going back to the first commit in February 2020, are there for anyone to read.

The CNCF part of the story started in 2022, when we applied to the CNCF Sandbox for the first time. In July we were rejected. It stung, but it taught us humility: a project earns its place in a community by taking part in it, not by knocking on its door. We went back to work, collaborating closely with the CNCF TAG Storage, in particular on our volume snapshot integration. That collaboration is how Leonardo started to contribute to Kubernetes storage itself, and in 2024 he became a key contributor to VolumeGroupSnapshot support in Kubernetes 1.32. Two years after the rejection, in September 2024, we submitted a second application, as I wrote in CloudNativePG in 2024. In the post celebrating 5,000 GitHub stars I announced that it was about to be evaluated, and on 15 January 2025 CloudNativePG was accepted into the CNCF Sandbox.

The Sandbox was strategic, not just symbolic. It let us work closely with other CNCF projects on real architectural problems, with integrations for Cilium, External Secrets Operator and Keycloak. It also gave us the structural protection I described in the virtuous cycle: governance, intellectual property and continuity held by a vendor-neutral foundation, independent of any single company, employer or sponsor.

Then came Atlanta. As I recounted in my KubeCon NA 2025 recap, I went there with a precise goal: talk to CNCF TOC and TAG members and gauge whether CloudNativePG was in the right place to apply for Incubation. We decided to take the leap right there, and on 12 November 2025 we submitted the application for Incubation. In my lightning talk I asked people to add their organisation to ADOPTERS.md, because adoption is what helps a project cross the chasm. Many of you did, and it made a real difference.

Behind those dates is a steady pattern. 2025 closed with over 7,700 GitHub stars, more than 132 million downloads of the operator image and nearly 880 commits, the fifth consecutive year above 800. Today we are at over 9,500 stars and 247 million downloads, with about 775 commits on main so far in 2026, on track for roughly 930 by the end of the year and a sixth consecutive year above 800. That consistency is what reviewers look for. It is the result of EDB’s sustained investment and of a community that has grown around it.

Stars are a blunt instrument, but the shape of the curve tells a story: since we open sourced the operator in 2022, the growth has been steady and has never flattened.

From taboo to standard #

The conversation has changed. The question I hear today is no longer “should we run PostgreSQL on Kubernetes?” but “which operator should we use, and how do we run it well?”. Declarative, self-healing, Kubernetes-native PostgreSQL has moved from a heresy to a mainstream pattern. And when it comes to choosing an operator, there is a difference that matters: CloudNativePG is the only PostgreSQL operator for Kubernetes with vendor-neutral governance, not owned by a single company.

That shift is the result of the approach I described earlier: bringing PostgreSQL to Kubernetes, rather than the other way around. In practice, the operator talks directly to the API server and manages PostgreSQL instances itself, without relying on external failover tools, so that a database behaves like any other Kubernetes application. If you want to understand that design choice, the controller documentation is the place to start.

What matters most to me is who benefits. Passing CNCF due diligence confirms that production-grade PostgreSQL is not a privilege of hyperscalers or of those who can afford a proprietary platform. A start-up, a conservative bank and a public agency can all run the same self-healing, cloud-neutral data infrastructure, on the same open standards, with no lock-in. That is the promise of cloud native PostgreSQL, and Incubation is a strong sign that it is being kept.

What Incubation really means #

On 2 November 2026, almost a year after our application, the CNCF TOC vote to move CloudNativePG to Incubation passed. It would be easy to see Incubation as a badge, but the process is a serious one. The CNCF Technical Oversight Committee and its reviewers examined the project across several dimensions, including security posture, release maturity, governance and, crucially, real-world adoption by multiple independent organisations. The due diligence document is public, and I encourage you to read it. It is a candid portrait of the project, strengths and areas for improvement included. You can follow the review in the pull request in the CNCF TOC repository.

Security was one of the areas where we invested most visibly. At Security Slam 2026, celebrated at KubeCon + CloudNativeCon Europe in Amsterdam, CloudNativePG was one of only three projects to earn all five available badges: Cleaner, Chronicler, Inspector, Mechanizer and Defender. I was named a Security Champion for leading the effort, but the credit belongs to everyone who contributed. The work left lasting artefacts behind, such as the OpenSSF Best Practices Baseline, a public threat assessment and a SECURITY-INSIGHTS.yml file, which organisations preparing for the EU Cyber Resilience Act will find useful.

We also join good company. At the Incubating tier we find projects such as Keycloak, the reference for cloud-native identity and access management, Longhorn for cloud-native block storage and KubeVirt for virtual machines on Kubernetes. Seeing PostgreSQL stand alongside identity, storage and virtualisation says something about how the cloud-native stack is maturing: the data layer is now a first-class citizen.

Finally, Incubation confirms CloudNativePG as the community-owned, vendor-neutral home for PostgreSQL in the cloud-native ecosystem. The code, the roadmap and the decisions belong to the community, and the project is now expected to prove it, which brings us to governance.

Governance: evolving while keeping technical focus #

Being vendor-neutral is not something you declare once. It is something you keep earning, and CNCF standards push us to make it structural.

Over the next six months we will evolve the project governance, in particular the Steering Committee. We will introduce an organisationally balanced voting system, with a strict cap of two seats per company. The goal is simple: no single company, including mine, should be able to control the direction of the project, and the project must be able to outlive the priorities of any one of its sponsors.

I want to be clear about what this does and does not change. I will keep providing core technical leadership for the operator engine, together with my team at EDB, and I will do everything I can to make sure that role continues. Balanced governance and strong technical stewardship are not in tension. A healthy open source project needs both: a fair process to decide where we go, and a team with the depth to get us there.

The project has also changed shape. In Atlanta I said that CloudNativePG is over 15 projects. Today the GitHub organisation hosts more than 30 active repositories. Around the operator now live extensions, image catalogs, plugins, Helm charts, dashboards and a growing set of peripheral tools. To keep that manageable, we have organised the project into four subprojects: Core, Supply Chain, Community, Docs & Ecosystem, and Extensibility. Each has its own committee of maintainers, so that responsibility sits close to the code and the people who know it best. This lets the wider community innovate across the ecosystem at its own pace, while the core team concentrates on what only the core team can do: the resilience, performance and database primitives of the operator itself.

The maintainer team has grown with it, from 7 when we applied for Incubation to 14 people across four organisations: EDB, GEICO, Upbound and Verito Digital. EDB is still by far the largest contributor, and widening that circle is exactly what balanced governance and the road to Graduation require. The maintainers list is public and kept up to date.

The horizon: KubeCon and Graduation #

Incubation also opens practical doors. It unlocks the official CNCF co-located events, and we are planning a dedicated community presence at KubeCon, including an official CloudNativePG Day. I cannot wait to see adopters, contributors and curious newcomers in the same room, sharing what works and what does not.

Beyond that, Incubation is the bridge to Graduation, the top tier of the CNCF project landscape. It is home to projects such as Kubernetes, Prometheus, Envoy, Helm, Argo CD, OpenTelemetry and Cilium, and also to data projects such as Vitess and TiKV. Graduation is the signal that late-majority enterprises look for before they commit, because it demands a healthy contributor and maintainer base that extends well beyond the founding company. Our plan is to apply for Graduation in 2027, with the goal of achieving it during 2028. It is an ambitious timeline, and it depends on the things we have just discussed: more diverse maintainers, balanced governance and continued adoption in production.

Sandbox in 2025, Incubation in 2026, Graduation in sight. It is still a long way to the top, but the view from this rung is a good one.

Thank you #

This milestone belongs to the entire team of maintainers and contributors, and I thank every one of you. First of all, though, I want to thank the two masterminds behind the operator, in alphabetical order: Leonardo Cecchi and Marco Nenciarini. They have been trusted friends and partners throughout this journey. We worked together at 2ndQuadrant, we built Barman together long before CloudNativePG existed, and we have kept building ever since. The engineering excellence you see in the operator is theirs, and I am proud to have shared the road with them.

Thank you also to the other maintainers, Francesco Canovai and Armando Ruocco, whose work on the operator day after day has been essential to getting here. Francesco is also leading Klio, a new multi-tiered backup and recovery plugin for CloudNativePG, built on the CNPG-I plugin interface. It is a good example of the kind of ecosystem project that the new subproject structure is meant to nurture. Keep an eye on it.

Welcome back to Philippe Scorsolini, an emeritus maintainer who returned to the project. Seeing a former maintainer choose to come back says more about the health of a community than any metric could.

Thank you to our other emeritus maintainer, Jonathan Gonzalez, for everything he contributed to the project. The door is always open, and I hope he will join us again one day.

A warm welcome also goes to the new maintainers who have joined the team, in alphabetical order: Jonathan Battiato, Floor Drees, Gabriele Fedi, Niccolò Fei, Itay Grudev, Tao Li, Tamara Nocentini and Jeremy Schneider. The project is stronger for every one of you, and I look forward to what we will build together.

I also want to thank EDB and the EDB leadership team for supporting me and the team in pursuing a long-term vision, and for trusting that quality is worth the patience.

My sincere thanks also go to the CNCF TOC and the reviewers who dedicated their time to scrutinise the project, to the adopters who trusted us early and shared their stories openly, and to everyone across the wider community who has made CloudNativePG what it is.

If you use CloudNativePG, tell us about it and add your organisation to the adopters list. If you want to contribute, whether with code, documentation, reviews or by helping others, you will find us on GitHub, and everything else, from documentation to release notes, lives on the project website at cloudnative-pg.io. The best part of this journey is still ahead, and we are building it together.

Stay tuned for the upcoming recipes! For the latest updates, consider subscribing to my LinkedIn and Twitter channels.

If you found this article informative, feel free to share it within your network on social media using the provided links below. Your support is immensely appreciated!

This article was drafted and refined with the assistance of Claude (Anthropic). All technical content, corrections and editorial direction are the author’s own.

Cover Picture: “African bush elephants (Loxodonta africana) female with six-week-old baby” by Charles J. Sharp, CC BY-SA 4.0, via Wikimedia Commons. Cropped for this article.