Padrões de replicação Postgres em 2026 — Patroni, serviços gerenciados e a história do failover

Existem essencialmente três formas de rodar Postgres em alta disponibilidade em 2026: Postgres gerenciado em um hyperscaler, um cluster Patroni autogerenciado, ou um script de replicação caseiro que alguém escreveu em 2019. A opção três é uma armadilha.

Operamos as opções um e dois extensivamente em engagements de clientes. Qual escolher depende de quanta capacidade operacional você tem e se precisa de extensões ou números de RPO/RTO que os serviços gerenciados não atingem.

Patroni — as semânticas de failover que importam

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

synchronous_mode: true é RPO=0 em troca de latência de commit. maximum_lag_on_failover: 1MB significa que uma replica atrasada não pode ser promovida — a alternativa é perda silenciosa de dados em um outage real. Essas duas configurações são o que torna a história de failover do Patroni mais forte que o RDS Multi-AZ.

O artigo completo cobre:

• Trade-offs do Postgres gerenciado (sem superuser, limites de parameter group, RPO definido pelo vendor)
• Topologia de cluster Patroni (3 Postgres + 3 etcd ou leases K8s)
• A sequência de failover de 30-45 segundos e como ajustar ttl para baixo
• Falhas de partição do DCS (etcd) — a demoção silenciosa que confunde todo mundo
• Patroni em Kubernetes via operadores Zalando/Crunchy vs VMs puras
• Health checks HAProxy / PgBouncer contra a API REST do Patroni

Para a maioria das cargas recomendamos Postgres gerenciado. Fale conosco se o seu não se encaixa.