Patterns de réplication Postgres en 2026 — Patroni, services managés et l'histoire du failover

Il y a essentiellement trois façons de faire tourner Postgres en haute dispo en 2026 : Postgres managé chez un hyperscaler, un cluster Patroni auto-managé, ou un script de réplication custom que quelqu'un a écrit en 2019. L'option trois est un piège.

Nous faisons tourner les options un et deux abondamment sur les engagements clients. Laquelle choisir dépend de la capacité opérationnelle dont vous disposez et de si vous avez besoin d'extensions ou de chiffres RPO/RTO que les services managés ne peuvent atteindre.

Patroni — les sémantiques de failover qui comptent

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

synchronous_mode: true, c'est RPO=0 contre une latence de commit. maximum_lag_on_failover: 1MB signifie qu'une replica en retard ne peut pas être promue — l'alternative est une perte de données silencieuse lors d'une vraie panne. Ces deux réglages sont ce qui rend l'histoire de failover de Patroni plus solide que RDS Multi-AZ.

L'article complet couvre :

• Trade-offs du Postgres managé (pas de superuser, limites de parameter group, RPO défini par le vendeur)
• Topologie de cluster Patroni (3 Postgres + 3 etcd ou leases K8s)
• La séquence de failover de 30-45 secondes et comment tuner ttl à la baisse
• Les pannes de partition du DCS (etcd) — le démotion silencieux qui confond tout le monde
• Patroni sur Kubernetes via les opérateurs Zalando/Crunchy vs VMs nues
• Health checks HAProxy / PgBouncer contre l'API REST de Patroni

Pour la plupart des workloads, nous recommandons Postgres managé. Contactez-nous si le vôtre ne rentre pas dans la case.