El equipo de PostgreSQL publicó el 15 de octubre la primera release candidate de PostgreSQL 19. Una RC es, por definición, prácticamente idéntica a lo que será la versión final: solo se esperan correcciones puntuales a partir de aquí. El calendario anunciado prevé una segunda candidata el 12 de noviembre y la disponibilidad general de PostgreSQL 19 el 19 de noviembre.
Entre los cambios que llegan a esta versión hay ajustes en REPACK CONCURRENTLY —la alternativa sin bloqueo a reorganizar una tabla—, en el nuevo asesor de planes pg_plan_advice, en el optimizador de consultas, en la replicación lógica y en el autovacuum en paralelo. Ninguno es un cambio aislado: todos inciden en los dos puntos que más dolores de cabeza dan en una instancia PostgreSQL grande en producción, que son el mantenimiento de las tablas y la calidad del plan de ejecución que elige el optimizador.
La relevancia para un equipo de datos en España no es menor. PostgreSQL sigue siendo el motor de referencia en las migraciones desde bases de datos propietarias, tanto por coste como por el ecosistema de extensiones que ha crecido a su alrededor. Una mejora en el autovacuum paralelo reduce directamente el tiempo en que una tabla grande queda con espacio muerto sin reclamar, que es uno de los problemas operativos más frecuentes en instancias con mucha escritura. Y un asesor de planes integrado facilita diagnosticar por qué una consulta ha dejado de usar el índice esperado, sin tener que interpretar a mano la salida de EXPLAIN ANALYZE.
El paso natural para cualquier equipo que dependa de PostgreSQL es probar esta RC en un entorno de staging, no esperar a la disponibilidad general para detectar regresiones. Es el mismo ciclo de todas las versiones mayores del proyecto: cuantas más instalaciones reales prueben la candidata, menos sorpresas aparecen en la versión final.
No hay anuncios de cambios incompatibles que rompan aplicaciones existentes, lo habitual en el proyecto, que cuida mucho la compatibilidad hacia atrás entre versiones mayores. Conviene de todos modos revisar las notas de la versión 19 completas antes de planificar la actualización, sobre todo si el equipo usa extensiones de terceros que dependan de APIs internas del motor.
El ritmo de publicación tampoco sorprende: PostgreSQL mantiene desde hace años un calendario anual fijo, con una versión mayor cada otoño y cinco años de soporte para cada una. Esa previsibilidad es precisamente uno de los argumentos que se repiten a favor del proyecto frente a motores comerciales con ciclos de lanzamiento menos regulares: quien planifica una migración sabe de antemano cuándo tendrá que volver a actualizar.
Más en Dataprix: guía de arquitectura de datos de Dataprix
Fuente: PostgreSQL.org
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.