Bitnami PostgreSQL alternative
Replacing bitnamilegacy/postgresql

Bitnami PostgreSQL variables and their official equivalents

Bitnami PostgreSQL image to official postgres:

What breaks when you switch

• The volume is mounted at /bitnami/postgresql. The official image looks under /var/lib/postgresql, so an unchanged volume mount starts an empty database.
• Bitnami's replication variables (POSTGRESQL_REPLICATION_*) have no official equivalent; replication has to be configured explicitly or handed to an operator.
• The Bitnami image runs as a non-root user. Check ownership of existing volumes before switching users.

bitnami/postgresql Helm chart values the drop-in image reads

The bitnami/postgresql chart passes credentials under the POSTGRES_* names, which the Bitnami image accepts as aliases for its own POSTGRESQL_* variables. The official postgres image uses the same names with a different meaning. There, POSTGRES_USER becomes the superuser. On the Bitnami image it creates an extra user, postgres stays the superuser, and the chart sends that password separately as POSTGRES_POSTGRES_PASSWORD. The OSSeva image keeps the Bitnami meaning, which is what the chart was written for. Chart 11.0.0 regrouped the older flat values (postgresqlUsername, postgresqlPassword, postgresqlDatabase, replication.enabled) under auth and architecture; both layouts render the variables below. Checked against chart 10.16.3 (PostgreSQL 11) and 11.9.13 (PostgreSQL 14).

PostgreSQL versions OSSeva publishes

Each line below has a patched OSSeva image. The second column shows which bitnami/postgresql chart releases defaulted to that line, which tells you the chart major to stay on during the swap.

Replication and high availability in the PostgreSQL charts

What happened to the Bitnami PostgreSQL image

How to migrate PostgreSQL off Bitnami safely

1. Find every reference to bitnami/postgresql and bitnamilegacy/postgresql in running workloads, Helm values files and CI pipelines, including init containers.
2. Record the PostgreSQL version each deployment pins. Versions past upstream end of life are not covered by the free open source images.
3. Take a backup and test a restore before touching a stateful workload.
4. Mirror the replacement container images into your own registry, and scan them before you deploy.
5. Move one replica or one environment at a time, and confirm the data path, file ownership and credentials on the new image.
6. Remove every remaining legacy reference so nothing falls back to the archive on the next deploy.

Your options

Repoint the Bitnami PostgreSQL Helm chart

1. Run helm list to record the chart version, then helm get values <release> to save what is deployed.
2. Keep that chart version. bitnami/postgresql 12.x moves the default to PostgreSQL 15, and a major version change needs pg_upgrade or a dump and restore, not a rolling restart.
3. Override image.registry, image.repository and image.tag, with the tag on the same major version as the data directory. PostgreSQL will not start on a data directory written by another major version.
4. Leave out global.security.allowInsecureImages. Bitnami added that image check in December 2024 (postgresql 16.3.0), and every chart that ships PostgreSQL 11 to 14 is older.
5. Run helm upgrade with --reuse-values and the override. Afterwards, SELECT version() should show the new build, and pg_stat_replication on the primary should list every read replica.

# values-osseva.yaml
# helm upgrade my-postgresql oci://registry-1.docker.io/bitnamicharts/postgresql \
#   --version 11.9.13 --reuse-values -f values-osseva.yaml
image:
  registry: registry.example.com   # OSSeva registry or your mirror of it
  repository: postgresql
  tag: "<14.x tag>"                # same major version as the data directory
global:
  imagePullSecrets:
    - registry-credentials

This works only with an image that keeps Bitnami's layout. With the official image, rewrite the chart or move to an operator. See replacing bitnamilegacy images for the full inventory and rollout steps.