5 Dinge, die du vor Postgres in Docker in 2026 wissen solltest

Docker ist einer der einfachsten Wege, Postgres lokal laufen zu lassen. Du kannst in Sekunden eine Database starten, deine App verbinden, Migrations testen und danach alles wieder wegwerfen.

Aber Postgres bleibt eine Database. Wenn du sie wie einen wegwerfbaren Web-Container behandelst, verlierst du irgendwann Daten.

Hier sind fünf Dinge, die du wissen solltest, bevor du Postgres in 2026 in Docker laufen lässt.

1. Für lokale Entwicklung reicht ein Docker Command

Für eine schnelle lokale Database:

docker run -d \
  --name postgres-container \
  -e POSTGRES_USER=myuser \
  -e POSTGRES_PASSWORD=mypassword \
  -e POSTGRES_DB=mydb \
  -p 5432:5432 \
  postgres:17

Der Command macht einiges:

• --name postgres-container gibt dem Container einen stabilen Namen.
• POSTGRES_USER erstellt einen Database User.
• POSTGRES_PASSWORD setzt das Passwort für diesen User.
• POSTGRES_DB erstellt die erste Database.
• -p 5432:5432 macht Postgres auf deinem Rechner erreichbar.
• postgres:17 nutzt das offizielle Postgres Docker Image mit gepinnter Major Version.

Prüf, ob der Container läuft:

docker ps

Verbinde dich direkt im Container:

docker exec -it postgres-container psql -U myuser -d mydb

Oder von deinem Rechner aus, wenn du psql installiert hast:

psql -h localhost -p 5432 -U myuser -d mydb

Für lokale Entwicklung reicht das meistens.

2. Ohne Volume sind deine Daten wegwerfbar

Der häufigste Docker/Postgres-Fehler ist fehlender persistenter Storage.

Dieser Command startet Postgres mit einem Docker Volume:

docker volume create pgdata

docker run -d \
  --name postgres-container \
  -e POSTGRES_USER=myuser \
  -e POSTGRES_PASSWORD=mypassword \
  -e POSTGRES_DB=mydb \
  -p 5432:5432 \
  -v pgdata:/var/lib/postgresql/data \
  postgres:17

Der wichtige Teil ist:

-v pgdata:/var/lib/postgresql/data

Das speichert das Postgres Data Directory in einem Docker Volume namens pgdata. Wenn du den Container löschst und neu erstellst, können die Daten überleben, weil sie außerhalb des Container Layers liegen.

Volumes inspizieren:

docker volume ls
docker volume inspect pgdata

Für Development sind Docker Volumes meistens einfacher als Bind Mounts. Für Production ist weniger wichtig, welche Volume-Art du nutzt. Wichtiger ist, ob der Storage durable, gebackupt, überwacht und wiederherstellbar ist.

3. Docker Compose ist besser, sobald eine App dazukommt

Sobald deine App mit Postgres sprechen muss, nimm Docker Compose. Du bekommst wiederholbare Config und ein internes Network zwischen den Services.

Erstell compose.yml:

services:
  postgres:
    image: postgres:17
    container_name: postgres-container
    restart: unless-stopped
    environment:
      POSTGRES_USER: myuser
      POSTGRES_PASSWORD: mypassword
      POSTGRES_DB: mydb
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U myuser -d mydb"]
      interval: 30s
      timeout: 5s
      retries: 5

volumes:
  pgdata:

Starte es:

docker compose up -d

Stoppe es:

docker compose down

Wenn ein anderer Container zur Database verbinden muss, pack ihn in dieselbe Compose-Datei und nutz den Service-Namen als Host:

services:
  app:
    image: my-app
    environment:
      DATABASE_URL: postgresql://myuser:mypassword@postgres:5432/mydb
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:17

Im Compose Network ist der Database Host postgres, nicht localhost.

4. Backups sind etwas anderes als Docker Volumes

Ein Docker Volume schützt dich davor, versehentlich den Container zu löschen. Es schützt dich nicht vor:

• falschen DELETE Statements.
• kaputten Daten.
• Serververlust.
• einer schlechten Migration.
• einer vollen Disk.

Erstell ein logisches Backup mit pg_dump:

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

Restore in eine bestehende Database:

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

Für alles Wichtige: plane Backups, speichere sie außerhalb des Servers und teste Restores. Ein Backup, das du nie restored hast, ist hauptsächlich eine Datei, die dich beruhigt.

5. Docker Postgres ist super für Development, aber Production ist mehr Arbeit

Postgres in Docker lokal zu starten ist einfach. Postgres in Docker für Production zu betreiben ist Ops-Arbeit.

Bevor du es für eine echte App nutzt, brauchst du Antworten auf:

• wo Backups gespeichert werden.
• wie Restores getestet werden.
• wer Disk Usage beobachtet.
• wie Postgres Upgrades laufen.
• wie Security Updates eingespielt werden.
• wie Clients privat verbinden.
• was passiert, wenn der Host stirbt.

Self-Hosting kann trotzdem richtig sein. Es ist günstig, flexibel und lehrreich. Sei nur ehrlich, wie viel Arbeit dazugehört.

Nimm Managed Postgres, wenn du die Database willst und nicht den Database-Betrieb.

FAQ

Kann ich mehrere Postgres Container gleichzeitig laufen lassen?

Ja. Nutze unterschiedliche Container-Namen, unterschiedliche Host Ports und unterschiedliche Volumes:

docker run -d \
  --name postgres-two \
  -e POSTGRES_USER=myuser \
  -e POSTGRES_PASSWORD=mypassword \
  -e POSTGRES_DB=mydb \
  -p 5433:5432 \
  -v pgdata2:/var/lib/postgresql/data \
  postgres:17

Sollte ich postgres:latest nutzen?

Nein. Nimm eine gepinnte Major Version wie postgres:17, oder eine gepinnte Minor Version, wenn du reproduzierbare Builds brauchst. Major Upgrades sollten bewusst passieren.

Kann ich das in Production nutzen?

Ja, aber nur wenn du Backups, Restores, Monitoring, Storage, Security und Upgrades wirklich besitzt. Für viele kleine Teams ist Managed Postgres der bessere Tradeoff.

Was sollte ich als Nächstes lesen?

Lies 5 Best Practices für Postgres in Docker für die Production Checklist und 5 günstige Möglichkeiten, Postgres zu hosten, wenn du Hosting-Optionen vergleichst.