PostgreSQL 16: novedades que cambian el dia a dia

Actualizado: 2026-05-03

PostgreSQL 16 llegó en septiembre de 2023 manteniendo la cadencia anual de la comunidad. Ninguna novedad aislada es revolucionaria, pero el conjunto refleja la madurez del proyecto: cada release pule áreas donde los operadores sentían fricción real. A continuación las novedades que cambian el día a día en producción.

Puntos clave

• La replicación lógica desde standby descarga el primario en clusters con múltiples consumidores CDC.
• pg_stat_io ofrece por primera vez visibilidad granular de I/O por tipo de operación y contexto.
• El paralelismo de FULL OUTER JOIN elimina un cuello de botella histórico en consultas analíticas.
• Las nuevas funciones SQL/JSON y de array reducen código de aplicación y son más portables entre motores.
• Migraciones desde 15 son sencillas; desde 13, el end-of-life de noviembre de 2025 urge actuar.

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 establecerse desde el primario, añadiendo carga al nodo más crítico.

Postgres 16 permite usar un standby como origen de suscripciones lógicas. Las implicaciones prácticas son tres:

• Pipelines ETL y CDC sin añadir carga al primario.
• Replicación cross-region desde un standby local en vez de cruzar continentes desde el nodo principal.
• Topologías de fan-out donde un standby alimenta a varios consumidores lógicos (Kafka, Debezium).

Para equipos con un primario ya sobrecargado, este cambio reduce significativamente la presión sobre el nodo más crítico.

Mejoras de rendimiento en queries paralelas

Postgres mejora paralelismo en cada release reciente. En la versión 16 destacan tres cambios:

• FULL OUTER JOIN paralelo. Antes era serial; ahora utiliza workers paralelos. La mejora es drástica en consultas analíticas que combinan tablas grandes.
• JOIN con filtros más complejos que ahora admiten paralelismo donde antes no lo hacían.
• Mejor planning de window functions, especialmente en combinación con agregaciones.

Para queries OLAP o reports complejos, el cambio es notable sin modificar nada en el código de la aplicación.

pg_stat_io: la nueva ventana al I/O

Una de las novedades de observabilidad más útiles de la versión. La vista pg_stat_io desglosa 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 es posible responder con datos: ¿quién consume el I/O — VACUUM, bulk loads o queries normales? ¿El shared_buffers tiene hit ratio suficiente? ¿Hay actividad de extend excesiva? Es una mejora fundamental para diagnóstico de performance que antes requería herramientas externas o instrumentación manual. Complementa bien los patrones de observabilidad con Grafana Stack para cerrar el ciclo de métricas.

Nuevas funciones SQL

Mejoras de sintaxis que reducen código de aplicación:

• SQL/JSON constructors estándar (JSON_OBJECT, JSON_ARRAY, IS JSON). Más portables entre motores que las funciones propietarias antiguas de Postgres.
• array_sample() y array_shuffle(). Útiles para sampling sin construir consultas elaboradas.
• Mejor soporte de regex en patrones COLLATE, lo que permite ordenamientos personalizados más expresivos.

Mejoras en replicación física y administración

Para clusters operacionales, varios ajustes se acumulan en el día a día:

• 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 con más detalle sobre lag y estado de cada réplica.
• pg_locks más granular sobre tipos de lock antes opacos.
• VACUUM con feedback más detallado vía pg_stat_progress_vacuum.

Cada mejora es pequeña individualmente, pero el conjunto reduce el tiempo de diagnóstico en incidentes.

Cambios menos visibles pero importantes

• Parámetro experimental io_method para pruebas con io_uring en Linux. Promete mejoras significativas de throughput de I/O en kernels modernos.
• CREATE TABLE LIKE mejorado con más opciones de herencia (constraints, indexes, statistics).
• Compresión de transacciones grandes en replicación lógica — menos bandwidth en flujos CDC activos.

Cuándo migrar

Tres escenarios con criterio claro:

• En Postgres 15: la migración es relativamente sencilla y sin cambios disruptivos. Vale la pena planificarla para aprovechar pg_stat_io y la replicación lógica desde standby.
• En Postgres 14 o anterior: prioriza migrar a 15 o 16 según el calendario operativo. Las versiones más antiguas se acercan al end-of-life.
• En Postgres 13: pierde soporte en noviembre de 2025. Empieza a planificar ahora.

Para nuevos proyectos, arranca directamente en 16. No hay razón para empezar en una versión anterior.

Verificaciones antes de migrar

Cuatro puntos operativos para una migración limpia:

1. Extensiones. Verifica que PostGIS, pgvector, TimescaleDB y cualquier otra extensión tienen versión compatible con Postgres 16.
2. Drivers cliente. Versiones antiguas pueden tener problemas con la autenticación SCRAM habilitada por defecto.
3. Backups. Prueba pg_dump desde la versión 16 hacia la versión menor antes de comprometer el cambio.
4. Replicación lógica existente. La migración de subscriber/publisher requiere coordinación con sus contrapartes.

Si usas bases de datos vectoriales como pgvector sobre Postgres, verifica la compatibilidad de la extensión antes de migrar.

Conclusión

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