Introduction

If a Bitnami PostgreSQL Helm release does not appear to update the user password after a Helm upgrade, the usual reason is that the chart updated Kubernetes values or secrets but did not reinitialize the existing database contents on the persistent volume. In other words, Helm changed the deployment inputs, but the already-initialized PostgreSQL data directory kept the old credential state.

Understand the Difference Between Secret Values and Database State

A Helm chart can manage:

• Kubernetes Secrets
• StatefulSet environment variables
• container startup configuration

But once PostgreSQL has already initialized its data on a persistent volume, changing a chart value does not automatically rewrite the password inside the database itself.

That is why this sequence often surprises people:

1. install chart with password A
2. data initializes on the volume
3. run helm upgrade with password B
4. application still authenticates with password A

The secret may have changed, but the database state was already established.

Check Whether Persistence Is Reusing Old Data

This issue is strongly associated with persistent volumes. If the same PVC is reused, PostgreSQL starts from the existing data directory instead of bootstrapping from scratch.

That means “change the Helm value and redeploy” is not enough for password rotation by itself.

You should verify:

• whether persistence is enabled
• whether the same PVC is still attached
• whether the secret changed but the database credential did not

Change the Password Inside PostgreSQL

If you need to rotate the password on an existing installation, the reliable fix is to change it in PostgreSQL itself and then keep the secret in sync.

ALTER USER app_user WITH PASSWORD 'new-password';

After that, ensure the Kubernetes Secret and application configuration use the same password. The critical point is that database credential state and chart configuration must converge; updating only one side creates confusion.

Recreate Storage Only If Reinitialization Is Acceptable

If this is a disposable environment and data loss is acceptable, you can remove the existing persistent volume claim and let PostgreSQL initialize again with the new chart values.

That is appropriate for:

• development clusters
• short-lived test environments
• clean rebuild scenarios

It is not the normal answer for production password rotation because it throws away state.

Treat Password Rotation as an Application Operation

For stateful services, password changes are often operational tasks, not mere config updates. A safe rotation plan usually includes:

• updating the database password
• updating the Kubernetes Secret
• updating dependent applications
• verifying new connections succeed
• removing any old credential fallback

Thinking of this as a real state change rather than a simple Helm diff leads to fewer surprises.

Common Pitfalls

• Assuming a Helm value change automatically mutates credentials inside an existing PostgreSQL data directory.
• Updating the Kubernetes Secret but not the actual database user password.
• Rotating the database password without updating dependent applications or connection secrets.
• Deleting storage in an environment where preserving database state matters.
• Treating stateful chart upgrades as though they behave like stateless config rollouts.

Summary

• With persistent storage, a Bitnami PostgreSQL chart upgrade may not change the effective database password.
• Helm values and Secrets do not automatically rewrite existing database state.
• For existing data, rotate the password inside PostgreSQL and keep secrets aligned.
• Recreating storage only makes sense when reinitialization is acceptable.
• Stateful credential changes should be handled as operational workflows, not just chart edits.