PostgreSQL lleva años lanzando una nueva versión principal cada otoño, y PostgreSQL 19 no llegará en la fecha que se esperaba. La cuarta beta está prevista para el jueves 24 de septiembre, y el proyecto ya ha revertido 53 cambios durante el ciclo de beta, incluida la gran novedad de la versión, las consultas de grafos. Para los equipos que planifican sus actualizaciones según el calendario habitual, la pregunta ya no es qué funciones probar, sino cuáles estarán realmente.
Esto es lo que se ha retirado, por qué, lo que sigue en la versión y cuándo es probable que llegue PostgreSQL 19.
Por qué PostgreSQL 19 va con retraso
En un artículo para el blog de ingeniería de Snowflake, Elizabeth Garrett Christensen escribe que el código está en un ciclo intenso de revisión, que se han revertido funciones importantes durante la beta y que muchas otras están siendo revisadas a fondo. Su valoración es que el lanzamiento se retrasará con seguridad semanas y quizá incluso meses. Las prioridades del proyecto, escribe, eran primero la calidad y después publicar dentro de la ventana habitual, y el equipo está reduciendo el alcance de la versión para acercarse a su calendario.
No hay fecha anunciada de disponibilidad general. Según Layerbase, que sigue el calendario, la Beta 4 del 24 de septiembre es el único hito con fecha, y el equipo de gestión de versiones ha dicho que su objetivo es la disponibilidad general antes de finales de octubre, lo que mantendría la versión dentro de la ventana habitual de septiembre a octubre. Es un objetivo declarado, no un anuncio, y Layerbase señala que la propia página de temas pendientes de PostgreSQL 19 sigue indicando la primera release candidate y la versión final como por decidir.
El mayor recorte fueron las consultas de grafos
Las SQL Property Graph Queries, conocidas como SQL/PGQ, pasaron a formar parte del estándar SQL en 2023. Permiten declarar un grafo de propiedades sobre tablas existentes y buscar patrones en él con GRAPH_TABLE, una forma más ligera de hacer preguntas de grafos sin adoptar una base de datos de grafos aparte. Era la función más grande de PostgreSQL 19, y se ha quedado fuera.
Layerbase informa de que la reversión del 7 de septiembre eliminó unas 16.000 líneas en 124 archivos. Los motivos fueron la madurez y el diseño, no un único fallo. The Register citó al veterano colaborador Tom Lane sobre la decisión: "At this point I'd be willing to bet dinner that if we ship it in v19 there will be post-release bug discoveries that are unfixable until v20" (a estas alturas, me apostaría una cena a que, si lo publicamos en la v19, aparecerán fallos después del lanzamiento que no se podrán corregir hasta la v20). Tom Kincaid, vicepresidente sénior de ingeniería de software de EDB, confirmó a la publicación que la función no formará parte de PostgreSQL 19.
El trabajo no está abandonado. El artículo de Snowflake describe los grafos de propiedades como material para PostgreSQL 20, aunque Layerbase advierte de que una función de ese tamaño, que vuelve a empezar tras una reversión, tampoco es una apuesta segura para la versión 20.
Las otras funciones que se retiraron
Las consultas de grafos fueron el titular, pero la lista es larga. Layerbase fecha las reversiones más visibles a partir del historial de commits del proyecto:
- ALTER TABLE MERGE/SPLIT PARTITION(S), una forma muy solicitada de reorganizar particiones, revertida el 26 de agosto con un mensaje de commit que cita varios problemas de diseño demasiado tarde para resolverlos en este ciclo.
- UPDATE/DELETE FOR PORTION OF, actualizaciones temporales que dividen una fila a lo largo de su periodo de validez, revertida el 15 de septiembre en una reversión que tuvo que deshacer 23 commits.
- GROUP BY ALL, un atajo para agrupar por todas las columnas no agregadas, revertido el 17 de julio después de que la revisión posterior al commit descubriera que podía producir resultados erróneos con algunas entradas de ORDER BY.
- Formatos de salida no textuales para pg_dumpall, que habrían permitido restaurar en paralelo los volcados del clúster completo, revertidos el 18 de junio.
La lista de Snowflake añade el ON ERROR en cascada de JSON_TABLE, un valor por defecto rápido para dominios con restricciones no volátiles y el seguimiento de consultas anidadas en pg_stat_statements. El denominador común, según el artículo, son fallos de diseño detectados en la revisión posterior al commit, resultados erróneos o problemas de compatibilidad descubiertos tarde, y la mayoría de estas funciones se volverán a intentar en la versión 20. El mensaje de commit de GROUP BY ALL lo dice expresamente, y Layerbase lo considera el más probable de volver.
Hay un punto en disputa. La lista de Snowflake incluye el cambio de la compresión TOAST por defecto a lz4, pero Layerbase dice que no encontró esa reversión en el historial de commits y que la documentación actual sigue indicando lz4 como valor por defecto cuando la compilación lo admite. Comprueba el ajuste en tu propio servidor en lugar de fiarte de cualquiera de los dos textos.
Cómo se comparan 53 reversiones con versiones anteriores
Las reversiones son una parte normal de cómo se hace PostgreSQL. Los parches llegan a través de commitfests abiertos, se discuten en la lista de correo hackers y los incorpora alguno de los aproximadamente 30 committers; después se publica una beta y se prueba antes de la versión final y de sus actualizaciones trimestrales de mantenimiento, tal como explica el artículo de Snowflake.
Lo que destaca este año es el momento, no el volumen. PostgreSQL 18 tuvo unas 44 reversiones, según Snowflake, la mayoría poco después de empezar su beta. PostgreSQL 19 lleva 53 hasta ahora, y muchas llegaron tarde y afectaron a funciones destacadas. Christensen señala que retrasar una versión principal es algo que no ocurría en PostgreSQL desde hace mucho tiempo, y sostiene que el proceso funciona como debe: las funciones que no están listas se retiran, y el razonamiento es público.
El factor IA en el ciclo de revisión
El artículo de Snowflake atribuye parte de la explicación a la IA. Varios colaboradores usan herramientas de IA para encontrar fallos y construir casos de prueba reproducibles, y muchas de las reversiones tardías salieron de revisiones en profundidad generadas por IA. Robert Haas, uno de los principales colaboradores del proyecto, organizó un concurso de fallos con ayuda de IA que sacó a la luz más funciones en riesgo.
El efecto también se nota en la seguridad. PostgreSQL solía tener de media un par de CVE por versión, dice el artículo, mientras que el parche de agosto de 2026 para PostgreSQL 18 corrigió 28. El proyecto aún no tiene una política oficial sobre contribuciones hechas con IA, aunque se espera una pronto.
La IA está ya a ambos lados del código de infraestructura. Nuestro reportaje sobre cómo la reescritura de Bun en Rust llevó 11 días y costó 165.000 dólares mostró a agentes escribiendo un runtime a gran velocidad. PostgreSQL 19 muestra la otra cara: la revisión asistida por IA frenando una versión porque encontró problemas que a las personas se les habían escapado.
Lo que sigue en PostgreSQL 19
La versión sigue siendo sustancial. La función que probablemente más importe a quienes administran bases de datos es REPACK, que hace lo que hacían VACUUM FULL y CLUSTER, con una opción CONCURRENTLY. Como explica The Register, VACUUM FULL mantiene un bloqueo exclusivo durante toda la reescritura, impidiendo lecturas y escrituras, mientras que REPACK CONCURRENTLY deja que otras transacciones usen la tabla durante la mayor parte de la operación y solo necesita el bloqueo exclusivo brevemente, al intercambiar los archivos nuevos. La página de temas pendientes todavía recoge varios problemas de REPACK (CONCURRENTLY) en curso, así que pruébalo con cuidado.
Layerbase y Snowflake también mencionan pg_plan_advice para estabilizar las decisiones del planificador, el autovacuum en paralelo, ON CONFLICT DO SELECT para que los upserts devuelvan la fila existente, IGNORE NULLS y RESPECT NULLS en funciones de ventana, salida en JSON desde COPY TO, un nuevo comando WAIT para leer tus propias escrituras en una réplica y una cláusula EXCEPT para las publicaciones. Dos cambios de comportamiento merecen atención antes de actualizar: JIT pasa a estar desactivado por defecto, y default_toast_compression pasa a ser lz4 cuando la compilación lo admite.
Qué deberían hacer ahora los desarrolladores
El consejo práctico es probar con la beta en lugar de esperar. Layerbase señala que los directorios de datos de la beta no tienen garantizada la compatibilidad entre betas ni con la versión final, así que pasar de una a otra exige un volcado y una restauración en lugar de una actualización en el sitio.
Sigue la página de temas pendientes y la lista de correo hackers, porque todavía podrían retirarse más funciones. Y si contabas con las consultas de grafos, el merge y split de particiones o GROUP BY ALL, planifica para PostgreSQL 20. Para todos los demás, PostgreSQL 19 sigue siendo una actualización importante, solo que más tarde de lo que sugería el calendario.
