[Incubation] CloudNativePG Incubation Application

[gbartolini]

Review Project Moving Level Evaluation

• I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.

CloudNativePG Incubation Application

v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.

Project Repo(s): https://github.com/cloudnative-pg/cloudnative-pg
Project Site: https://cloudnative-pg.io/
Sub-Projects: See https://github.com/cloudnative-pg/governance/blob/main/COMPONENT-OWNERS.md
Communication: #cloudnativepg-users on CNCF Slack

Project points of contacts:

• Armando Ruocco, armando.ruocco@enterprisedb.com, @armru

• Floor Drees, floor.drees@enterprisedb.com, @FloorD

• Francesco Canovai, francesco.canovai@enterprisedb.com, @fcanovai

• Gabriele Bartolini, gabriele.bartolini@enterprisedb.com, @gbartolini

• Jonathan Gonzalez, jonathan.gonzalez@enterprisedb.com, @sxd

• Leonardo Cecchi, leonardo.cecchi@enterprisedb.com, @leonardoce

• Marco Nenciarini, marco.nenciarini@enterprisedb.com, @mnencia

• Philippe Scorsolini, philippe.scorsolini@upbound.io, @phisco

• (Post Incubation only) Book a meeting with CNCF staff to understand project benefits and event resources.

Incubation Criteria Summary for $PROJECT

Application Level Assertion

• This project is currently Sandbox, accepted on 20250121, and applying to Incubation.
• This project is applying to join the CNCF at the Incubation level.

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

See the official Adopters file.

Note: We can also provide large end-users who are yet to become public but could be interested in private conversations with the CNCF TOC.

Application Process Principles

Suggested

N/A

Required

• Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.
  • This was completed and occurred on 25-Sept-2024, and can be discovered at https://www.youtube.com/watch?v=Nsu5Em8Ig88.

• All project metadata and resources are vendor-neutral.

• Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
• Met during Project's application on DD-MMM-YYYY.

• Due Diligence Review.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

  • Installation & upgrade
  • Quickstart
  • Architecture
  • CNPG Playground

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.

Suggested

• Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

  • The project has recently adopted issues in the Governance project with gitvote for public and transparent votes.

• Clear and discoverable project governance documentation.

  • Governance Project

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

  • https://github.com/cloudnative-pg/governance/blob/main/GOVERNANCE.md#maintainers
  • https://github.com/cloudnative-pg/cloudnative-pg/blob/main/CONTRIBUTING.md

• Governance clearly documents vendor-neutrality of project direction.

  • https://github.com/cloudnative-pg/governance/blob/main/GOVERNANCE.md#values

• Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

  • https://github.com/cloudnative-pg/governance/blob/main/GOVERNANCE.md#maintainers

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

  • https://github.com/cloudnative-pg/governance/blob/main/GOVERNANCE.md#project-roles

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

  • https://github.com/cloudnative-pg/governance/blob/main/GOVERNANCE.md#project-roles

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

  • https://github.com/cloudnative-pg/governance/blob/main/GOVERNANCE.md#project-roles

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

  • https://github.com/cloudnative-pg/governance/blob/main/COMPONENT-OWNERS.md

Required

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

  • https://github.com/cloudnative-pg/governance/blob/main/MAINTAINERS.md

• A number of active maintainers which is appropriate to the size and scope of the project.

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

  • Every project has a GOVERNANCE.md file that points to the main one in the governance project. For example, this is the GOVERNANCE.md file for CloudNativePG.

• Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.

  • https://github.com/cloudnative-pg/governance/blob/main/CODE_OF_CONDUCT.md

• CNCF Code of Conduct is cross-linked from other governance documents.

  • Example: CoC from CloudNativePG

• All subprojects, if any, are listed.

  • All projects are listed under the organisation: https://github.com/cloudnative-pg

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.

Suggested

• Contributor ladder with multiple roles for contributors.

  • We currently have only component owners and maintainers as they seem good enough for now. But we might explore different ones before or after incubation. See: https://github.com/cloudnative-pg/governance/blob/main/GOVERNANCE.md#project-roles

Required

• Clearly defined and discoverable process to submit issues or changes.

  • https://github.com/cloudnative-pg/cloudnative-pg/blob/main/CONTRIBUTING.md

• Project must have, and document, at least one public communications channel for users and/or contributors.

  • https://github.com/cloudnative-pg/cloudnative-pg/blob/main/CONTRIBUTING.md
  • https://github.com/cloudnative-pg/cloudnative-pg/tree/main?tab=readme-ov-file#communications

• List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

  • https://github.com/cloudnative-pg/cloudnative-pg/tree/main?tab=readme-ov-file#communications

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

  • https://github.com/cloudnative-pg#cloudnativepg-community-meetings
  • https://zoom-lfx.platform.linuxfoundation.org/meetings/cloudnativepg?view=week

• Documentation of how to contribute, with increasing detail as the project matures.

  • Generic contributions
  • Source contributions
  • Developer Certificate of Origin
  • Developmnet environment setup
  • E2E testing procedure
  • Linux Foundation Mentorship program fro CNPG
  • Release procedure

• Demonstrate contributor activity and recruitment.

  • https://cloudnativepg.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1
  • https://insights.linuxfoundation.org/project/cloudnativepg/contributors?timeRange=past365days
  • https://insights.linuxfoundation.org/project/cloudnativepg/popularity?timeRange=past365days

Engineering Principles

Suggested

• Roadmap change process is documented.

  • https://github.com/cloudnative-pg/cloudnative-pg/blob/main/ROADMAP.md

• History of regular, quality releases.

  • https://github.com/cloudnative-pg/cloudnative-pg/releases

Required

• Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This can also be satisfied by completing a General Technical Review.

  • If applicable a General Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.

  • https://github.com/cloudnative-pg/cloudnative-pg?tab=readme-ov-file#scope

  • https://github.com/cloudnative-pg/cloudnative-pg/blob/main/docs/src/faq.md

• Document what the project does, and why it does it - including viable cloud native use cases. This can also be satisfied by completing a General Technical Review.

  • https://cloudnative-pg.io/documentation/current/
  • https://cloudnative-pg.io/documentation/current/use_cases/
  • https://cloudnative-pg.io/documentation/current/operator_capability_levels/

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

  • https://github.com/cloudnative-pg/cloudnative-pg/blob/main/ROADMAP.md

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This can also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.

  • If applicable a General Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.

  • https://github.com/cloudnative-pg/cloudnative-pg/blob/main/contribute/technical-architecture.md

  • https://cloudnative-pg.io/documentation/current/architecture/

  • https://cloudnative-pg.io/documentation/current/controller/

  • https://cloudnative-pg.io/documentation/current/container_images/

  • https://cloudnative-pg.io/documentation/current/imagevolume_extensions/

• Document the project's release process.

  • Release procedure

Security

Suggested

N/A

Required

Note: this section may be augmented by a joint-assessment performed by TAG Security and Compliance.

• Clearly defined and discoverable process to report security issues.

  • https://github.com/cloudnative-pg/cloudnative-pg/blob/main/SECURITY.md

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

• Document assignment of security response roles and how reports are handled.

  • https://github.com/cloudnative-pg/cloudnative-pg/security

• Document Security Self-Assessment.

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

  • https://www.bestpractices.dev/en/projects/9933

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

  • https://github.com/cloudnative-pg/cloudnative-pg/blob/main/ADOPTERS.md
  • https://cloudnative-pg.io/end_users/

• Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)

The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

• TOC verification of adopters.

Refer to the Adoption portion of this document.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

  • https://cloudnative-pg.io/documentation/current/cncf-projects/external-secrets/
  • https://cloudnative-pg.io/documentation/current/cncf-projects/cilium/
  • https://github.com/cloudnative-pg/postgres-keycloak-oauth-validator

Additional Information

[mbianchidev]

CloudNativePG is one of the projects that I follow closely in the landscape for many different reasons.

• First and foremost it's the demonstration that running Stateful workloads on Kubernetes is more than possible and it's quite easy.
• It's an amazing community that welcomes all the cool and different DB vendors and individual contributors alike
• It attracted quite a lot of buzz when they decided to open their applications for the mentorship program, even with my mentees
• Maintainers are super helpful in answering questions both on Slack and at events in person, where they are more than present and across the globe
• Some of the same maintainers also contribute and collaborate with SIG Storage in Kubernetes

For these reasons I cannot be happier to vouch for what would be their well deserved Incubation level in the CNCF Landscape.

[ianstanton]

I'm excited to support CloudNativePG's application for incubation status. I was fortunate to work with CNPG during my time at Tembo, where we built our platform on top of it, and it proved to be an excellent foundation. The project's quality, stability, and the team's responsiveness were consistently impressive.

Since CNPG joined the Sandbox in January 2025, it's been great to see the project's continued growth and maturation. The comprehensive governance improvements, expanded adopter base, and strong technical foundation they've built make them a solid candidate for incubation. Congratulations to @gbartolini and the entire team on reaching this milestone!

[zoe-tek]

We use CNPG for all of our on prem kubernetes clusters and I am very happy with it and the support provided.

[jpetazzo]

10 years ago, running databases on Kubernetes was not recommended, and you would definitely get weird looks from your fellow SREs if you did it.

5 years ago, running databases on Kubernetes was challenging, but the Kubernetes storage ecosystem was blooming (with the stabilization of the CSI, database operators...) so it was definitely possible, and a viable option, especially for folks running large numbers of database clusters.

Today, running a database on Kubernetes is a totally normal thing to do, and operators like CNPG make it easy for developers (not even DBAs!) to deploy production-grade PostgreSQL databases on regular Kubernetes clusters. With a YAML manifest that fits on a 80x25 screen, we get a PG cluster with multiple replicas, automated failover, automated switchover during node maintenance, backups (giving us easy access to features like Point-In-Time-Recovery), and even the ability to provision database clones in mere seconds thanks to the integration with CSI volume snapshots. Along with Prometheus exporters and Grafana dashboards showing us replication status and tons of other metrics that we didn't have on our previous managed PG provider.

I cannot use enough words to express how grateful I am for the work of the CNPG authors and maintainers for giving us that amazing open source software, and I wholeheartedly support their application for incubation status with the CNCF! 🫶🏻

[CodeAdminDe]

Thanks to CNPG, I've migrated all my databases to Postgres. I use it in all my local and cloud K8s clusters.

The stability, reliability, and production readiness are unmatched. Thanks to CNPG, databases in K8s are finally what they should be - cloud-native!

A must-have in the CNCF portfolio! I without a doubt support their application for incubation status at CNCF! ❤️