Postgres 19 se retrasó: la IA está encontrando demasiados bugs

Postgres 19 tenía que salir en septiembre, como casi todas las versiones mayores del proyecto, y todavía no ha salido. El motivo es curioso: no falta código, sobran bugs. Robert Haas, uno de los committers más veteranos de PostgreSQL, escribió un post con un título sin rodeos: Postgres 19 is late, and it's AI's fault. Según él, las herramientas de IA están encontrando problemas a un ritmo que la comunidad nunca había visto, y eso empujó el calendario.

Vale la pena detenerse un minuto en esta noticia. Dice mucho sobre Postgres 19, pero dice todavía más sobre cómo se va a hacer software de aquí en adelante.

¿Por qué se retrasó Postgres 19?

El ciclo de Postgres es bastante predecible. Feature freeze en abril, betas a mitad de año, release candidate y lanzamiento hacia septiembre. Postgres 17 salió en septiembre de 2024. El 18 salió en septiembre de 2025. Se puede planificar una actualización con base en eso.

En 2026 el engranaje se trabó en la fase de estabilización. Es en esa fase cuando la gente prueba lo que entró en el freeze y corrige lo que aparece. El problema es que ahora aparece mucho más.

Investigadores y contribuidores empezaron a apuntar modelos de IA al código fuente de Postgres. Leen el C, buscan caminos extraños, generan casos de prueba y reportan. Una parte es ruido. Pero una parte relevante son bugs de verdad: condiciones de carrera, errores de borde en el manejo de memoria, comportamiento incorrecto en combinaciones raras de features.

Y Postgres tiene una política que respeto mucho: un bug conocido en una feature nueva no llega al release. Si no se puede corregir con seguridad, la feature se queda fuera o el lanzamiento espera.

El cuello de botella no es encontrar bugs, es corregirlos

Aquí está el punto que me parece más interesante. Encontrar bugs se volvió barato. Corregirlos sigue siendo caro.

Para cada reporte, alguien tiene que:

• reproducir el problema
• entender si es un bug real o un falso positivo
• escribir el patch
• revisar el patch (en Postgres, esto va en serio)
• garantizar que la corrección no rompe otra cosa

Ninguna de esas etapas se volvió diez veces más rápida. La primera sí. El resultado es una cola que crece del lado de quienes tienen permiso de commit, que es un grupo pequeño de gente muy experimentada.

Encontrar bugs se volvió commodity. Revisar sigue siendo artesanía.

Quien ya ha sido responsable de un repositorio popular conoce la sensación. Abres GitHub por la mañana y tienes 40 issues nuevas. La mitad son duplicadas, unas cinco son reales y graves. Ahora imagina eso en una base de datos que corre las finanzas de medio mundo, donde un patch mal hecho se convierte en corrupción de datos en producción.

¿Esto es bueno o malo?

Mi opinión, sin matices: es bueno. Muy bueno, incluso.

Esos bugs ya estaban ahí. La IA no creó ninguno. Solo encendió la luz en una habitación que estaba a oscuras. La alternativa era que descubrieras el mismo bug a las tres de la mañana, con la base de datos bloqueada y el Slack en llamas.

Un retraso de algunas semanas, o de algunos meses, en una base de datos que va a correr en tu servidor durante cinco años es un precio bajo. Prefiero mil veces un Postgres 19 retrasado a un 19.0 que exija un 19.1 de emergencia dos semanas después.

Hay un lado menos bonito, claro. El costo de esta limpieza recae sobre voluntarios y sobre ingenieros pagados por unas pocas empresas. Generar un reporte automatizado cuesta centavos. Analizar cada uno cuesta horas de alguien que podría estar escribiendo features. Si la comunidad no crea filtros, el riesgo es que el mantenedor se agote antes de que se acaben los bugs.

Y esto no es exclusivo de Postgres. curl, Linux, OpenSSL y varios otros proyectos ya se han quejado de reportes generados por IA de baja calidad. La diferencia aquí es que buena parte de los hallazgos parece ser legítima. El problema no es la basura, es el volumen.

Qué cambia en tu actualización de Postgres

En la práctica, para quien usa Postgres en el día a día, el mensaje es simple.

No planifiques la actualización por la fecha del calendario. Si tu equipo tenía "migrar al 19 en el Q4" en el roadmap, revísalo. Espera al lanzamiento, y de preferencia espera al primer minor. Eso siempre fue buena práctica, ahora lo es todavía más.

Prueba la beta o el RC con tu carga de trabajo. Nadie conoce tus queries mejor que tú. Levanta un contenedor y corre tu suite contra él:

docker run -d --name pg19 -e POSTGRES_PASSWORD=dev -p 5433:5432 postgres:19rc1
DATABASE_URL=postgres://postgres:dev@localhost:5433/postgres bun test

Ajusta la tag a la versión de prueba que esté publicada. Si algo se rompe, repórtalo. Tu reporte con una reproducción real vale más que diez reportes genéricos.

Atento a los minors de las versiones actuales. Muchos de estos bugs no están solo en el código nuevo. Cuando la corrección afecta a versiones antiguas, se porta a los minors del 14 al 18. Así que es muy probable que los próximos releases de mantenimiento vengan más cargados de lo normal. Actualizar un minor es barato y normalmente no requiere pg_upgrade:

SELECT version();
-- PostgreSQL 18.1 ... entonces revisa si ya existe un 18.x más nuevo

Si usas una base de datos gestionada (RDS, Neon, Supabase, Cloud SQL), el minor suele llegar solo en la ventana de mantenimiento. Solo confirma que la ventana está configurada y que no quedó olvidada en 2022.

Qué enseña esto para tu propio código

Se puede sacar una lección que vale para cualquier proyecto, incluida esa API en Node que mantienes tú solo.

Si las herramientas de IA logran encontrar bugs en Postgres, uno de los códigos más revisados del open source, los van a encontrar en el tuyo. Esto funciona en los dos sentidos. Puedes usarlo a tu favor antes del lanzamiento, o alguien puede usarlo en tu contra después.

Lo que he estado haciendo en mis proyectos:

• correr revisión automatizada en los PR, pero tratar la salida como sugerencia, nunca como verdad
• pedirle a la herramienta que genere el test que reproduce el bug, no solo su descripción
• aceptar un hallazgo solo después de que el test falle de verdad en mi máquina

Este último punto elimina buena parte del ruido. Un reporte sin reproducción va al final de la cola. Un reporte con un test fallando se vuelve prioridad. Es exactamente el filtro que necesita un mantenedor sobrecargado.

La otra lección es sobre capacidad. Si tu equipo empieza a usar IA para revisar código, el número de problemas encontrados va a subir. Eso no significa que el código empeoró. Significa que vas a necesitar tiempo en el sprint para corregir. Quien no reserva ese tiempo crea una pila de issues que nadie mira, y entonces la herramienta se convierte en otra alarma ignorada.

¿Vale la pena esperar a Postgres 19?

Sí. Y la espera en sí es una buena señal.

Postgres se ganó la reputación de base de datos que no te deja tirado justamente por decisiones así: frenar el lanzamiento en vez de empujar código con bugs conocidos. La IA cambió el ritmo de la caza, pero la cultura de revisión sigue siendo la misma. Para quien guarda datos de clientes, es exactamente lo que quiero de una base de datos.

Lo gracioso es que, después de años escuchando que la IA iba a escribir todo el software del mundo, su primera gran contribución a Postgres fue darles más trabajo a los humanos. Al menos es trabajo del tipo correcto.

Uso Postgres en prácticamente todo lo que construyo, y voy a esperar el 19 con calma. Si quieres ver dónde corre por aquí, échale un vistazo a mis proyectos.

Postgres 19 se retrasó, y el motivo no es falta de código. Es exceso de bugs.

Las herramientas de IA están encontrando problemas en el código de Postgres a un ritmo que la comunidad nunca había visto. Y como el proyecto no lanza features con bugs conocidos, el calendario se fue al traste.

Lo que más me llamó la atención: encontrar bugs se volvió barato, corregirlos sigue siendo caro. Reproducir, revisar y garantizar que nada se rompió todavía depende de un grupo pequeño de gente muy experimentada.

Para mí es una gran noticia. Esos bugs ya estaban ahí. La IA solo encendió la luz antes de que aparecieran a las tres de la mañana en tu servidor de producción.

Si tu equipo empieza a usar IA para revisar código, reserva tiempo en el sprint para corregir lo que encuentre. Si no, se convierte en otra alarma que nadie mira.

Escribí sobre lo que esto cambia en tu actualización y en tu propio código. El enlace está en los comentarios.

#PostgreSQL #InteligenciaArtificial #OpenSource #DesarrolloDeSoftware #Backend