PostgreSQL 16: replicación lógica que ya es práctica

javi
Hileras de servidores con luces LED azul y verde representando replicación de bases de datos

PostgreSQL 16 (septiembre 2023) marca un hito para replicación lógica: features largamente esperados la hacen productiva para escenarios que antes requerían herramientas externas. Parallel apply, subscribers desde standbys, mejor gestión de schemas — suficiente para migrations zero-downtime, CDC eficiente, y multi-tenant dissemination.

Qué cambia en PG16

Features clave de logical replication en 16:

Parallel apply

Antes de PG16, apply en el subscriber era single-threaded. Ahora:

-- En el subscriber
ALTER SUBSCRIPTION mysub SET (
    streaming = parallel,
    parallel_apply = 4  -- workers paralelos
);

Para transacciones grandes, el apply se paraleliza. Mejora típica: 2-5x throughput.

Subscribers desde standbys

Antes: logical replication solo desde primary. PG16: puedes leer WAL desde un standby físico.

  • Ventaja: reduce carga del primary.
  • Caso uso: multi-tenant con muchos subscribers.

Logical decoding en standbys

Relacionado: standbys ahora pueden exponer slots lógicos directamente.

Bi-directional replication support

Schemas que permiten aplicar y publicar en la misma BD (con disciplina) hacen multi-master lógico posible. Still complicated pero factible sin extensiones.

ALTER SUBSCRIPTION improvements

  • ENABLE/DISABLE sin drop+recreate.
  • SKIP transacciones problemáticas (p.ej. conflictos de PK).
  • Management más flexible.

Casos de uso desbloqueados

Zero-downtime migration

Migrar de PG14 a PG16 (o entre hostings):

  1. Setup logical replication PG14 → PG16.
  2. Sincronizar datos (DDL manual, datos via pub/sub).
  3. Dual-write breve vs primary cutover.
  4. Apps apuntan al nuevo.
  5. Viejo se decomisiona.

Tiempo de downtime: minutos vs horas con pg_dump.

CDC para data warehouse

Publicar cambios desde OLTP a Kafka vía Debezium (que usa logical replication):

CREATE PUBLICATION dw_pub FOR ALL TABLES;

Debezium consume y empuja a Kafka. Downstream: Snowflake, BigQuery, ClickHouse.

Read replicas geo-distribuidas

Subscribers en regiones distintas consumiendo de publication central. Lecturas locales, writes al primary central.

Multi-tenant con BD por cliente

Dissemination de cambios desde una BD central a muchas BD por tenant.

Ejemplo práctico

Publisher (origen):

CREATE PUBLICATION mypub FOR TABLE users, orders;

-- O todas las tablas
CREATE PUBLICATION allpub FOR ALL TABLES;

Subscriber (destino):

CREATE SUBSCRIPTION mysub
  CONNECTION 'host=primary port=5432 dbname=mydb user=replicator password=secret'
  PUBLICATION mypub
  WITH (streaming = parallel, parallel_apply = 4);

Monitorización:

SELECT * FROM pg_stat_subscription;
SELECT * FROM pg_replication_slots;

Limitaciones que persisten

Aunque mejorada, todavía:

  • No replica DDL: CREATE TABLE, ALTER deben aplicarse manualmente en ambos lados.
  • Sequences: no se replican automáticamente el valor.
  • Conflictos: sin resolución automática built-in; aplica primero-gana con warnings.
  • Large objects: no replicados.
  • TRUNCATE: ahora sí replicado en PG11+, pero con caveats.

Herramientas como pglogical siguen siendo útiles para casos avanzados.

Performance

Orientation numbers con PG16 parallel apply:

  • Single worker: ~5-10k rows/s inserts.
  • 4 parallel workers: ~30-50k rows/s.
  • Network: WAL shipping, limitado por bandwidth.
  • CPU: tanto primary (decoding) como subscriber (apply) consume.

Para cargas write-heavy, logical replication tiene overhead visible pero manejable.

Operación

Checklist:

  • Monitor slot lag: pg_replication_slots.confirmed_flush_lsn vs pg_current_wal_lsn().
  • Cleanup slots huérfanos: slots sin subscriber activo bloquean WAL cleanup. Peligroso.
  • WAL retention: planificar según max lag esperado.
  • Credenciales: usuario replicator con permisos mínimos.

Alertar si lag crece inesperadamente o slots se quedan atrás.

Comparativa con alternativas

Solución Uso Complejidad Coste
PG16 logical replication DB-to-DB Media $0 (incluido)
Debezium + Kafka CDC a muchos Alta Kafka infra
pglogical Multi-master avanzado Alta $0 (OSS)
BDR (EDB) Multi-master enterprise Muy alta Licencia cara
Fivetran / Airbyte ELT a DW Baja (SaaS) Por volumen

Para casos simples (DB-to-DB), PG16 built-in es suficiente. Para complex (multi-master, CDC masivo), alternativas specialized.

Migración a PG16

Upgrade desde PG14/15:

  • pg_upgrade: in-place upgrade, típicamente rápido.
  • Logical replication entre old y new.
  • Dump/restore: último recurso, downtime largo.

Para producción seria, logical replication es la vía más segura.

Conclusión

PostgreSQL 16 convirtió la replicación lógica en herramienta de primera línea. Features como parallel apply, subscribers desde standbys y mejor management cierran brechas que antes requerían extensiones o herramientas externas. Para migraciones zero-downtime, CDC simple, y arquitecturas multi-region, PG16 built-in cubre la mayoría de casos. Para ultra-complejos (multi-master con conflict resolution), todavía hacen falta specialty tools. Pero el ecosistema PostgreSQL está más autónomo que nunca en este área.

Síguenos en jacar.es para más sobre PostgreSQL, replicación y arquitecturas de datos.

Entradas relacionadas