¿Cómo funciona la replicación en PostgreSQL?

Question

Accepted Answer

**Replicación** copia datos de una base de datos **principal** a uno o más servidores **réplica** (standby) — para alta disponibilidad (failover si falla la principal) y escalado de lectura (distribuir consultas de lectura). PostgreSQL utiliza principalmente **replicación por streaming** (física) basada en el write-ahead log (WAL).

## Replicación por streaming (física)

```text
Primary  ──(streams WAL: the write-ahead log of changes)──▶  Replica(s)
  ✓ The primary handles all WRITES
  ✓ Replicas continuously apply the primary's WAL → stay in sync (near-real-time)
  ✓ Replicas can serve READ queries ("hot standby") → scale reads
```

La principal transmite su **WAL** (write-ahead log — un registro de cada cambio) a las réplicas, que lo aplican para mantenerse sincronizadas. Las réplicas son copias de solo lectura que pueden servir consultas de lectura.

## Los beneficios: HA y escalado de lectura

```text
HIGH AVAILABILITY → if the primary fails, a replica can be PROMOTED to primary (failover)
  → minimal downtime, no data loss (with synchronous replication)
READ SCALING → route read-only queries to replicas → offload the primary
  → handle more read traffic (great for read-heavy workloads)
BACKUPS → take backups from a replica without loading the primary
```

## Replicación síncrona vs asíncrona

```text
ASYNCHRONOUS (default) → the primary commits without waiting for replicas
  ✓ faster writes (no wait)   ✗ a tiny window of potential data loss on failover
SYNCHRONOUS → the primary waits for a replica to confirm before committing
  ✓ no data loss on failover  ✗ slower writes (waits for the replica)
→ Choose based on the durability vs performance trade-off.
```

## Replicación lógica (un modelo diferente)

```text
LOGICAL replication → replicates specific TABLES/changes (not the whole cluster), based
on a publish/subscribe model. Enables: selective replication, cross-version, and
replicating to different schemas → good for migrations, integrations, partial replication.
```

## Alta disponibilidad en la práctica

```text
Tools like Patroni, repmgr, or cloud-managed Postgres automate FAILOVER (detecting
primary failure and promoting a replica) → near-automatic high availability.
A load balancer / connection router directs writes to the primary, reads to replicas.
```

## Por qué es importante

La replicación es importante para construir implementaciones de PostgreSQL **altamente disponibles y escalables**, por lo que comprenderla es conocimiento valioso de nivel senior para arquitectura de base de datos en producción.

Los dos beneficios fundamentales son críticos para aplicaciones serias: **alta disponibilidad** (si la base de datos principal falla, una réplica puede ser promovida para tomar el control, minimizando el tiempo de inactividad — esencial para sistemas que deben permanecer disponibles) y **escalado de lectura** (enrutar consultas de solo lectura a réplicas descarga la principal, permitiendo que el sistema maneje mucho más tráfico de lectura — valioso para cargas de trabajo intensivas en lectura).

Comprender la **replicación por streaming** (la principal transmitiendo su WAL a réplicas que permanecen sincronizadas y pueden servir lecturas) es la base.

Conocer el trade-off de **replicación síncrona vs asíncrona** es importante: asíncrona (la predeterminada — escrituras más rápidas pero una pequeña ventana de posible pérdida de datos en failover) versus síncrona (sin pérdida de datos pero escrituras más lentas) — una decisión de durabilidad vs rendimiento que afecta la confiabilidad.

Comprender la **replicación lógica** (replicar tablas específicas mediante pub/sub, útil para migraciones, entre versiones, y replicación parcial/selectiva) amplía las opciones.

Saber que las **herramientas de HA** (Patroni, repmgr, Postgres en la nube gestionado) automatizan el failover, y que el enrutamiento de lectura/escritura dirige el tráfico apropiadamente, es conocimiento arquitectónico práctico.

Como la alta disponibilidad y escalabilidad son requisitos esenciales para sistemas de bases de datos en producción, y como la replicación (con su failover de HA, escalado de lectura, el trade-off de durabilidad síncrona/asíncrona, y replicación lógica para flexibilidad) es el mecanismo principal que proporciona PostgreSQL para ellos, comprender la replicación es conocimiento importante de nivel senior para arquitectar implementaciones de Postgres confiables y escalables — una preocupación frecuentemente relevante para sistemas en producción y un tema que demuestra comprensión de la disponibilidad y escalado de bases de datos que se espera para roles senior de base de datos/backend.