La IA frenó PostgreSQL 19: encontró 40 bugs que faltaban

PostgreSQL 19 no saldrá cuando estaba previsto. Y la culpa no es de la IA escribiendo código, sino de la IA revisándolo. El equipo de desarrollo del motor de bases de datos más popular del mundo acaba de posponer el lanzamiento y revertir hasta diez funciones importantes porque los revisores automáticos encontraron más fallos de los que había manos para arreglar.

Si programa en Python, JavaScript, Go o cualquier lenguaje conectado a una base de datos, esto le afecta directamente. Y lo pone frente a una pregunta incómoda: ¿los asistentes de código realmente nos aceleran, o nos están poniendo a trabajar de verdad por primera vez?

La fecha nueva: el 19 de noviembre

PostgreSQL 19 estaba agendado para finales de septiembre o principios de octubre. Ahora el PostgreSQL Global Development Group apunta al 19 de noviembre, con entre ocho y diez funciones retiradas del ciclo y empujadas a Postgres 20.

Peter Eisentraut, vicepresidente de EDB y uno de los committers con más peso del proyecto, explicó el motivo en un blog: parte de las funciones revertidas tenían defectos arquitectónicos que no se podían arreglar "rápido y durante la beta".

El dato que lo cambia todo

Aquí viene lo interesante. Eisentraut no culpó a la generación de código con IA. De hecho aclaró que no hubo "vibe coding", porque la mayoría de esas funciones se escribieron cuando la técnica ni existía.

El culpable es otro: la revisión de código asistida por LLM. Esas herramientas destaparon una cola larga de errores en casos límite que antes nadie veía hasta años después del lanzamiento.

Su explicación, textual: "Con la revisión asistida por LLM, este tipo de cosas se detectan mucho más rápido, y entonces estás mirando una lista de cuarenta reportes de defectos. Aunque cada uno requiera un arreglo de tres líneas en promedio, hay un costo fijo por atender cada reporte, y entonces se te acaba el tiempo."

Cuarenta defectos. Tres líneas cada uno. Y aún así no alcanzó. Ese es el nuevo cuello de botella del software moderno: no es escribir, es decidir.

Lo que se cae de Postgres 19

La baja más dolorosa es SQL Property Graph Queries (SQL/PGQ), que entró al estándar SQL en 2023 y permite consultar relaciones entre nodos conectados por aristas. Su implementación fue removida por problemas sin resolver.

El contributor Tom Lane lo advirtió antes: "A estas alturas estaría dispuesto a apostar una cena a que si lo lanzamos en la v19 habrá descubrimientos de bugs post-lanzamiento que no se podrán arreglar hasta la v20." Acertó.

Lo que sí sobrevive es REPACK CONCURRENTLY, que evita el bloqueo de tabla del VACUUM FULL al recuperar espacio en disco. Para cualquiera que haya sufrido un mantenimiento en producción a las 3 de la mañana, eso solo vale la espera.

Por qué esto importa en LATAM

PostgreSQL es la base de datos preferida de los desarrolladores profesionales, y buena parte de esa posición viene de que los tres grandes hyperscalers construyeron servicios sobre él: RDS, Cloud SQL, Azure Database y hasta los sistemas distribuidos wire-compatible como CockroachDB y YugabyteDB.

Traducción regional: si su proyecto corre sobre un Postgres gestionado, su proveedor no va a subir a la v19 hasta meses después del lanzamiento estable. Con diez funciones retiradas, la brecha entre la versión comunitaria y los servicios en la nube se estrecha, no se agranda. Programe para la v18 y no cuente con PGQ en 2026.

¿La IA nos está volviendo más lentos o más honestos?

Hay dos formas de leer esto. La cínica: una herramienta nueva metió ruido, infló la lista de pendientes y frenó un lanzamiento que llevaba un año de planificación.

La honesta, y creo que es la correcta: durante treinta años el software se lanzó con una deuda técnica invisible que se pagaba en parches silenciosos durante cinco años. Lo que cambió no es la cantidad de bugs. Cambió que ahora los vemos antes de enviarlos, y eso incomoda mucho más que arreglarlos después en silencio.

Eisentraut apunta a que el problema se corrige solo: la calidad efectiva exigida subió después de que las funciones se escribieron. Los próximos ciclos se planificarán sabiendo que el listón ahora vive más alto.

Mientras tanto, Postgres 19 llega en noviembre, más tarde y más pequeño. Y probablemente más sólido que cualquier versión anterior.

¿Y usted qué prefiere: lanzamientos rápidos con parches eternos, o esperar dos meses por un motor que aguante en producción? Comparta esto con el que en su equipo todavía cree que la IA en el código es solo para escribir más rápido. La parte difícil nunca fue escribir.