PostgreSQL 17: las novedades que apuntan maneras

Actualizado: 2026-05-03

PostgreSQL 17 alcanzó GA en septiembre de 2024. Es una release iterativa pero con features que tienen impacto operativo real: vacuum significativamente más eficiente, logical replication con failover completo, JSON_TABLE SQL:2023, async I/O experimental y mejoras en el planner. Para equipos que operan Postgres serio, vale la pena probar en staging desde ya y planificar el upgrade para los próximos meses.

Puntos clave

• Nuevo algoritmo de dead tuple storage en vacuum: hasta 20x menos memoria en tablas grandes.
• Slot synchronization: los slots lógicos se replican a standbys; tras un failover el subscriber reconecta sin re-sync completo.
• JSON_TABLE (SQL:2023): convierte JSON en tabla relacional con sintaxis estándar.
• COPY ... FROM con ON_ERROR IGNORE: ETL pesado sin abortar en errores de fila.
• Async I/O activable via config: mejoras potencialmente significativas en NVMe.

Vacuum más rápido y barato en memoria

Vacuum ha sido históricamente una fuente de dolores en tablas gigantes: bloqueos, uso de memoria, lentitud. PG17 ataca esto con un nuevo algoritmo de almacenamiento de dead tuples:

• Hasta 20x menos memoria que el algoritmo anterior.
• maintenance_work_mem ya no limita como antes: el vacuum es intrínsecamente más eficiente.
• Parallel index cleanup mejorado.
• Vacuum tras failover: reanuda desde donde quedó en lugar de empezar desde cero.

En tablas de varios cientos de millones de filas, la diferencia puede ser la que separa un vacuum que dura horas de uno que dura minutos.

Logical replication con failover

Este es el cierre más esperado. En PostgreSQL 16 (que mejoró el apply paralelo), un caso común seguía roto: si el primario cae y un standby asciende, los subscribers perden el estado de su slot lógico y necesitan re-sync completo.

PG17 introduce slot synchronization:

• Los slots lógicos se replican a los standbys físicos.
• Tras un failover, el subscriber puede reconectarse al nuevo primario sin sincronización completa.
• Esto convierte la logical replication en infraestructura HA-viable de verdad.

JSON_TABLE

PG17 añade JSON_TABLE (SQL:2023 standard). Convertir JSON en tabla relacional inline:

SELECT t.*
FROM orders o,
     JSON_TABLE(o.data, '$.items[*]' COLUMNS (
         item_id INT PATH '$.id',
         name TEXT PATH '$.name',
         price NUMERIC PATH '$.price'
     )) AS t;

Antes había que usar jsonb_array_elements más extracciones: verboso y propenso a errores. Ahora la sintaxis es SQL estándar e interoperable con otros motores que soporten SQL:2023.

COPY mejorado para ETL

COPY ... FROM tiene dos mejoras importantes:

• ON_ERROR IGNORE: continúa procesando filas tras un error de parseo en lugar de abortar la operación completa. Para ETL de fuentes externas con datos sucios, esto es oro.
• Rendimiento mejorado en bulk loads.

Para cargas ETL pesadas que antes requerían preprocessing defensivo o scripts de reintento, esta opción simplifica considerablemente el pipeline.

MERGE más robusto

MERGE (SQL standard upsert) mejora en PG17:

• Soporta triggers correctamente.
• Clausula RETURNING.
• Mejor optimizador.

Permite reemplazar patrones antiguos de INSERT ... ON CONFLICT con sintaxis estándar que funciona bien en ambientes mixtos.

Async I/O

Introducción experimental de I/O asíncrono para operaciones de lectura (sequential scans, index scans, bitmap heap scans). Activable via config. Potencialmente significativo en hardware moderno con NVMe SSD donde la latencia de I/O es baja y el paralelismo es la clave. En benchmarks preliminares sobre NVMe, el ganho varía entre 10% y 40% según el workload.

Backups incrementales

pg_basebackup con modo incremental:

pg_basebackup -D backup --incremental=/backup/prev_manifest

Reduce tiempo y tamaño de backups. Combinado con pgBackRest o WAL-G, los flujos de backup se vuelven significativamente más eficientes para bases de datos grandes.

Mejoras de planner

• Subquery pull-up más agresivo.
• Parallel hash join mejorado.
• Planes más estables en casos borderline.

Benchmarks preliminares muestran mejoras del 5-15% en queries típicas frente a PG16.

Cuándo hacer upgrade

Para un cluster productivo:

• GA + versiones minor 17.1/17.2: esperar 1-2 meses tras el GA para dejar que la comunidad reporte problemas.
• Beta en staging/dev: ya vale la pena para familiarizarse.
• Nuevos proyectos: arrancar directamente con 17.

El upgrade con pg_upgrade --link desde PG15+ es non-destructivo y rápido: relinks en lugar de copiar datos.

Roadmap: qué viene después

En el horizonte de PG18+ se vislumbran vectorized execution (experimental), columnar storage via TableAM expansion, y mejoras continuas en JIT. PostgreSQL sigue demostrando que la evolución consistente release tras release acumula ventajas difíciles de replicar.

Conclusión

PostgreSQL 17 es una release iterativa con dividendos prácticos claros: vacuum más eficiente, logical replication HA completa, JSON_TABLE estándar, mejoras de planner. Para equipos que operan Postgres serio, los beneficios operativos justifican la planificación del upgrade en los próximos seis meses. No hay breaking changes dramáticos, pero los release notes merecen lectura antes de tocar cualquier cluster de producción.