La versión 19 de PostgreSQL, una de las bases de datos de código abierto más usadas del mundo, llegará más tarde de lo previsto. El equipo de lanzamientos ha movido la versión final al 19 de noviembre, en lugar del 29 de octubre, y ha añadido una segunda versión candidata, el 12 de noviembre. Antes, los desarrolladores retiraron entre 8 y 10 funciones importantes que ya estaban dentro, y el motivo ha abierto un debate en la comunidad: ¿cuánto ha tenido que ver la revisión de código con inteligencia artificial?
PostgreSQL publica una versión grande cada año. Las funciones nuevas se congelan en primavera, las versiones beta salen en verano y la final suele llegar entre septiembre y octubre. Que alguna función se caiga durante la beta es normal: una por ciclo, según Peter Eisentraut, uno de los desarrolladores con permiso para incorporar cambios al código. Esta vez han sido «unas 8 a 10 funciones importantes, según cómo se cuente», y algunas en plena recta final.
Claves del retraso
- Las fechas. La primera versión candidata salió el 15 de octubre, como estaba previsto. Jonathan Katz, del equipo de lanzamientos, explicó que, por «el volumen de correcciones» acumuladas, prefieren publicarlas en una segunda candidata antes de dar la versión por terminada. «Sabemos que ha sido un ciclo atípico», reconoció.
- Lo que se cae. La más vistosa son las consultas de grafos SQL/PGQ, que entraron en el estándar SQL en 2023: se retiraron el 7 de septiembre, con 47 cambios detrás. También se han quitado la división y unión de particiones con
ALTER TABLE, y, según el recuento del consultor Christophe Pettus, la activación de sumas de verificación sin parar la base de datos y las órdenesUPDATEyDELETEpor intervalos de tiempo (FOR PORTION OF), entre otras. El motivo oficial: «múltiples problemas de diseño que ya es tarde para resolver en este ciclo». Pasan a PostgreSQL 20. - Lo que se queda.
REPACK CONCURRENTLY, que recupera el espacio en disco sin bloquear la tabla, como hasta ahora hacíaVACUUM FULL; el autovacuum en paralelo;pg_plan_advice, para orientar al planificador de consultas; la replicación lógica de secuencias y la exportación de consultas a JSON conCOPY. - La explicación de la IA. Eisentraut cree que la revisión con modelos de lenguaje encuentra «mucho más rápido» una larga cola de fallos en casos límite, poco graves pero numerosos, que antes habrían aparecido mucho después. El resultado es que los desarrolladores acaban mirando «una lista de unos cuarenta informes de fallos», cada uno con su arreglo y su revisión, y se quedan sin tiempo. «El listón de calidad efectivo ha subido después de que la función se escribiera», resume. Aclara que no es culpa de código escrito por IA: casi todas esas funciones son anteriores.
- La otra explicación. De abril a agosto, los desarrolladores más veteranos estuvieron dedicados a parches de seguridad: la página de seguridad de PostgreSQL ya registra 44 fallos con número CVE de 2026, frente a 7 de todo 2025. Pettus, citando un análisis de doce retiradas hecho por el desarrollador Tomas Vondra, sostiene que la mayoría salieron de revisiones humanas, con un solo caso claro en el que la IA dio la pista. «La revisión no aumentó. Llegó tarde», escribe. El propio Eisentraut también incluye esta causa en su lista.
Por qué importa
PostgreSQL está detrás de millones de aplicaciones, y el proyecto ha preferido retrasar la fecha y retirar funciones antes que publicar algo con fallos difíciles de corregir. El caso muestra además un efecto de la IA en el software libre del que se habla poco: las herramientas que revisan código pueden encontrar fallos más deprisa de lo que un grupo pequeño de voluntarios y empleados es capaz de corregirlos, y el cuello de botella pasa a ser el tiempo de las personas. Los desarrolladores ya hablan de usar la IA también para probar las funciones desde el principio, de definir un estado «experimental» para las novedades y de pedir que se declare cuándo una revisión se ha hecho con IA. Mientras tanto, para quien tenga PostgreSQL en producción, la recomendación habitual se mantiene: esperar a que la 19 madure y seguir con la 18.
Datos contrastados con el aviso del equipo de lanzamientos, el anuncio de la primera versión candidata, la página de seguridad de PostgreSQL, el blog de Peter Eisentraut, el de Christophe Pettus y el de Command Prompt. Portada: un elefante, la mascota de PostgreSQL, en el parque nacional de Murchison Falls (Uganda), foto de Ssemmanda will, Wikimedia Commons, CC BY-SA 4.0 (recortada, con texto).
Fuente: The Register, «Postgres 19 delayed after AI reviewers find more bugs than humans can fix»