Postgres-Replikations-Patterns 2026 — Patroni, Managed Services und die Failover-Story

Es gibt im Wesentlichen drei Wege, Postgres 2026 hochverfügbar zu betreiben: Managed Postgres auf einem Hyperscaler, ein selbst gemanagter Patroni-Cluster, oder ein selbstgebautes Replikations-Skript, das jemand 2019 geschrieben hat. Option drei ist eine Falle.

Wir betreiben Optionen eins und zwei umfassend über Kundenengagements. Welche Sie wählen sollten, hängt davon ab, wie viel operative Kapazität Sie haben und ob Sie Extensions oder RPO/RTO-Zahlen brauchen, die die Managed Services nicht erreichen.

Patroni — die Failover-Semantiken, die zählen

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    maximum_lag_on_failover: 1048576
    synchronous_mode: true
postgresql:
  use_pg_rewind: true

synchronous_mode: true ist RPO=0 im Tausch gegen Commit-Latenz. maximum_lag_on_failover: 1MB heißt, eine veraltete Replica kann nicht promotet werden — die Alternative wäre stiller Datenverlust bei einem echten Ausfall. Diese beiden Einstellungen sind das, was Patronis Failover-Story stärker macht als RDS Multi-AZ.

Der vollständige Beitrag behandelt:

• Trade-offs von Managed Postgres (kein Superuser, Parameter-Group-Limits, vom Anbieter definiertes RPO)
• Patroni-Cluster-Topologie (3 Postgres + 3 etcd oder K8s-Leases)
• Die 30-45-Sekunden-Failover-Sequenz und wie man ttl herunter tunet
• DCS- (etcd-) Partitionsausfälle — die stille Demotion, die alle verwirrt
• Patroni auf Kubernetes via Zalando/Crunchy-Operatoren vs Bare-VMs
• HAProxy- / PgBouncer-Healthchecks gegen Patronis REST-API

Für die meisten Workloads empfehlen wir Managed Postgres. Melden Sie sich, wenn Ihrer nicht passt.