PostgreSQL 16: novedades que cambian el dia a dia

javi
Pantalla con consultas SQL y resultados en terminal

PostgreSQL 16 se lanzó el 14 de septiembre de 2023, manteniendo la cadencia anual de la comunidad. Aunque ninguna de sus novedades es revolucionaria por sí sola, el conjunto refleja la madurez del proyecto: cada release pule áreas concretas que sus usuarios sentían como fricciones. Cubrimos las novedades que realmente cambian el día a día en producción.

Replicación lógica desde standby

La novedad más esperada por equipos con clusters grandes. Hasta Postgres 15, la replicación lógica (CDC, change data capture) solo podía hacerse desde el primario — añadiendo carga al nodo más crítico.

Postgres 16 permite establecer suscripciones lógicas con un standby como origen. Implicaciones prácticas:

  • Pipelines ETL y CDC que no añaden carga al primario.
  • Replicación cross-region desde un standby local en vez de tener que cruzar continentes desde el primario.
  • Topologías de fan-out donde un standby alimenta a varios consumers lógicos.

Para equipos con un primario sobrecargado y varios consumidores Kafka/Debezium, este cambio reduce significativamente la presión sobre el primary.

Mejoras de rendimiento en queries paralelas

Postgres ha mejorado paralelismo en cada release reciente; en 16 destaca:

  • FULL OUTER JOIN paralelo. Antes era serial; ahora puede usar workers paralelos. Mejora drástica en queries analíticas.
  • JOIN con filtros más complejos que ahora soportan paralelismo donde antes no.
  • Mejor planning de window functions, especialmente cuando se combinan con agregaciones.

Para queries OLAP o reports complejos, el cambio es notable sin tocar nada en tu código.

pg_stat_io: la nueva ventana al I/O

Una de las novedades de observabilidad más útiles. La vista pg_stat_io rompe el I/O de Postgres por tipo de operación (read, write, extend, fsync) y contexto (normal, vacuum, bulk read/write).

SELECT backend_type, object, context, reads, writes, hits
FROM pg_stat_io
ORDER BY reads DESC;

Por primera vez puedes responder con datos: ¿quién está consumiendo el I/O — VACUUM, bulk loads o queries normales? ¿Mi shared buffers tienen suficiente hit ratio? ¿Hay actividad de extend (extensión de tabla) excesiva?

Es una mejora fundamental para diagnóstico de performance que antes requería herramientas externas o instrumentación manual.

Nuevas funciones SQL

Mejoras en sintaxis que ahorran código de aplicación:

  • SQL/JSON constructors estándar (JSON_OBJECT, JSON_ARRAY, IS JSON). Más portable entre BD que las funciones específicas de Postgres antiguas.
  • array_sample() y array_shuffle(). Útiles para sampling sin tener que construir consultas elaboradas.
  • Mejor soporte de regex en patrones COLLATE — sortings personalizados más expresivos.

Mejoras en la replicación física

Para clusters más operacionales:

  • pg_basebackup paralelo. Backups iniciales más rápidos en clusters grandes.
  • Compresión LZ4 y Zstandard integrada en pg_dump y pg_restore. Antes había que combinar con tuberías externas.
  • Estadísticas mejoradas en pg_stat_replication — más detalle sobre lag y estado de cada replica.

Cambios pequeños individualmente, pero acumulan en operaciones diarias.

Funciones administrativas

Mejoras a la administración día a día:

  • pg_locks mejorado con granularidad sobre tipos de lock que antes eran opacos.
  • VACUUM con feedback de progreso más detallado vía pg_stat_progress_vacuum.
  • Logical decoding más robusto ante interrupciones — recovery más limpio tras un fallo.

Cambios menos visibles pero importantes

Algunos cambios internos importantes para casos avanzados:

  • io_method parámetro experimental para pruebas con io_uring en Linux. Promete mejoras significativas en throughput de I/O.
  • CREATE TABLE LIKE mejorado con más opciones de qué heredar (constraints, indexes, statistics).
  • Compresión de transacciones grandes en logical replication — menos bandwidth en replicación lógica.

Cuándo migrar

PostgreSQL 16 es solid release. Para producción:

  • Si estás en 15: la migración es relativamente sencilla, sin cambios disruptivos. Vale la pena planificarla en los próximos 6 meses para aprovechar pg_stat_io y replicación lógica desde standby.
  • Si estás en 14 o anterior: prioriza migrar a 15 o 16 según tu calendario operativo. Las versiones más antiguas se acercan a end-of-life.
  • Si estás en 13: 13 perderá soporte en noviembre de 2025. Empieza a planificar.

Para nuevos proyectos en 2023, empieza directamente en 16. No hay razón para arrancar en una versión anterior.

Cosas a verificar antes de migrar

Lecciones operativas para una migración limpia:

  • Extensiones. Verifica que cada extensión que usas (PostGIS, pgvector, TimescaleDB, etc.) tiene versión compatible con 16.
  • Drivers. Drivers cliente antiguos pueden tener problemas con autenticación SCRAM por defecto.
  • Backups: prueba pg_dump desde 16 hacia versión menor antes de comprometer (compatibilidad hacia atrás funciona pero conviene validar).
  • Replicación lógica existente: la migración de subscriber/publisher requiere coordinación con sus contrapartes.

Conclusión

PostgreSQL 16 no transforma cómo usas la base de datos; mejora puntos concretos que cualquier operador de Postgres en producción agradecerá. Replicación lógica desde standby, pg_stat_io y mejoras de paralelismo son las tres novedades que justifican planificar la migración desde 14 o 15. Para equipos en 13 o anterior, además, el plazo de end-of-life acerca la urgencia.

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

Entradas relacionadas