PostgreSQL 17 en 2026: las novedades más importantes de la última versión mayor

PostgreSQL 17 se lanzó en septiembre de 2024 y trajo un buen puñado de mejoras que, aunque no siempre saltan a la vista en los changelogs, tienen un impacto real en el día a día. Si todavía estás en la 15 o la 16, este resumen te ayudará a decidir cuándo merece la pena migrar.

VACUUM incremental: por fin más manejable

Uno de los puntos más comentados de PG17 es la reescritura parcial del proceso de VACUUM. Hasta ahora, cuando VACUUM procesaba una tabla grande, tenía que recorrerla entera de una vez o volver a empezar si se interrumpía. En la versión 17 se introduce el VACUUM incremental, que guarda el estado del progreso en el mapa de visibilidad de la tabla y puede reanudar desde donde lo dejó.

En la práctica, esto reduce los picos de I/O en tablas con mucho tráfico de escritura. Si tienes tablas de logs o de eventos con decenas de millones de filas, notarás que el VACUUM autovacuum compite menos con las queries de producción.

pg_dump más rápido gracias al paralelismo mejorado

La utilidad pg_dump ya soportaba paralelismo con la opción -j, pero en PG17 se ha ampliado para que el volcado paralelo funcione también en el formato de directorio (-Fd) con más tipos de objetos. El resultado es que backups de bases de datos grandes se completan bastante más rápido en máquinas con varios núcleos.

Si haces backups nocturnos de bases de datos de varios GB, prueba a ajustar el parámetro -j y verás la diferencia. En algunos casos se reduce el tiempo de volcado a la mitad.

SQL/JSON constructors: la sintaxis estándar llega por fin

PostgreSQL ha tenido soporte de JSONB durante años, con sus operadores propios (->, ->>, @>...). En PG17 se añaden los constructores del estándar SQL:2016: JSON(), JSON_ARRAY() y JSON_OBJECT(). Esto no reemplaza lo que ya existía, sino que añade una forma portable de construir JSON que funciona igual en otros motores compatibles con el estándar.

-- Con los nuevos constructores SQL/JSON
SELECT JSON_OBJECT(
  'nombre' VALUE u.nombre,
  'edad'   VALUE u.edad
)
FROM usuarios u;

-- Equivalente con la sintaxis clasica de PostgreSQL
SELECT jsonb_build_object('nombre', u.nombre, 'edad', u.edad)
FROM usuarios u;

Si tu equipo trabaja con otros motores además de PostgreSQL, esta sintaxis facilita que las queries sean más portables sin perder nada de potencia.

Mejoras en replicación lógica: failover slots

Otro cambio que pasa más desapercibido pero que importa en producción es el soporte de failover slots en la replicación lógica. Hasta PG16, si hacías un failover a una réplica, los slots de replicación lógica se perdían y tenías que reconfigurar los suscriptores manualmente. En PG17, los slots pueden sincronizarse automáticamente a las réplicas físicas de standby, de forma que el failover es mucho menos traumático.

Esto es especialmente útil si usas replicación lógica para alimentar pipelines de datos o para zero-downtime deployments con herramientas como pglogical o la replicación nativa.

Streaming replication: menos latencia en redes lentas

La replicación en streaming también ha recibido ajustes. PG17 mejora el protocolo de comunicación entre primary y standby para reducir la latencia de replicación en conexiones con ancho de banda limitado o alta latencia. No es un cambio dramático, pero si tienes réplicas en regiones geográficas distintas, puede notarse.

Cuándo tiene sentido migrar

Si tu aplicación usa tablas con mucha escritura y tienes problemas de bloat o de VACUUM que tarda demasiado, PG17 es una actualización que vale la pena hacer. Las mejoras en VACUUM incremental y en pg_dump son sólidas y resuelven problemas reales.

Si, en cambio, tu carga es principalmente de lectura y estás en PG15 o PG16 sin problemas, puedes esperar al ciclo natural de actualización. PG17 es una versión estable y ya está en soporte activo, así que no hay prisa si todo funciona bien.

Para conectar datos de PostgreSQL con Python, puedes combinar esta base con las librerías de pandas y Polars para análisis de datos. Y si te interesa cómo gestionar el acceso a base de datos desde Elixir, el artículo sobre Ecto y changesets cubre un enfoque muy diferente al SQL directo.

Imagen: Pexels / panumas nikhomkhai