--- title: 'PostgreSQL Helm Chart: So deployst du Postgres auf Kubernetes' description: 'Erfahre, wie du PostgreSQL mit Helm auf Kubernetes deployst, warum Bitnami-Charts problematisch geworden sind und welche Alternativen es gibt.' 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 --- PostgreSQL auf [Kubernetes](/de/blog/what-is-kubernetes) zu betreiben ist heute für viele Teams Alltag. Helm hat sich als Standard-Werkzeug durchgesetzt, um diese Deployments reproduzierbar zu machen. Was dabei oft unterschätzt wird: Stateful Workloads wie Datenbanken verzeihen Konfigurationsfehler weniger als zustandslose Services – und wer bisher blind auf Bitnami-Charts gesetzt hat, steht seit 2025 vor einer unerwarteten Entscheidung. ## Was Helm hier eigentlich macht Helm ist ein Package Manager für Kubernetes. Ein [**Helm Chart**](/de/blog/what-is-a-helm-chart) bündelt alle Kubernetes-Manifeste, die du für ein Deployment brauchst. Dazu gehören Deployments, Services, ConfigMaps, Secrets und PersistentVolumeClaims, zusammengefasst in einem versionierten, konfigurierbaren Paket. Statt dutzende YAML-Dateien manuell zu pflegen, definierst du deine Abweichungen vom Standard in einer `values.yaml` und übergibst den Rest dem Chart. Helm ist einer von mehreren Ansätzen, um [Kubernetes-Konfiguration lesbarer zu machen](/de/blog/simplify-kubernetes-configuration). Für PostgreSQL bedeutet das: Das Chart kümmert sich um StatefulSets, Headless Services für die Peer-Kommunikation, die Einbindung von Persistent Volumes und optionale Replikationskonfigurationen. Du musst das Rad nicht neu erfinden, solltest aber verstehen, was unter der Haube passiert. ## PostgreSQL Helm Chart Deployment – der direkte Weg ### Voraussetzungen Bevor du deployst, solltest du folgendes sicherstellen: - Helm 3.x ist installiert - Du hast `kubectl`-Zugriff auf deinen Cluster - Ein **StorageClass** ist konfiguriert, der dynamisch Persistent Volumes bereitstellen kann - Deine Kubernetes-Version ist kompatibel mit dem gewählten Chart ### Das Chart installieren Mit einem Community-kompatiblen Chart (Details zur Wahl im nächsten Abschnitt) sieht der Basis-Befehl so aus: ```bash helm repo add helm repo update helm install my-postgres /postgresql \ --namespace databases \ --create-namespace \ -f values.yaml ``` Statt alle Parameter als `--set`-Flags zu übergeben, empfiehlt sich eine saubere `values.yaml`. Das macht das Deployment nachvollziehbar, versionierbar und reproduzierbar. ### Wichtige Konfigurationsparameter Drei Bereiche sind in der Praxis am kritischsten: Passwörter gehören nicht direkt in die `values.yaml`. Lege stattdessen Kubernetes Secrets vorher an und referenziere sie im Chart: ```yaml auth: existingSecret: 'my-postgres-secret' secretKeys: adminPasswordKey: 'postgres-password' userPasswordKey: 'user-password' ``` Die Standard-Persistenzkonfiguration reicht für Tests, genügt aber nicht für den Produktionsbetrieb. Definiere Größe und StorageClass explizit: ```yaml primary: persistence: enabled: true size: 50Gi storageClass: 'fast-ssd' ``` Wenn du Hochverfügbarkeit brauchst, lohnt sich ein Read-Replica-Setup: ```yaml architecture: replication readReplicas: replicaCount: 2 ``` Ohne explizite Replikationskonfiguration deployst du eine Einzelinstanz. Das funktioniert, ist aber kein produktionstaugliches Setup. ## Das Bitnami-Problem und was es für dein Setup bedeutet Bitnami hat jahrelang den De-facto-Standard für Helm Charts geliefert. Die Charts waren einfach zu nutzen, gut dokumentiert und hatten eine breite Community. Das hat sich geändert. Seit VMware Bitnami übernommen hat, wurde das Repository-Modell schrittweise umgebaut – ein klassisches Beispiel für [Vendor Lock-in](/de/blog/cloud-vendor-lock-in). Ab August 2025 ist der direkte Zugriff auf das öffentliche Bitnami-Repository für kommerzielle Nutzer eingeschränkt. Wer `helm repo update` in seiner CI/CD-Pipeline ohne Anpassung laufen lässt, riskiert, dass Deployments fehlschlagen – nicht weil der Cluster ein Problem hat, sondern weil das Chart-Repository nicht mehr wie erwartet erreichbar ist. Für bestehende Setups heißt das: Überprüfe, welche deiner Helm Charts von Bitnami stammen. Schau dir an, ob du betroffen bist – und wenn ja, wann dein aktuell gecachtes Chart das letzte Mal erfolgreich geladen wurde. Das ist kein Grund zur Panik, erfordert aber konkretes Handeln. ## Alternativen zum Bitnami PostgreSQL Helm Chart ### Open-Source-Alternativen im Überblick Es gibt funktionstüchtige Alternativen, die aktiv gepflegt werden: Wie du PostgreSQL mit dem Cloudpirates Helm Chart auf lowcloud deployst, zeigt unser Schritt-für-Schritt-Guide. - **Cloudpirates Open Source Helm Charts**: lowcloud stellt eigene, quelloffene Charts bereit – als direkte Antwort auf die Bitnami-Problematik. Die Charts sind auf praxistaugliche Defaults ausgelegt und werden aktiv gewartet. - **Zalando Postgres Operator**: Ein Operator-Ansatz, der über CRDs gesteuert wird. Mächtiger als ein simples Chart, aber auch komplexer in der Einrichtung. - **CloudNativePG Operator**: Der CNCF-gepflegte Postgres-Operator mit starkem Fokus auf Kubernetes-Native-Features wie Streaming-Replikation, Point-in-Time-Recovery und automatische Failover-Szenarien. ### Kriterien für die Wahl des richtigen Charts Die Wahl hängt von deinen Anforderungen ab: | Kriterium | Einfaches Chart | Operator-Ansatz | | ---------------------- | --------------------- | --------------------------- | | Einstiegshürde | Niedrig | Mittel bis hoch | | Flexibilität | Begrenzt | Hoch | | Automatisches Failover | Manuell konfiguriert | Integriert | | Replikationsverwaltung | Statisch | Dynamisch | | Produktionsreife | Gut für kleine Setups | Empfohlen für kritische DBs | Für Teams, die PostgreSQL produktiv und mit Hochverfügbarkeitsanforderungen betreiben wollen, ist ein Operator mittelfristig die solidere Wahl. Für kleinere Services oder Entwicklungsumgebungen reicht ein gut konfiguriertes Chart. ## Persistenz, Backups und Monitoring nicht vergessen Wenn das Deployment läuft, fangen die eigentlichen Operationsaufgaben an. Stelle sicher, dass dein PersistentVolumeClaim an eine StorageClass gebunden ist, die tatsächlich schnelle I/O liefert. Langsame Festplatten sind bei PostgreSQL ein häufiger Performance-Killer, der sich erst unter Last zeigt. Für Backups bleibt `pg_dump` eine valide Lösung bei kleineren Datenbanken. In Kubernetes-nativen Setups lohnt sich ein Blick auf **Velero** für Snapshot-basierte Backups des Persistent Volumes auf [S3-kompatiblem Objektspeicher](/de/blog/s3-compatible-object-storage) oder **Barman** für WAL-Archivierung und Point-in-Time-Recovery. ```bash # Einfacher pg_dump aus einem laufenden Pod kubectl exec -it my-postgres-0 -n databases -- \ pg_dump -U postgres mydb > backup.sql ``` Beim Monitoring ist der **postgres_exporter** der Standardweg, um PostgreSQL-Metriken in Prometheus zu exportieren. Folgende Metriken solltest du im Blick haben: - `pg_stat_activity` – aktive Verbindungen und laufende Queries - `pg_replication_lag` – Replikationsverzögerung bei Read Replicas - `pg_database_size_bytes` – Datenbankwachstum über Zeit Ein Grafana-Dashboard gibt es fertig zum Import – such nach Dashboard-ID `9628` im Grafana-Repository. ## Wann ein Managed-Ansatz die bessere Wahl ist Der Betrieb von PostgreSQL auf Kubernetes ist lösbar, aber er bindet Zeit – besonders bei einer [laufenden Kubernetes-Migration](/de/blog/kubernetes-migration-guide). Jemand muss die Charts aktualisieren, Backups überwachen, Failover-Szenarien testen und sicherstellen, dass Storage-Klassen nach Cluster-Upgrades noch korrekt funktionieren. Für Teams, die sich auf ihre Anwendung konzentrieren wollen statt auf Datenbankinfrastruktur, ist eine [DevOps-as-a-Service-Plattform](/de/blog/devops-as-a-service) wie **lowcloud** eine pragmatische Alternative. PostgreSQL wird dort als verwalteter Service bereitgestellt – auf Basis derselben [souveränen Kubernetes-Infrastruktur](/de/blog/kubernetes-digital-sovereignty), aber ohne den operativen Overhead. Du brauchst keine eigenen Helm Charts zu pflegen, keine manuelle Backup-Konfiguration einzurichten und kein Monitoring-Setup von Grund auf aufzubauen. Das ist kein Ersatz für jeden Use Case. Wer spezifische PostgreSQL-Konfigurationen, eigene Extensions oder volle Kontrolle über jeden Parameter braucht, ist mit dem Eigenbetrieb besser bedient. Für alles andere lohnt sich die Frage: Ist das wirklich ein differenzierender Vorteil für dein Team, oder doch nur notwendiger Overhead? ## Fazit PostgreSQL mit Helm auf Kubernetes zu deployen funktioniert. Die Schritte sind überschaubar, die Konfigurationsoptionen gut dokumentiert. Was sich geändert hat: Die Wahl des richtigen Charts ist keine Selbstverständlichkeit mehr. Wer bisher auf Bitnami gesetzt hat, sollte die eigene CI/CD-Pipeline überprüfen und eine Alternative evaluieren – ob das ein Community-Chart, ein Operator oder ein Managed-Service ist, hängt von den eigenen Anforderungen ab. Die Infrastruktur-Entscheidungen von heute wirken sich direkt auf die Wartbarkeit in zwölf Monaten aus. Wie du PostgreSQL in wenigen Minuten auf lowcloud deployst, zeigt unser PostgreSQL-Guide in der Dokumentation.