Discussion: CloudNativePG as foundational database infrastructure for software packs

[dcmcand]

Context

Software packs that need PostgreSQL (e.g., Superset, Gitea) currently depend on upstream Helm charts that bundle Bitnami PostgreSQL sub-charts. This dependency is no longer viable.

The Bitnami situation

Effective August 28, 2025, Broadcom moved Bitnami container images behind a paywall (Bitnami Secure Images, starting at $72,000/year). Key impacts:

• All versioned image tags (e.g., bitnami/postgresql:14.17.0-debian-12-r3) were moved to bitnamilegacy/ and will receive no further updates
• Public catalog deletion was set for September 29, 2025
• Only :latest tags remain free, which are unsuitable for production (no version pinning)
• Helm charts on Docker Hub (bitnamicharts/) remain available as OCI artifacts but reference paywalled images
• The chart source code on GitHub remains Apache 2 licensed, but the images they reference are not freely available

This means any Helm chart depending on Bitnami sub-charts for PostgreSQL or Redis is building on a dead foundation. The bitnamilegacy mirrors are frozen and accumulating unpatched CVEs.

Proposal

Add CloudNativePG as an optional foundational service managed by the nebari-operator. Software packs would request managed PostgreSQL databases through the NebariApp CRD, similar to how they request Keycloak clients today with provisionClient: true.

NebariApp CRD extension

spec:
  database:
    enabled: true
    provider: cloudnativepg
    instances: 1
    size: 1Gi

When enabled, the operator would:

1. Create a CloudNativePG Cluster resource
2. Wait for the database to become ready
3. Store connection credentials in a secret (<name>-db-credentials) with keys: host, port, username, password, database, uri
4. Create RBAC allowing the app's ServiceAccount to read the credentials secret

How packs would use it

Packs would reference the operator-created secret via extraEnv or envFrom, disable the bundled Bitnami PostgreSQL sub-chart, and point their database config at the operator-provided credentials. The same pattern already established for OIDC client provisioning.

Why CloudNativePG

• CNCF project - actively maintained, strong community, vendor-neutral governance
• No Bitnami dependency - uses official PostgreSQL Docker images from the PostgreSQL community
• Kubernetes-native - declarative CRDs, no external tools (no Patroni/repmgr/Stolon). Integrates directly with the Kubernetes API for failover
• Production-ready - automated failover, continuous backup to object storage, point-in-time recovery, connection pooling (PgBouncer), rolling updates
• Observability - built-in Prometheus metrics exporter, structured logging
• Security - TLS by default, certificate rotation, RBAC integration
• Resource efficiency - one operator manages all databases across all packs, vs. one Bitnami sub-chart per pack

Considerations

• Adds a new foundational dependency to the Nebari platform (alongside Envoy Gateway, cert-manager, Keycloak)
• Packs still need to work without it for standalone/non-Nebari deployments
• Need a migration path for existing deployments using bundled Bitnami PostgreSQL
• The CloudNativePG operator itself needs lifecycle management

Prior art

This follows the pattern already established for Keycloak - the operator manages a shared platform service and provisions per-app resources (OIDC clients / databases) through the NebariApp CRD.

References

• Bitnami catalog changes announcement (bitnami/charts#35164)
• Bitnami container changes (bitnami/containers#83267)
• CloudNativePG documentation
• CNCF blog: Cloud Neutral Postgres with CloudNativePG

[viniciusdc]

Yes, please, this would be great, though having a toggle might also be nice. NIC should have this as an optional value, and we need docs to better execute adoption.

This has come up recently with more and more adoptions of DB deps on newer Software Packs (SPs)

[viniciusdc]

A situation that I think will be a recurring instance of this came up recently. Someone building a new Postgres-backed application hit an unreachability issue with a third-party-hosted database (IPv6 surface area mismatch with the cluster), and the quickest workaround proposed was to point to the same Postgres instance that another existing agent already used. That instance turned out to be a shared bring-your-own setup, run on a cloud provider by one team member, with a planned move to another cloud for centralization. Adding a new database meant requesting admin access from the person who set it up or asking for a migration plan.

The friction this exposes isn't just "external DB unreachable from the cluster". It's that every contributor with a Postgres-backed pack ends up making the same set of ad-hoc choices independently: pick a provider, pick a hosting location, pick a provisioning workflow. The result is a sprawl of one-off database instances, each owned by whoever set it up and managed with whatever tooling they happen to know. Asking "who manages X?" becomes a form of digital archaeology, and "can you give me access to add a database?" routes back to the original owner every time. Responsibilities are siloed around individuals rather than around the platform.

What this issue gives us is a deterministic, centralized way for any pack to request a Postgres database without coordinating with whoever set up the shared infra: database.enabled: true in the NebariApp CRD. The operator provisions a CNPG Cluster, and credentials land in a per-app Secret. Same self-service shape we already have for OIDC clients. No person-in-the-loop for the routine case, no silo growing around whoever happens to own the current shared instance.

Worth being explicit that this isn't a lock-in. Any pack that has a reason to use its own database elsewhere (managed RDS, a hosted DBaaS, a self-managed cluster) is still free to do that. What this is is a default contract for the common case where a pack just needs "a Postgres I can reach", not a requirement that everything route through CNPG.