PostgreSQL, una de las bases de datos de código abierto más usadas del mundo, publicó el 15 de octubre de 2026 la primera versión candidata de PostgreSQL 19 y confirmó que la versión final se espera hasta el 19 de noviembre. Originalmente se esperaba para finales de septiembre o principios de octubre.
El retraso tiene una explicación poco común: según uno de sus principales desarrolladores, la revisión de código asistida con inteligencia artificial encontró tantos defectos pequeños que el equipo no alcanzó a corregirlos todos a tiempo, y prefirió quitar varias funciones nuevas antes que lanzarlas con errores.
¿Qué pasó?
El anuncio oficial del proyecto dice que PostgreSQL 19 RC1 ya está disponible para pruebas y que la versión final debería salir el 19 de noviembre de 2026, salvo que aparezca un problema que obligue a retrasarla o a publicar otra candidata. Antes habrá una segunda candidata el 12 de noviembre, el mismo día de la actualización trimestral de seguridad, porque el equipo decidió incluir ese paquete grande de correcciones antes del lanzamiento.
Entre los cambios desde la beta 4 hay correcciones para REPACK (CONCURRENTLY), para pg_plan_advice, para nuevas optimizaciones del planificador de consultas y para el aspirado automático en paralelo. También cambió un detalle que puede afectar tus scripts: al exportar una consulta con COPY en formato JSON, ahora las llaves usan los nombres de columna de la consulta, incluidos los alias, en lugar de los nombres de la tabla.
The Register reportó el 16 de octubre que entre 8 y 10 funciones importantes se retiraron de esta versión y pasarán a PostgreSQL 20. La más sonada es el soporte para consultas de grafos SQL/PGQ, que forma parte del estándar SQL desde 2023. Tom Lane, otro de los desarrolladores históricos, había advertido que si se enviaba en la 19 habría errores que no se podrían corregir hasta la 20.
Peter Eisentraut, committer del proyecto y vicepresidente en la consultora EDB, explicó en su blog que no hay una sola causa, pero que la revisión asistida con modelos de lenguaje cambió el juego: esas herramientas encuentran mucho más rápido una larga cola de casos límite que antes salían a la luz años después del lanzamiento. En sus palabras, de pronto «te quedas mirando una lista de unos cuarenta reportes de defectos».
¿Por qué te importa?
Si tenías planeado migrar a PostgreSQL 19 este trimestre, ajusta tu calendario: la fecha razonable para producción es a partir del 19 de noviembre, y después de la segunda candidata del 12 de noviembre. Mientras tanto, PostgreSQL 18 sigue siendo la versión estable más reciente.
La historia también dice algo sobre cómo está cambiando el desarrollo de software. Eisentraut aclara que esto no se debe al vibe coding, es decir, a generar código con IA sin revisarlo, porque la mayoría de esas funciones se escribió antes de que eso fuera posible. Lo que pasó es que la vara de calidad subió después de que el código ya estaba escrito y aprobado. Aunque cada arreglo sea de tres líneas, cada reporte trae un costo fijo de revisión, y el tiempo se acaba.
Para quien administra bases de datos, el lado bueno es que la versión que llegue en noviembre habrá pasado por un escrutinio inusual. El propio Eisentraut sostiene que PostgreSQL 19 seguirá siendo una gran versión y que será muy robusta. Entre lo que sí se queda destaca REPACK CONCURRENTLY, que recupera espacio en disco sin el bloqueo de tabla que exige VACUUM FULL.
¿Qué puedes hacer?
- Si tienes un entorno de pruebas, instala la RC1 y corre ahí tu aplicación; el proyecto pide reportar cualquier error que encuentres antes de la versión final.
- Revisa si tus scripts dependen de
COPY ... (FORMAT json), porque el nombre de las llaves cambió y puede romper lo que lea esos archivos. - Si estabas esperando las consultas de grafos SQL/PGQ, planea con PostgreSQL 20; en la 19 ya no vienen.
- Anota en tu calendario el 12 de noviembre para la actualización de seguridad de todas las ramas soportadas y el 19 de noviembre para la versión final.
- Recuerda que pasar de una versión mayor a otra requiere
pg_upgradeo un respaldo conpg_dumpy restauración; nunca es solo reemplazar binarios.
Un mes de espera a cambio de una versión con menos sorpresas en producción es un trato que a casi cualquier administrador le conviene.
Sigue leyendo
- Más de 16,000 bases de datos de Supabase quedaron abiertas en internet
- Linus Torvalds usa Claude Code para acelerar el kernel de Linux
Fuentes
- PostgreSQL Global Development Group: PostgreSQL 19 RC 1 Released!
- The Register: Postgres 19 delayed after AI reviewers find more bugs than humans can fix
- Blog de Peter Eisentraut: The reverts will continue until morale improves
Imagen de portada: foto de panumas nikhomkhai en Pexels.