PostgreSQL Helm Chart: How to Deploy Postgres on Kubernetes

Running PostgreSQL on Kubernetes has become standard practice for many teams. Helm has established itself as the go-to tool for making these deployments reproducible. What's often underestimated: stateful workloads like databases are far less forgiving of configuration mistakes than stateless services — and those who have blindly relied on Bitnami charts now face an unexpected decision since 2025.

What Helm actually does here

Helm is a package manager for Kubernetes. A Helm Chart bundles all the Kubernetes manifests you need for a deployment. That includes Deployments, Services, ConfigMaps, Secrets, and PersistentVolumeClaims — all wrapped into a versioned, configurable package. Instead of manually maintaining dozens of YAML files, you define your deviations from the defaults in a values.yaml and let the chart handle the rest.

For PostgreSQL, this means the chart takes care of StatefulSets, Headless Services for peer communication, Persistent Volume integration, and optional replication configurations. You don't need to reinvent the wheel — but you should understand what's happening under the hood.

PostgreSQL Helm Chart deployment — the direct path

Prerequisites

Before you deploy, make sure you have the following in place:

• Helm 3.x installed
• kubectl access to your cluster
• A StorageClass configured that can dynamically provision Persistent Volumes
• A Kubernetes version compatible with the chosen chart

Installing the chart

Using a community-compatible chart (more on choosing one in the next section), the basic command looks like this:

helm repo add <repo-name> <repo-url>
helm repo update

helm install my-postgres <repo-name>/postgresql \
  --namespace databases \
  --create-namespace \
  -f values.yaml

Rather than passing every parameter as --set flags, use a proper values.yaml. This keeps the deployment traceable, version-controlled, and reproducible.

Key configuration parameters

Three areas are most critical in practice:

Passwords don't belong directly in your values.yaml. Instead, create Kubernetes Secrets upfront and reference them in the chart:

auth:
  existingSecret: 'my-postgres-secret'
  secretKeys:
    adminPasswordKey: 'postgres-password'
    userPasswordKey: 'user-password'

The default persistence configuration works for testing but isn't suitable for production. Define size and StorageClass explicitly:

primary:
  persistence:
    enabled: true
    size: 50Gi
    storageClass: 'fast-ssd'

If you need high availability, a read replica setup is worth considering:

architecture: replication
readReplicas:
  replicaCount: 2

Without explicit replication configuration, you're deploying a single instance. That works — but it's not production-grade.

The Bitnami problem and what it means for your setup

For years, Bitnami delivered the de facto standard for Helm Charts. Their charts were easy to use, well-documented, and backed by a broad community. That has changed.

Since VMware acquired Bitnami, the repository model has been gradually restructured — a concrete example of vendor lock-in. As of August 2025, direct access to the public Bitnami repository is restricted for commercial users. If you're running helm repo update in your CI/CD pipeline without adjustments, you risk deployment failures — not because of a cluster issue, but because the chart repository is no longer accessible as expected.

For existing setups, this means: check which of your Helm Charts come from Bitnami. Determine whether you're affected — and if so, when your currently cached chart was last successfully pulled.

No reason to panic, but it does require concrete action.

Alternatives to the Bitnami PostgreSQL Helm Chart

Open-source alternatives at a glance

There are fully functional alternatives that are actively maintained:

For a hands-on walkthrough of deploying PostgreSQL with the Cloudpirates Helm Chart on lowcloud, check out our step-by-step guide.

• Cloudpirates Open Source Helm Charts: lowcloud provides its own open-source charts as a direct response to the Bitnami situation. The charts are designed with practical defaults and are actively maintained.
• Zalando Postgres Operator: An operator approach controlled via CRDs. More powerful than a simple chart, but also more complex to set up.
• CloudNativePG Operator: The CNCF-maintained Postgres operator with a strong focus on Kubernetes-native features like streaming replication, point-in-time recovery, and automatic failover.

Criteria for choosing the right chart

The choice depends on your requirements:

For teams running PostgreSQL in production with high-availability requirements, an operator is the more robust choice in the medium term. For smaller services or development environments, a well-configured chart is sufficient.

Don't forget persistence, backups, and monitoring

Once the deployment is running, the real operational work begins.

Make sure your PersistentVolumeClaim is bound to a StorageClass that actually delivers fast I/O. Slow disks are a common PostgreSQL performance killer that only shows up under load.

For backups, pg_dump remains a valid solution for smaller databases. In Kubernetes-native setups, consider Velero for snapshot-based backups of the Persistent Volume on S3-compatible object storage, or Barman for WAL archiving and point-in-time recovery.

# Simple pg_dump from a running pod
kubectl exec -it my-postgres-0 -n databases -- \
  pg_dump -U postgres mydb > backup.sql

For monitoring, postgres_exporter is the standard way to export PostgreSQL metrics to Prometheus. Key metrics to watch:

• pg_stat_activity — active connections and running queries
• pg_replication_lag — replication delay for read replicas
• pg_database_size_bytes — database growth over time

A ready-made Grafana dashboard is available for import — search for Dashboard ID 9628 in the Grafana repository.

When a managed approach is the better choice

Running PostgreSQL on Kubernetes is solvable, but it takes time. Someone has to update the charts, monitor backups, test failover scenarios, and ensure storage classes still work correctly after cluster upgrades.

For teams that want to focus on their application rather than database infrastructure, a DevOps as a Service platform like lowcloud is a pragmatic alternative. PostgreSQL is provided as a managed service — built on the same sovereign Kubernetes infrastructure, but without the operational overhead. You don't need to maintain your own Helm Charts, set up manual backup configurations, or build a monitoring setup from scratch.

This isn't a replacement for every use case. If you need specific PostgreSQL configurations, custom extensions, or full control over every parameter, self-hosting is the better path. For everything else, it's worth asking: is this really a differentiating advantage for your team, or just necessary overhead?

Conclusion

Deploying PostgreSQL with Helm on Kubernetes works. The steps are manageable, the configuration options well-documented. What has changed: choosing the right chart is no longer a given. If you've been relying on Bitnami, you should review your CI/CD pipeline and evaluate an alternative — whether that's a community chart, an operator, or a managed service depends on your own requirements.

The infrastructure decisions you make today directly impact maintainability twelve months from now.

To deploy PostgreSQL on lowcloud in minutes, follow our PostgreSQL guide in the documentation.