PostgreSQL 19 se retrasa al 19 de noviembre y deja fuera sus mejores funciones
PostgreSQL 19 no sale en octubre: la disponibilidad general se movió al 19 de noviembre después de que una oleada de fallos, destapada en parte con revisión asistida por IA, superara la capacidad del equipo para corregirlos.
Qué pasó con PostgreSQL 19: las fechas nuevas
El PostgreSQL Global Development Group publicó la primera candidata de lanzamiento el 15 de octubre y, en el mismo anuncio, fijó la disponibilidad general para el 19 de noviembre de 2026. Entre medio va una segunda candidata, prevista para el 12 de noviembre. La fecha original apuntaba a finales de septiembre o principios de octubre, el mismo hueco de otoño que el proyecto usa cada año.
RC1 el 15 de octubre, RC2 el 12 de noviembre, GA el 19
El calendario oficial quedó así: Beta 1 el 4 de junio, Beta 4 el 24 de septiembre, RC1 el 15 de octubre, RC2 el 12 de noviembre y GA el 19 de noviembre. La congelación de funciones había ocurrido mucho antes, el 8 de abril.
El plan original: finales de septiembre o principios de octubre
PostgreSQL 18 salió el 25 de septiembre de 2025, así que la expectativa era repetir la ventana. Un release candidate no es una promesa de entrega: es una versión que, si aparece un problema serio, se retrasa. Eso fue exactamente lo que ocurrió.
Lee también
Seis meses de betas: del 4 de junio a la congelación de abril
Entre la congelación y la candidata pasaron seis meses de pruebas con usuarios reales. Ese periodo es donde se acumulan los reportes de defectos, y este año se acumularon más de lo habitual.
La causa: encontrar fallos se volvió barato
La explicación que circula como titular —"la IA retrasó PostgreSQL"— es una versión corta de algo más interesante: encontrar defectos se abarató mucho, y arreglarlos sigue siendo trabajo humano de voluntarios.
Lo que reporta The Register
El medio británico publicó el 16 de octubre que la oleada de reportes de defectos durante el beta superó la capacidad del equipo para corregirlos antes de la fecha. En el mismo texto se describe el papel de la revisión asistida por IA: encuentra fallos más rápido de lo que se pueden cerrar.
El análisis de Shaun Thomas y el hilo de pgsql-hackers
Shaun Thomas, de pgEdge, revisó los revertidos siguiendo el hilo de la lista pgsql-hackers y llegó a la misma conclusión desde dentro de la comunidad. Contó incluso que le pidió a Claude que ordenara los parches de la versión 19 "más peligrosos" según los errores corregidos después de la congelación. Eso es una anécdota del analista, no una declaración del proyecto.
Los committers son voluntarios: el cuello de botella es humano
Lo que el proyecto comunicó fueron fechas y decisiones, sin atribuir causas. La parte que importa para cualquiera que mantenga software: las herramientas generan hallazgos a un ritmo que la revisión humana no puede seguir. Si tu pipeline escupe 300 hallazgos por semana y cierras 40, no tienes un problema de calidad: tienes un problema de cola.
Las funciones que se quedaron fuera
El proyecto prefirió recortar alcance antes que publicar código roto. La decisión tiene un costo visible: funciones que se anunciaron en primavera no estarán en la versión de noviembre.
SQL/PGQ: las consultas de grafos que eran el titular del release
SQL/PGQ llevaba consultas de grafo al SQL estándar, sin extensión: recorrer relaciones —quién sigue a quién, rutas, dependencias— sin pegar tablas a mano. Era la función más esperada de la versión y se revirtió días antes de la fecha prevista. Algunos análisis hablan de cerca de medio centenar de commits revertidos; la cifra conviene atribuirla.
Entre ocho y diez funciones importantes, retenidas
Según The Register, fueron entre ocho y diez las funciones significativas que se retiraron del lanzamiento. La cifra exacta no está confirmada por el proyecto, así que se cita como rango.
Qué pasa con ellas: la promesa de PostgreSQL 20
Peter Eisentraut dijo a The Register que lo revertido probablemente llegue en PostgreSQL 20, una versión que hasta hace poco se esperaba sin funciones nuevas, solo correcciones. Es decir: el trabajo no se pierde, se mueve un año.
Qué sí llega en PostgreSQL 19
La versión no es un lanzamiento vacío. Estas son las funciones confirmadas en las notas de la 19.0:
- REPACK y REPACK CONCURRENTLY. Reorganizan la tabla y recuperan espacio, absorbiendo lo que hacían
VACUUM FULLyCLUSTER. La variante concurrente no bloquea lecturas ni escrituras. - pg_plan_advice. Consejos de plan dentro del núcleo, sin extensiones de terceros: cierra una brecha histórica del planificador.
- Autovacuum en paralelo. Varios procesos de limpieza sobre la misma operación, útil en tablas grandes.
- I/O asíncrono que se ajusta solo. Con
io_method=worker, el número de workers se regula conio_min_workerseio_max_workers, sobre la base que dejó la 18. - Mejoras en replicación lógica. Ajustes de sincronización y conflictos que reducen trabajo manual en réplicas.
Qué significa para tu proyecto
Para quien administra una base de datos, la noticia se traduce en tres decisiones concretas y ninguna es urgente.
Si tenías la migración en el calendario de este trimestre
No esperes PostgreSQL 19 en tu proveedor antes de diciembre: las plataformas gestionadas esperan la GA y después hacen sus propias pruebas. Si tu hoja de ruta dependía de SQL/PGQ, no hay atajo: extensión de terceros o esperar a la 20.
Cómo probar la RC1 sin arriesgar producción
La RC1 sirve para staging y para reproducir problemas, nunca para producción. Si estás planeando el salto de motor, el trabajo útil de estas semanas no es esperar la 19 sino preparar el terreno: la guía para migrar de MySQL a PostgreSQL en Laravel 13 cubre el inventario, el ensayo y el corte con rollback.
La lección para tu equipo: más hallazgos de los que puedes cerrar
El patrón se repite en cualquier equipo: análisis estático, linters y revisión con IA producen hallazgos mucho más rápido que la capacidad de triagear, arreglar y volver a probar. Lo que hizo PostgreSQL —recortar alcance y mover la fecha— es la decisión que casi nadie toma en un sprint, y por eso conviene tenerla escrita antes de necesitarla.
Conclusión
Un proyecto que recorta alcance para no romper da más confianza que uno que llega a tiempo con deuda. Las fechas a mirar son el 12 y el 19 de noviembre: si la RC2 aparece sin sorpresas, la GA se mantiene. Mientras tanto, producción sigue en PostgreSQL 18, y en el blog hay más guías de bases de datos y de Laravel en producción para seguir leyendo.
