PostgreSQL 19 no sale en octubre. Sale alrededor del 19 de noviembre, y por el camino se han quedado fuera entre ocho y diez funcionalidades de peso. El motivo que da uno de los committers principales es lo que hace que la noticia merezca la pena: la revisión de código asistida por modelos de lenguaje destapó más defectos de los que había tiempo material de cerrar antes de la fecha.
Qué ha pasado
La versión estaba prevista para finales de septiembre o principios de octubre. Ahora se espera disponible de forma general hacia el 19 de noviembre. Peter Eisentraut, vicepresidente en EDB y uno de los committers de referencia del proyecto, lo explicó en su blog y The Register lo recogió.
Hay dos cosas distintas mezcladas, y conviene separarlas:
- Defectos arquitectónicos serios en algunas de las funcionalidades retiradas. De esos no se sale con un parche rápido en plena beta.
- Una cola larga de problemas menores, casos límite más o menos inofensivos que antes habrían ido apareciendo poco a poco en los cinco años siguientes al lanzamiento, a base de correcciones sueltas.
Lo segundo es lo nuevo. Eisentraut lo describe con una imagen muy reconocible: te plantas delante de una lista de cuarenta informes de defecto y, aunque cada uno se resuelva con tres líneas de media, cada uno tiene su coste fijo —reproducirlo, escribir el test, pasar revisión, decidir si va a ramas anteriores— y el tiempo se acaba.
Su diagnóstico es que el listón de calidad subió después de que el código estuviera escrito y aceptado: cuando se desarrollaron las funcionalidades grandes, la revisión con modelos no era tan útil como en los meses previos al lanzamiento. Y deja claro que esto no va de vibe coding: la mayor parte de ese código se escribió cuando esa técnica ni estaba disponible.
Entre lo que se cae está el soporte de consultas sobre grafos de propiedades (SQL/PGQ), que entró en el estándar SQL en 2023 y permite expresar relaciones entre nodos y aristas. Tom Lane lo avisó sin anestesia:
Me apostaría una cena a que, si lo publicamos en la v19, aparecerán fallos que no se podrán arreglar hasta la v20.
Lo que sí llega: REPACK CONCURRENTLY, que recupera espacio en disco sin el bloqueo exclusivo de tabla que exige VACUUM FULL. Y un efecto secundario curioso en la planificación: hace unos meses se daba por hecho que PostgreSQL 20 sería una versión de solo correcciones; ahora se llevará las funcionalidades que se han quedado en el tintero.
Por qué importa
Esto no es una anécdota de un proyecto de base de datos. Es el primer caso público y bien documentado de un cambio que va a tocar a cualquiera que enchufe un revisor automático a su repositorio: el cuello de botella se ha movido. Detectar defectos ha pasado a ser barato. Clasificarlos, reproducirlos y cerrarlos cuesta exactamente lo mismo que antes.
Tres consecuencias prácticas:
1. El coste fijo por hallazgo manda. Cuarenta parches de tres líneas no son dos horas de trabajo: son cuarenta ciclos de contexto, revisión y decisión. Si vas a meter revisión con modelos, mide el coste de cerrar un hallazgo medio en tu equipo antes de encender la manguera. Si no tienes ese número, lo que vas a conseguir es una lista que nadie mira.
2. El listón se mueve debajo de tus pies. Código que pasó revisión humana en marzo suspende en septiembre con herramientas mejores. Eso va a pasar en todas las bases de código del mundo, no solo en PostgreSQL. La lectura operativa: pasa el revisor cuando se escribe la funcionalidad, no la semana antes del congelado. Lo que encuentres en beta ya no es información, es un problema de calendario.
3. Si tenías la 19 en el plan de otoño, muévela. Y si estabas esperando las consultas de grafo para quitarte una base de datos de en medio, ese plan se va al ciclo siguiente. No construyas encima de algo que todavía no ha salido.
Qué no cambia
El titular se lee peor de lo que es. Aquí no hay una IA escribiendo código malo que luego otra IA descubre: el propio Eisentraut se molesta en aclararlo. Los defectos arquitectónicos de las funcionalidades retiradas son de toda la vida, de los que detecta —o no— una revisión humana.
Tampoco es un desastre de proyecto. Es un retraso de unas seis semanas en un ciclo anual, con las funcionalidades aplazadas a la siguiente versión y una versión final que, según él, saldrá más robusta precisamente por el repaso extra. Preferir eso a publicar y arrastrar fallos cinco años es una decisión, no un accidente.
Y hay un número que me falta: cuántos de esos informes eran defectos reales y cuántos ruido. La fuente no lo desglosa, y es justo el dato que necesitaría cualquiera que esté valorando montar lo mismo en su casa.
Nuestra lectura
Me parece una buena noticia, y la prefiero contada así, con nombre y apellidos, a la versión limpia de nota de prensa. Un proyecto que retira ocho funcionalidades en beta te está diciendo algo muy valioso sobre lo que significa su palabra «estable».
Donde no estoy de acuerdo es en el optimismo final. Eisentraut apunta a que la situación se arreglará sola en los próximos ciclos si los revisores siguen mejorando al ritmo actual. Mi apuesta es la contraria: cuanto mejor detecte la herramienta, más larga será la cola. Esto no se arregla con mejores detectores, se arregla con proceso —clasificación por severidad, un criterio explícito de qué casos límite se quedan abiertos y quién firma esa decisión—. Si lo dejas en manos de la herramienta, el listón sube indefinidamente y nunca publicas.
Esto ya lo hemos visto pasar, por cierto. Cuando enchufas un analizador estático nuevo a una base de código de diez años, te salen miles de avisos y el equipo entra en parálisis. Lo que funcionó entonces fue la línea base: congelas lo que hay, lo marcas como deuda conocida y exiges el listón nuevo solo al código nuevo. PostgreSQL no puede hacer exactamente eso con una funcionalidad ya aceptada y en beta, pero la idea de fondo sirve: el listón se decide antes del congelado, no cuando ya tienes la lista delante.
Es el mismo patrón que nos encontramos cuando metemos un modelo a revisar código o documentos dentro de un proceso de empresa: generar hallazgos es gratis, cerrarlos no. La parte cara del proyecto nunca es el modelo, es decidir quién mira cada hallazgo y qué se hace con los que no se van a arreglar.
Cualquier duda me dices y lo vemos. Un saludo, Vicente.