Alternatives to the Bitnami PostgreSQL Helm Chart

The short answer

For most teams the best alternative to the Bitnami PostgreSQL Helm chart is CloudNativePG: an Apache 2.0 operator, a CNCF Sandbox project, with failover built in, backups to object storage, and an import that copies data out of the Bitnami database and can upgrade the major version on the way. Zalando's postgres-operator and Crunchy PGO are mature Patroni-based alternatives. The official postgres image in a plain StatefulSet suits single instances where you do not need failover.

All four support PostgreSQL 14 to 18 only. If the Bitnami release runs 11, 12 or 13, either the migration includes a major-version upgrade, or you keep the chart and swap its image for one that is still maintained: Bitnami Secure Images for current versions, or OSSeva's Bitnami-compatible image for 11 to 14.

Why the chart needs replacing at all

The chart source is still on GitHub under Apache 2.0, and packaged releases still sit at docker.io/bitnamicharts. The problem is the image. Versioned bitnami/postgresql tags were deleted on 29 September 2025, and the copies in bitnamilegacy have not been updated since August 2025. If your pods are already failing to pull, start with fixing ImagePullBackOff after the Bitnami change, then come back to choose a replacement.

Bitnami PostgreSQL chart alternatives compared

Checked against each project's own repository and documentation on 6 October 2026.

CloudNativePG

CloudNativePG runs each database as a Cluster resource. The operator places a primary and replicas, and its instance manager promotes a replica when the primary fails, without an external tool such as Patroni. Backups go to object storage through the Barman Cloud Plugin, or to Kubernetes volume snapshots. Since 1.26, the older built-in barmanObjectStore settings are deprecated in favour of the plugin, so new clusters should start on the plugin.

The useful part for a Bitnami migration is bootstrap.initdb.import. It connects to an existing PostgreSQL over the network, runs pg_dump and pg_restore, and works with a source on an older major version, so a Bitnami database on 13 can land on 17 or 18 in one step. It is an offline import: stop writes to the source, or plan to catch up afterwards. A minimal cluster that imports one database from a Bitnami release:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: app-db
spec:
  instances: 3
  storage:
    size: 20Gi
  bootstrap:
    initdb:
      import:
        type: microservice
        databases:
          - app
        source:
          externalCluster: bitnami
  externalClusters:
    - name: bitnami
      connectionParameters:
        host: my-postgresql.data.svc
        user: postgres
        dbname: postgres
      password:
        name: my-postgresql          # the Bitnami release's secret
        key: postgres-password

The CloudNativePG documentation advises against its pg_basebackup bootstrap for databases outside its own clusters and recommends the logical import instead. CloudNativePG supports PostgreSQL 14 to 18 and stopped supporting 13 on 13 November 2025.

Zalando postgres-operator

Zalando's operator manages a postgresql resource and runs each pod on Spilo, an image that bundles PostgreSQL with Patroni for failover and WAL-G or WAL-E for backups and point-in-time recovery. It is actively released: v2.0.3 shipped on 2 October 2026, and the v2.0 line supports PostgreSQL 14 to 18. One thing to know before adopting it: the Spilo README says the project does not make regular releases or publish latest images, so pin the Spilo image the operator release names.

The operator can clone from an S3 backup or from another cluster in the same namespace, and can run a standby that streams from a remote primary, but only when source and target are on the same major version. From a Bitnami release, a dump and restore is usually simpler.

Crunchy PGO

PGO manages a PostgresCluster resource, uses Patroni for failover and pgBackRest for backups, and the 6.0 releases support PostgreSQL 14 to 18. The operator source is Apache 2.0. The container images are a separate matter: the README says images downloaded from the Crunchy Data Developer Portal are subject to the Crunchy Data Developer Program terms, and those terms require a support subscription for production use at organisations with 50 or more employees and do not permit redistribution. Read them before you choose PGO for production.

For migration, PGO can run a standby cluster that streams from an existing host, restore from a pgBackRest repository, or use logical replication between clusters.

The official postgres image with a StatefulSet

For a single instance, development, or a team that wants no operator, the official postgres image in a StatefulSet is the least machinery. It needs only POSTGRES_PASSWORD; POSTGRES_USER defaults to postgres and POSTGRES_DB to the user's name. There is no failover, replication or backup scheduling, so you add those yourself.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 1
  selector:
    matchLabels: { app: postgres }
  template:
    metadata:
      labels: { app: postgres }
    spec:
      containers:
        - name: postgres
          image: postgres:17
          env:
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef: { name: postgres-auth, key: password }
            - name: PGDATA
              value: /var/lib/postgresql/data/pgdata
          ports:
            - containerPort: 5432
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 20Gi

Two version details matter. The image stopped publishing PostgreSQL 13 when it reached end of life on 13 November 2025, so the oldest tag is 14. And from PostgreSQL 18 the image's PGDATA is version-specific, /var/lib/postgresql/18/docker, with the volume at /var/lib/postgresql; the /var/lib/postgresql/data mount above applies to 17 and earlier.

Keeping the chart: Bitnami Secure Images or OSSeva

If rewriting the deployment is not worth it now, keep bitnami/postgresql and change only the image. Broadcom says Bitnami Secure Images work with the same charts, and the subscription covers stable tags and long-term support versions; prices are by quote. Broadcom does not publish what happens to a PostgreSQL major version after its community end of life, so ask for that in writing if you run 13 or 14.

OSSeva's Bitnami-compatible PostgreSQL image covers PostgreSQL 11 to 14, including the versions past community end of life, with backported security and data-corruption fixes. It keeps the Bitnami variables, the /bitnami/postgresql data path and the non-root user, so the change is image.registry, image.repository and image.tag on the chart version you already run. That page lists which chart versions defaulted to which PostgreSQL line and how postgresql-ha differs. For the support behind it, see OSSeva for PostgreSQL.

What to check before migrating off the Bitnami chart

• Data directory. The chart keeps data at /bitnami/postgresql/data on a volume mounted at /bitnami/postgresql. The official image and the operators expect their own paths and users, so a new deployment starts on a new volume, filled by import or restore. Mounting the old volume under a different image starts an empty database, or fails on file ownership.
• Credentials. The chart passes credentials as POSTGRES_* variables, but on the Bitnami image POSTGRES_USER creates an additional user and postgres stays the superuser. On the official image, POSTGRES_USER is the superuser. Map users and passwords explicitly, and read the release's secret (postgres-password, password) before you uninstall it.
• Values that become configuration. primary.initdb.scripts, postgresqlSharedPreloadLibraries (pgaudit by default) and any primary.extendedConfiguration need an equivalent in the new setup, or behaviour changes quietly.
• Major version. If the source is 11, 12 or 13, decide whether the migration is also the upgrade. The major version upgrade guide covers the methods, and PostgreSQL backup, recovery and high availability covers what to put in place afterwards.

Frequently asked questions

What is the best alternative to the Bitnami PostgreSQL Helm chart?

CloudNativePG for most new deployments: Apache 2.0, built-in failover, object-storage backups, and a logical import that copies data out of the Bitnami database. Zalando's operator and Crunchy PGO are mature Patroni-based options. To keep the existing chart, swap only the image, to Bitnami Secure Images or to OSSeva's drop-in image for PostgreSQL 11 to 14.

Can I migrate from the Bitnami PostgreSQL chart to CloudNativePG without downtime?

The built-in import is offline: it uses pg_dump and pg_restore, so writes to the source should stop while it runs. For a near-zero cutover, set up logical replication from the Bitnami database to the new cluster and switch once it has caught up.

Which Bitnami chart alternatives support PostgreSQL 13 or older?

Of the open source options, none: CloudNativePG, Zalando's v2.0 operator and PGO 6.0 support 14 to 18, and the official image no longer publishes 13. For 11, 12 or 13, upgrade during the migration, or keep the chart with a maintained image that still covers that version, such as OSSeva's.

Bitnami Helm charts replacement for RabbitMQ, Kafka and PostgreSQL?

The usual operator replacements are CloudNativePG for PostgreSQL, Strimzi for Kafka and the RabbitMQ Cluster Operator for RabbitMQ. To keep the Bitnami charts, OSSeva's drop-in images cover PostgreSQL, Kafka and RabbitMQ, including Kafka 3.x on ZooKeeper and RabbitMQ 3.8 to 3.13.

Is the Bitnami PostgreSQL chart still maintained?

The chart source is still on GitHub under Apache 2.0, but its versioned images were removed from docker.io/bitnami and the free copies in bitnamilegacy receive no updates. Running it in production means supplying a maintained image.