Patrones de replicación de Postgres en 2026 — Patroni, servicios gestionados y la historia del failover

Hay esencialmente tres formas de correr Postgres en alta disponibilidad en 2026: Postgres gestionado en un hyperscaler, un clúster Patroni autogestionado, o un script de replicación a medida que alguien escribió en 2019. La opción tres es una trampa.

Operamos las opciones uno y dos extensamente a través de engagements de clientes. Cuál elegir depende de la capacidad operativa que tenga y de si necesita extensiones o números de RPO/RTO que los servicios gestionados no pueden alcanzar.

Patroni — las semánticas de failover que importan

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

synchronous_mode: true es RPO=0 a cambio de latencia de commit. maximum_lag_on_failover: 1MB significa que una replica retrasada no puede ser promovida — la alternativa es pérdida silenciosa de datos en una caída real. Estos dos ajustes son lo que hace que la historia de failover de Patroni sea más sólida que la de RDS Multi-AZ.

El artículo completo cubre:

• Trade-offs del Postgres gestionado (sin superuser, límites de parameter group, RPO definido por el proveedor)
• Topología de clúster Patroni (3 Postgres + 3 etcd o leases K8s)
• La secuencia de failover de 30-45 segundos y cómo ajustar ttl a la baja
• Fallos de partición del DCS (etcd) — la democión silenciosa que confunde a todos
• Patroni sobre Kubernetes vía operadores Zalando/Crunchy vs VMs desnudas
• Health checks HAProxy / PgBouncer contra la API REST de Patroni

Para la mayoría de cargas recomendamos Postgres gestionado. Háblanos si el suyo no encaja.