Robert Haas, committer principal de PostgreSQL, publicó el 30 de octubre una entrada en su blog para explicar por qué la versión mayor de este año llega tarde. Durante la última década, las versiones principales de PostgreSQL salieron siempre entre mediados de septiembre y mediados de octubre, pero PostgreSQL 19 probablemente tendrá que esperar a noviembre, y el proyecto podría retrasarlo aún más. La razón que da cabe en una frase:
"The short answer is that LLMs happened." (En pocas palabras: llegaron los LLM.)
Haas es hoy ingeniero de software senior (senior staff) en Databricks. El texto es una valoración personal suya y no ofrece una nueva fecha de lanzamiento.
Tres grandes funciones retiradas en el último mes
La congelación de funciones se produce cada año el 8 de abril, y retirar funciones después de la congelación no es raro. Lo distinto este año es el momento y el calado: entre el 27 de agosto y el 15 de septiembre se revirtieron sucesivamente tres funciones importantes.
UPDATE/DELETE FOR PORTION OF- Consultas de grafos de propiedades en SQL (SQL/PGQ)
ALTER TABLE ... MERGE PARTITION / SPLIT PARTITION
Según Haas, en otros años también se retiran funciones, pero rara vez tan tarde y rara vez varias de peso a la vez.
Los commits suben un sesenta por ciento, sin que los committers sean más descuidados
Fija la ventana de conteo cada año entre el 8 de abril y el 25 de septiembre para comparar el volumen de correcciones. El año pasado entraron 724 commits en REL_18_STABLE; este año, 1169 en REL_19_STABLE, un aumento de más del 60 %. En la rama estable anterior, REL_17_STABLE sumó 248 el año pasado y REL_18_STABLE suma 433 este año, un incremento de más del 74 %.
Haas no cree que ese aumento de commits se deba a que la gente escriba peor código. Considera que el cuidado de los committers es parecido al de otros años; el cambio está en la fase de detección: mucha gente ha empezado a usar LLM para cazar bugs en PostgreSQL y los reporta directamente.
"What's different now is that it's become vastly easier to find those bugs." (Lo que ha cambiado es que ahora resulta muchísimo más fácil encontrar esos bugs.)
Esta atribución tiene un hueco: el historial de commits no registra quién descubrió cada bug ni con qué herramienta, y el artículo tampoco indica qué proporción corresponde a informes de LLM. Los aumentos citados son datos medidos; lo de "principalmente por los LLM" es la observación de un committer veterano.
El cuello de botella es la revisión humana
El mecanismo del retraso tiene dos capas. La primera: con más bugs, corregirlos lleva naturalmente más tiempo. Los LLM pueden redactar parches, pero un parche no es necesariamente correcto ni necesariamente conforme a las normas del proyecto, y al final un committer tiene que revisarlos uno por uno antes de integrarlos. La segunda capa es más sutil: el tiempo que debía dedicarse a revisar el contenido de la nueva versión lo consumen los problemas de seguridad y los defectos de ramas antiguas, de modo que decidir qué funciones retirar también se retrasa.
Esto puede ponerse junto al experimento de Firefox de Epoch AI de hace unos días. Epoch midió el lado del ataque: usó GLM 5.3 para escribir exploits en la ventana que se abre tras publicarse un parche, con un coste de cómputo de unos 1000 dólares por versión. Haas habla del lado del mantenimiento: la misma capacidad aplicada a un proyecto con décadas de historia hace subir primero el volumen de informes, mientras que el número de personas capaces de revisar código no sube con él. La variable común a ambos lados es el coste de encontrar vulnerabilidades, que cae más rápido que el de corregirlas.
Tampoco queda lejos de los equipos de China. Muchos productos de bases de datos en la nube se desarrollan a partir de PostgreSQL; si el volumen de integraciones en upstream sube entre un sesenta y un setenta por ciento, la carga de trabajo de seguir los parches en downstream también podría crecer en proporción. Cuán grande sea el impacto, hasta ahora ningún proveedor ha dado cifras.
Cuarenta años de bugs acumulados son la presión a largo plazo
Al propio Haas no le inquieta el retraso. Dice que, en un ciclo largo, no es mucho tiempo y que nace de la exigencia de calidad del proyecto. También subraya que el hecho de que la IA encuentre estos problemas no ha cambiado su valoración de la calidad del código.
Lo que le deja sin red es lo que viene después. El proyecto ha acumulado unos cuarenta años de bugs que los humanos no habían detectado, los LLM pueden desenterrar muchos de ellos, y en sus propias palabras: "how are we ever going to catch up". A partir de ahora, cada función nueva será revisada por una IA, lo que supone presión, pero también puede dejar el código más sólido. No ofreció una solución; solo dijo que él y mucha gente están buscando la manera.
En qué fecha saldrá por fin PostgreSQL 19 dependerá de los próximos anuncios del equipo de lanzamiento.
Fuentes: blog personal de Robert Haas; CocoLoop; informe público del experimento de Epoch AI; las estadísticas de commits por rama siguen el criterio del texto de Haas y no se recalcularon por separado.