---
title: 'PostgreSQL Helm Chart: How to Deploy Postgres on Kubernetes'
description: 'Learn how to deploy PostgreSQL with Helm on Kubernetes, why Bitnami charts have become problematic, and what alternatives are available.'
image:
  src: /images/blog/postgresql-helm-chart-kubernetes.jpg
authors:
  - name: Fabian Sander
    to: /about/fabiansander
    avatar:
      src: /images/blog/authors/fabian.png
date: 2026-03-16
tags:
lastUpdated: 2026-04-13
published: true
---

Running PostgreSQL on [Kubernetes](/en/blog/what-is-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](/en/blog/what-is-a-helm-chart). 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:

```bash
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:

```yaml
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:

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

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

```yaml
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](/en/blog/cloud-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:

| Criterion              | Simple Chart          | Operator Approach            |
| ---------------------- | --------------------- | ---------------------------- |
| Barrier to entry       | Low                   | Medium to high               |
| Flexibility            | Limited               | High                         |
| Automatic failover     | Manually configured   | Built-in                     |
| Replication management | Static                | Dynamic                      |
| Production readiness   | Good for small setups | Recommended for critical DBs |

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](/en/blog/s3-compatible-object-storage), or **Barman** for WAL archiving and point-in-time recovery.

```bash
# 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](/en/blog/devops-as-a-service) like **lowcloud** is a pragmatic alternative. PostgreSQL is provided as a managed service — built on the same [sovereign Kubernetes infrastructure](/en/blog/kubernetes-digital-sovereignty), 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.