PostgreSQL 17: las novedades que apuntan maneras

javi
Código SQL en pantalla con sintaxis resaltada sobre fondo oscuro

PostgreSQL 17 beta 1 salió el 23 de mayo de 2024, con GA prevista para septiembre. Es release iterativa pero con varias features que harán notar: mejoras importantes en vacuum, logical replication con failover, JSON_TABLE SQL standard, y muchas optimizaciones de I/O. Este artículo cubre qué vale la pena empezar a probar en testing y por qué.

Vacuum más rápido y barato en memoria

Vacuum históricamente ha sido fuente de dolores: bloqueos, uso de memoria, lentitud. PG17 ataca esto:

  • Nuevo algoritmo de dead tuple storage: hasta 20x menos memoria.
  • maintenance_work_mem ya no limita como antes — más eficiente intrínsecamente.
  • Parallel index cleanup mejorado.
  • Vacuum tras failover: reanuda desde donde quedó.

En tablas gigantes, esto puede reducir vacuum de horas a minutos.

Logical replication con failover

En PG16 (con las mejoras discutidas el artículo anterior), falla un caso común: si el primary cae y un standby promote, los subscribers pierden su state.

PG17 introduce slot synchronization:

  • Slots lógicos se replican a standbys.
  • Tras failover, subscriber puede re-conectar al nuevo primary sin re-sync completo.

Esto completa la visión de logical replication como infraestructura HA-viable.

JSON_TABLE

PG17 finalmente 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 tenías que usar jsonb_array_elements + extracciones — verbose. Ahora syntax SQL-standard.

COPY mejorado

COPY ... FROM tiene:

  • ON_ERROR ignore: continuar tras error parseando fila.
  • Performance mejorada para bulk loads.

Para ETL pesado, la capacidad de skip errores sin abortar es oro.

MERGE mejorado

MERGE (SQL standard upsert) más robusto:

  • Soporta triggers correctly.
  • RETURNING clause.
  • Mejor optimizer.

Permite reemplazar patterns antiguos de INSERT ... ON CONFLICT.

Improvements en planner

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

Benchmarks preliminarios muestran 5-15% improvements en queries típicos vs PG16.

I/O asíncrono

Introducción de async I/O para ciertas operaciones:

  • Sequential scans.
  • Index scans.
  • Bitmap heap scans.

Potencialmente major improvement en hardware moderno con NVMe. Activable via config.

Nuevo incremental backup

pg_basebackup con incremental mode:

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

Reduce tiempo y tamaño de backups. Combinado con pgBackRest o WAL-G, flujos más eficientes.

Extensions

  • pg_stat_io estabilizada (introducida PG16).
  • pg_buffercache con stats más detalladas.
  • auto_explain con output JSON.

Mejor observabilidad out-of-box.

Breaking changes

  • Algunas deprecations de sintaxis vieja.
  • Cambios en pg_hba.conf parseo — revisar antes de upgrade.
  • Defaults ligeramente distintos en algunos pragmas.

Nada dramático pero merece lectura de release notes.

Performance benchmarks

Números tempranos (beta):

  • INSERT throughput: +5-10% vs PG16.
  • Logical replication: +30-50% con parallel apply mejorado.
  • Vacuum en tablas grandes: hasta 20x más eficiente en memoria.
  • Complex analytical queries: +10-15% via planner.

Para producción masiva, los gains pueden ser significativos.

Cuándo hacer upgrade

Para un cluster productivo:

  • Esperar GA (septiembre 2024) + 1-2 minor (17.1, 17.2).
  • Beta en staging/dev vale la pena ya.
  • Nuevos proyectos 2024 H2+: arrancar con 17.

pg_upgrade sin drama

PG17 mantiene compatibilidad pg_upgrade desde PG15+. Flujo normal:

pg_upgrade -b /old/bin -B /new/bin \
  -d /old/data -D /new/data \
  --link

Con --link, upgrade en minutos (no copia datos, solo relinks).

Roadmap: qué viene después

Lookahead a PG18+:

  • Vectorized execution (experimental).
  • Columnar storage via TableAM expansión.
  • Distributed query con FDW mejorado.
  • Mejoras continuas en JIT.

PostgreSQL sigue evolucionando fuertemente sin perder backwards compatibility.

Extensions a seguir

Con PG17:

  • pgvector: 0.7+ compatible.
  • TimescaleDB: PG17 support siguiendo GA.
  • Citus: distributed PostgreSQL, soporte próximo.
  • PostGIS: tradicionalmente rápido a actualizar.

Ecosistema extensions se adapta en meses.

Ecosistema cloud

Proveedores:

  • AWS RDS / Aurora: Postgres 17 disponible tras GA + validation.
  • GCP Cloud SQL: similar.
  • Azure Database: similar.
  • Supabase, Neon, Railway, Fly.io: tienden a adoptar rápido.

Para producción managed, esperar 3-6 meses tras GA es prudente.

Conclusión

PostgreSQL 17 es release iterativa pero con features impactantes: vacuum más eficiente, logical replication con failover completo, JSON_TABLE estándar, async I/O. Para equipos que operan Postgres serio, vale la pena probar en staging pronto y planificar upgrade para fin de 2024 o inicios de 2025. No hay features breaking pero hay muchos dividendos prácticos. PostgreSQL continúa demostrando que evolución consistente es estrategia sólida — release tras release, acumula ventajas sobre alternativas.

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

Entradas relacionadas