5 Best Practices für Postgres in Docker in 2026

Postgres läuft wunderbar in Docker. Die Probleme kommen meistens daher, dass eine Database wie ein stateless Web-App-Container behandelt wird.

Wenn du PostgreSQL in 2026 in Docker nutzt, sind das die fünf wichtigsten Best Practices.

1. Pinne die Postgres Image-Version

Nimm für alles, was dir wichtig ist, nicht postgres:latest. Pinne mindestens die Major Version. Wenn du reproduzierbare Production Builds brauchst, pinne auch die Minor Version.

Für lokale Entwicklung reicht meistens:

docker run -d \
  --name postgres \
  -e POSTGRES_PASSWORD=change-me \
  postgres:17

Für Production-nahe Umgebungen solltest du expliziter sein:

services:
  postgres:
    image: postgres:17.5

Docker Hub listet aktuell gepflegte offizielle Postgres Image Tags, inklusive stabiler Major Tags und Beta Tags. Bevor du eine Minor Version in ein langlebiges Setup kopierst, prüf die offizielle Image Page und nimm die Version, die deine App wirklich unterstützt.

Warum das wichtig ist:

• du vermeidest überraschende Major Upgrades.
• lokale Umgebung, Staging und Production passen zusammen.
• Upgrades passieren bewusst statt aus Versehen.

2. Leg Database Files auf ein echtes Volume

Verlass dich nie auf den beschreibbaren Layer des Containers für Database-Daten. Wenn der Container gelöscht wird, sind die Daten sonst weg.

Nimm ein Docker Volume:

docker volume create pgdata

docker run -d \
  --name postgres \
  -e POSTGRES_USER=myuser \
  -e POSTGRES_PASSWORD=change-me \
  -e POSTGRES_DB=mydb \
  -v pgdata:/var/lib/postgresql/data \
  postgres:17

Oder mit Compose:

services:
  postgres:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_USER: myuser
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: mydb
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Bind Mounts können auch funktionieren, aber Docker Volumes sind meistens der einfachere Default. Docker Volumes sind portabel, gut mit Docker Tools inspizierbar und brechen seltener wegen Host-Dateirechten.

3. Halte Postgres vom öffentlichen Internet fern

Der einfachste Weg, eine Dockerisierte Postgres Instanz abzusichern: Mach sie gar nicht erst öffentlich erreichbar.

Für lokale Entwicklung ist Port Publishing okay:

services:
  postgres:
    image: postgres:17
    ports:
      - "5432:5432"

Für Production ist privates Networking zwischen App und Database besser:

services:
  app:
    image: my-app
    environment:
      DATABASE_URL: postgresql://myuser:change-me@postgres:5432/mydb
    depends_on:
      - postgres

  postgres:
    image: postgres:17
    environment:
      POSTGRES_USER: myuser
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: mydb
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

In diesem Setup erreicht die App Postgres über postgres:5432 im internen Docker Network. Es gibt keinen öffentlichen Database Port, außer du setzt ihn bewusst.

Production Checklist:

• nutz starke Passwörter oder Secret Files.
• beschränk Network Access.
• aktiviere TLS, wenn Clients über unsichere Netzwerke verbinden.
• nutz getrennte Database User für getrennte Apps.

4. Behandle Backups als Teil des Container-Setups

Ein Postgres Container ist keine Backup-Strategie. Ein Docker Volume ist auch keine Backup-Strategie.

Das Minimum sind logische Backups mit pg_dump:

docker exec -t postgres \
  pg_dump -U myuser -d mydb -Fc \
  > backup-$(date +%F).dump

Teste auch den Restore:

cat backup-2026-07-02.dump | docker exec -i postgres \
  pg_restore -U myuser -d mydb --clean --if-exists

Für Production willst du meistens mehr:

• geplante Backups.
• Backup Storage außerhalb des Servers.
• Restore Tests.
• Alerts, wenn Backups fehlschlagen.
• Point-in-Time Recovery, wenn schon ein paar Stunden Datenverlust weh tun würden.

5. Ergänze Health Checks, Metrics und Upgrade-Disziplin

Postgres braucht langweilige Betriebsarbeit. Docker macht den Start einfacher, aber es ersetzt nicht Observability und Maintenance.

Füg einen Health Check hinzu:

services:
  postgres:
    image: postgres:17
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U myuser -d mydb"]
      interval: 30s
      timeout: 5s
      retries: 5

Aktiviere sinnvolle Postgres-Sichtbarkeit:

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Dann beobachte die langweiligen Dinge:

• Disk Usage.
• Memory Pressure.
• lange laufende Queries.
• Connection Count.
• Backup-Freshness.
• Replication Lag, falls du Replicas betreibst.

Für Upgrades gilt: nicht einfach postgres:16 auf postgres:17 ändern und hoffen. Lies die Postgres Release Notes, mach ein Backup, teste das Upgrade auf einer Kopie und plane Zeit für Rollback ein.

Fazit

Docker ist super für Postgres Development und kann auch für Production okay sein, wenn du es wirklich betreibst. Sobald du Backups, Restore Tests, Monitoring, Upgrades, TLS und private Netzwerke nicht selbst besitzen willst, nimm Managed Postgres.

Für den Einstieg lies PostgreSQL in Docker ausführen. Für Backup-Details lies PostgreSQL über SSH-Tunnel sichern und wiederherstellen.