Actualizado: 2026-07-07

PostgreSQL 17 alcanzó disponibilidad general[1] 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, un nuevo motor de I/O en streaming 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.

  • I/O en streaming para sequential scans y ANALYZE: lecturas más grandes (hasta 128 KB en vez de 8 KB) y menos syscalls.

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 TidStore, un nuevo algoritmo de almacenamiento de dead tuples que, según confirma el propio equipo de PostgreSQL[2], consume:

  • Hasta 20x menos memoria que el algoritmo anterior.

  • Ya no hay tope silencioso de 1 GB: maintenance_work_mem y autovacuum_work_mem altos ahora se aprovechan de verdad.

  • Parallel index cleanup mejorado.

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:

  • Puede modificar vistas actualizables (updatable views).

  • Añade la cláusula WHEN NOT MATCHED BY SOURCE.

  • Admite RETURNING, con la función merge_action() para saber qué rama del MERGE generó cada fila.

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

I/O en streaming para sequential scans

PG17 no trae async I/O completo todavía (eso llega con PG18[3]), pero sienta la base: una nueva API de streaming I/O que agrupa lecturas de disco con el parámetro io_combine_limit, pasando de reads de 8 KB a reads de hasta 128 KB en sequential scans y en ANALYZE. Es groundwork de bajo nivel, pero mejora el throughput en cargas que escanean tablas completas, y allana el camino para el I/O asíncrono real que sí llegó en la versión siguiente.

Backups incrementales

pg_basebackup con modo incremental:

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

Reduce el tiempo y el volumen de datos a mover en cada backup. No sustituye a pgBackRest ni WAL-G (que ya resuelven esto para muchos equipos), pero da a pg_basebackup y a pg_combinebackup una vía nativa para bases de datos grandes sin depender de herramientas de terceros.

Mejoras de planner

  • Subquery pull-up más agresivo.

  • Parallel hash join mejorado.

  • Planes más estables en casos borderline.

Los números varían mucho según la carga, pero dan una idea del orden de magnitud: en el benchmark independiente de SQLpipe[4], un sequential scan bajó de 6.6 a 4.8 segundos (~27% menos) frente a PG16; no es representativo de toda carga, pero confirma que el I/O en streaming y las mejoras del planner se notan en la práctica.

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.

Versión en inglés: PostgreSQL 17: The Novelties That Show Promise.

Fuentes:

  1. PostgreSQL 17 Released! (nota de prensa oficial)[1]
  2. PostgreSQL 17 Released with Improved Vacuum Process and Performance Gains (InfoQ)[2]
  3. Waiting for Postgres 17: Streaming I/O for sequential scans & ANALYZE (pganalyze)[3]
  4. PostgreSQL 17 Performance Benchmark (SQLpipe)[4]
Visitas: 265

Fuentes

  1. alcanzó disponibilidad general
  2. según confirma el propio equipo de PostgreSQL
  3. llega con PG18
  4. benchmark independiente de SQLpipe