PostgreSQL 19 incorpora el reempaquetado nativo de tablas (repacking), más control sobre los planes de consulta y mejoras en la replicación y el mantenimiento. Con la disponibilidad general prevista para el 19 de noviembre de 2026, los equipos deberían evaluar las ventajas junto con importantes limitaciones de compatibilidad y de operación.
Una actualización de versión mayor de PostgreSQL puede cambiar la forma en que una aplicación consulta, mantiene y replica sus datos. Esos cambios pueden mejorar el rendimiento y reducir el trabajo operativo. También pueden poner al descubierto dependencias que no eran evidentes con una versión anterior. PostgreSQL 19 hace que esa evaluación sea oportuna.
El PostgreSQL Global Development Group publicó PostgreSQL 19 RC1 el 15 de octubre de 2026. RC2 está prevista para el 12 de noviembre, y la disponibilidad general, para el 19 de noviembre, siempre que no surjan problemas que bloqueen el lanzamiento. Una versión candidata (release candidate) es en su mayor parte idéntica a la versión final prevista, aunque todavía pueden aplicarse algunas correcciones antes de la disponibilidad general.
A fecha de 6 de noviembre, PostgreSQL 19 sigue siendo una versión candidata. Es una versión preliminar y los equipos deberían probarla fuera de producción. La pregunta útil para los equipos de bases de datos es qué cambios merecen pruebas antes de la versión final.
¿Qué cambia?
PostgreSQL 19 aporta mejoras en el mantenimiento de tablas, la planificación de consultas, la replicación y las operaciones de bases de datos.
| Capacidad | Qué cambia | Qué deberían evaluar los equipos |
|---|---|---|
REPACK nativo | Reescribe tablas para recuperar espacio en disco | Bloqueos, necesidades de almacenamiento y visibilidad de las transacciones |
pg_plan_advice | Influye en determinadas decisiones del planificador | Rendimiento de las consultas y riesgo de indicaciones desactualizadas |
| Operaciones de vacuum mejoradas | Mantenimiento paralelo de índices y mejoras en la priorización | Uso de recursos del mantenimiento |
| Replicación lógica | Sincronización de secuencias y activación más flexible | Comportamiento durante la migración y la conmutación (switchover) |
Comando WAIT en el servidor en espera (standby) | Espera a una posición especificada del registro de escritura anticipada (write-ahead log, WAL) | Consistencia de lectura, latencia y gestión de los tiempos de espera |
| Cambios de compatibilidad | Valores predeterminados modificados y funcionalidades eliminadas | Dependencias de aplicaciones, autenticación y extensiones |
Estas capacidades responden a necesidades distintas. Los equipos deberían priorizar las que resuelven un problema operativo real en lugar de probar todas las funciones por igual.
Fuente: PostgreSQL 19 preliminary release notes.
1. El REPACK nativo ofrece una nueva opción de mantenimiento
Las tablas de PostgreSQL pueden acumular espacio sin usar a medida que se actualizan o eliminan filas. El VACUUM habitual hace que gran parte de ese espacio pueda reutilizarse, pero normalmente no lo devuelve al sistema operativo. PostgreSQL 19 incorpora el comando nativo REPACK, que reescribe una tabla y sus índices para recuperar espacio. También puede reorganizar las filas según un índice.
La opción CONCURRENTLY permite la actividad normal de la tabla durante gran parte de la operación, con lo que se evita el bloqueo exclusivo prolongado que exige una reescritura convencional de la tabla. Es útil, pero el reempaquetado concurrente tiene limitaciones importantes.
No es seguro con MVCC (MVCC-safe). MVCC (control de concurrencia multiversión) es el mecanismo que permite que cada transacción trabaje a partir de una instantánea (snapshot) coherente de los datos. PostgreSQL advierte que las transacciones que usan instantáneas tomadas antes de que comenzara la operación de reempaquetado pueden ver la tabla vacía después de que se confirme la transacción de reempaquetado.
El reempaquetado concurrente también usa un bloqueo exclusivo durante su fase final de intercambio de archivos. Necesita suficiente espacio temporal en disco para alojar otra copia de la tabla y de sus índices, y puede requerir almacenamiento adicional para la ordenación y las modificaciones concurrentes.
Se aplican otras restricciones. Por ejemplo, el reempaquetado concurrente no está disponible para tablas particionadas, tablas sin registro (unlogged) ni determinadas tablas sin información de identidad adecuada. Un reempaquetado también puede fallar si se ejecutan comandos DDL, que cambian la estructura de una tabla, sobre la tabla durante el reempaquetado, o en otras condiciones documentadas.
Por estos motivos, no debería tratarse como un sustituto directo del VACUUM rutinario. Los equipos de bases de datos deberían probar primero tablas representativas, la capacidad de disco disponible, el comportamiento de las transacciones, los bloqueos y los procedimientos de recuperación. Cuando la preocupación es prevenir el desbordamiento (wraparound) de los ID de transacción, PostgreSQL sigue recomendando VACUUM, no REPACK.
Qué ofrece
PostgreSQL 19 incorpora el comando nativo REPACK, que reescribe una tabla y sus índices para recuperar espacio. La opción CONCURRENTLY permite la actividad normal de la tabla durante gran parte de la operación, con lo que se evita el bloqueo exclusivo prolongado que exige una reescritura convencional de la tabla.
Límites clave
No es seguro con MVCC (MVCC-safe). PostgreSQL advierte que las transacciones que usan instantáneas tomadas antes de que comenzara la operación de reempaquetado pueden ver la tabla vacía después de que se confirme la transacción de reempaquetado. El reempaquetado concurrente también usa un bloqueo exclusivo durante su fase final de intercambio de archivos. Necesita suficiente espacio temporal en disco para alojar otra copia de la tabla y de sus índices, y puede requerir almacenamiento adicional para la ordenación y las modificaciones concurrentes.
Pruebas
Los equipos de bases de datos deberían probar primero tablas representativas, la capacidad de disco disponible, el comportamiento de las transacciones, los bloqueos y los procedimientos de recuperación. Cuando la preocupación es prevenir el desbordamiento (wraparound) de los ID de transacción, PostgreSQL sigue recomendando VACUUM, no REPACK.
Fuente: PostgreSQL 19, REPACK command documentation.
2. La planificación de consultas se vuelve más controlable
PostgreSQL normalmente elige los planes de ejecución a partir de estadísticas, estimaciones de costo y reglas del optimizador. En ocasiones, sus estimaciones llevan a un plan con un rendimiento deficiente para una carga de trabajo concreta. PostgreSQL 19 incorpora el módulo pg_plan_advice, que permite a los equipos describir determinadas decisiones del planificador (planner) e influir en ellas. La extensión relacionada pg_stash_advice puede asociar indicaciones (advice) almacenadas a consultas individuales.
Estas herramientas pueden ayudar a los equipos a investigar regresiones de planes o a estabilizar un plan que se sabe útil. Sin embargo, las indicaciones de planificación no sustituyen al optimizador de consultas. Funcionan restringiendo las opciones disponibles del planificador. No pueden obligar a PostgreSQL a usar un plan que el planificador considere no válido o que no genere.
Las indicaciones también pueden volverse perjudiciales cuando cambian la distribución de los datos, los índices o las características de la carga de trabajo. Por ejemplo, una indicación que favorece un índice concreto podría ayudar hoy a una consulta, pero volverse ineficiente después de que la tabla subyacente crezca de forma considerable.
El enfoque correcto es empezar con estadísticas fiables, índices adecuados y análisis de consultas. Las indicaciones para el planificador solo deberían introducirse cuando haya evidencia repetible que lo justifique. Los equipos también deberían vigilar si las indicaciones proporcionadas siguen siendo aplicables con el tiempo.
Fuentes: PostgreSQL 19, pg_plan_advice documentation y PostgreSQL 19 preliminary release notes.
3. La replicación se vuelve más flexible
PostgreSQL 19 introduce cambios que podrían simplificar determinados flujos de trabajo de replicación y migración. Una mejora permite que los suscriptores (subscribers) de la replicación lógica mantengan los valores de las secuencias alineados con el publicador (publisher). Esto puede ser útil durante migraciones en las que los identificadores generados deben seguir siendo correctos después de una conmutación (switchover).
PostgreSQL 19 también permite habilitar la replicación lógica, en las condiciones admitidas, cuando wal_level está configurado en replica, sin el reinicio que antes se asociaba a cambiar esa configuración. Estos cambios reducen parte del trabajo de configuración y migración, pero no eliminan la necesidad de verificar la sincronización, la consistencia de los datos o el comportamiento ante una conmutación por error (failover). Otra mejora significativa afecta a la consistencia de lectura en los servidores standby.
El comando WAIT y la consistencia de leer tus propias escrituras (read-your-writes)
En la replicación asíncrona, una escritura puede confirmarse (commit) en el primario antes de que un standby la haya reproducido (replay). Por eso, una aplicación que lee inmediatamente del standby puede ver datos más antiguos. PostgreSQL 19 incorpora WAIT FOR LSN, que permite a una aplicación esperar hasta que se haya alcanzado una posición especificada del registro de escritura anticipada. Un número de secuencia del registro (log sequence number, LSN) identifica una posición en el registro de escritura anticipada.
Para lograr el comportamiento read-your-writes, la aplicación debe obtener del primario una ubicación del WAL adecuada después de que se confirme la transacción correspondiente y, luego, esperar a que esa ubicación se reproduzca en el standby. Importa la distinción entre que el WAL se haya escrito, volcado a disco (flushed) o reproducido. Solo una reproducción correcta establece que los cambios confirmados correspondientes están disponibles para las lecturas posteriores en ese standby.
Commit en el primario
En la replicación asíncrona, una escritura puede confirmarse (commit) en el primario antes de que un standby la haya reproducido (replay). Por eso, una aplicación que lee inmediatamente del standby puede ver datos más antiguos.
Toma la posición WAL
Para lograr el comportamiento read-your-writes, la aplicación debe obtener del primario una ubicación del WAL adecuada después de que se confirme la transacción correspondiente y, luego, esperar a que esa ubicación se reproduzca en el standby.
Espera en standby
PostgreSQL 19 incorpora WAIT FOR LSN, que permite a una aplicación esperar hasta que se haya alcanzado una posición especificada del registro de escritura anticipada. La espera también puede añadir latencia. El comando admite la gestión de tiempos de espera (timeouts), pero un tiempo de espera omitido o igual a cero puede provocar una espera indefinida.
Luego lee
Solo una reproducción correcta establece que los cambios confirmados correspondientes están disponibles para las lecturas posteriores en ese standby. Las aplicaciones deben gestionar adecuadamente los tiempos de espera agotados, la promoción del standby y las interrupciones de la recuperación.
La espera también puede añadir latencia. El comando admite la gestión de tiempos de espera (timeouts), pero un tiempo de espera omitido o igual a cero puede provocar una espera indefinida. Las aplicaciones deben gestionar adecuadamente los tiempos de espera agotados, la promoción del standby y las interrupciones de la recuperación. Es un mecanismo de consistencia útil, no un sustituto de la supervisión de la replicación ni de la gestión de fallos en la propia aplicación.
Fuente: PostgreSQL 19, WAIT documentation.
4. Mejoras de mantenimiento y rendimiento
PostgreSQL 19 también mejora la forma en que las bases de datos realizan el trabajo en segundo plano. Los cambios incluyen una priorización más flexible de autovacuum y el mantenimiento paralelo de índices, junto con mejoras en la planificación, la ejecución y la E/S.
Estas mejoras pueden beneficiar a determinadas cargas de trabajo, pero sus efectos dependen del tamaño de las tablas, el número de índices, la configuración y los recursos disponibles. El vacuum paralelo, por ejemplo, afecta principalmente a las fases de vacuum de índices y de limpieza de índices. No hace que todas las operaciones de vacuum sean paralelas ni garantiza que terminen más rápido.
Del mismo modo, una priorización más sofisticada de autovacuum no elimina la necesidad de supervisar el crecimiento de las tablas y el progreso del mantenimiento. Los equipos deberían medir la duración del mantenimiento, el uso de E/S, la latencia de las consultas y la contención de recursos antes y después de la actualización. Las notas de la versión describen las capacidades, pero el rendimiento en producción debe demostrarse con cargas de trabajo representativas.
Fuente: PostgreSQL 19, Routine Vacuuming.
5. Los cambios de compatibilidad merecen especial atención
Varios cambios de PostgreSQL 19 pueden afectar a las aplicaciones y a las herramientas operativas existentes.
| Cambio | Posible consecuencia |
|---|---|
| Compilación JIT (just-in-time, justo a tiempo) desactivada de forma predeterminada | Algunas cargas de trabajo analíticas pueden requerir una configuración explícita de JIT |
| Autenticación RADIUS eliminada | Las instalaciones que usan RADIUS deben migrar a otro método de autenticación compatible |
standard_conforming_strings activado de forma obligatoria | Los scripts SQL o los volcados de bases de datos antiguos que dependan del comportamiento anterior pueden necesitar cambios |
Cambio de las clases de operadores de índice predeterminadas para inet y cidr | pg_upgrade rechaza los clústeres que tienen índices btree_gist sobre estos tipos, por lo que primero necesitan trabajo correctivo |
| Cambios en las interfaces del sistema y en la configuración | Las herramientas de supervisión, las extensiones o la automatización pueden necesitar actualizaciones de compatibilidad |
Un problema especialmente importante afecta a los volcados de bases de datos. PostgreSQL advierte que los volcados creados con versiones antiguas de pg_dump o pg_dumpall con standard_conforming_strings desactivado pueden no cargarse correctamente en PostgreSQL 19. Los equipos deberían usar un proceso de volcado admitido y verificar la restauración en lugar de suponer que una copia de seguridad antigua es compatible.
Las notas de la versión también señalan casos en los que pg_upgrade se negará a actualizar clústeres que contengan determinados índices o nombres de objetos incompatibles. Una actualización de versión mayor requiere una estrategia de migración adecuada, como pg_upgrade, volcado y restauración, o un enfoque adecuado basado en replicación lógica. Actualizar los paquetes como si se tratara de una versión menor no es suficiente.
Fuente: PostgreSQL 19, Migration and Compatibility Notes.
¿Qué deberían probar ahora los equipos de bases de datos?
Una evaluación útil de la versión candidata puede mantenerse acotada.
Compatibilidad de las aplicaciones: Ejecuta pruebas representativas de aplicación e integración con PostgreSQL 19 RC1. Incluye el comportamiento de SQL, la autenticación, las extensiones y los controladores (drivers) de bases de datos.
Consultas críticas: Compara los planes de ejecución y el rendimiento real de las consultas que afectan a las operaciones del negocio.
Comportamiento del mantenimiento: Prueba REPACK y las mejoras de vacuum con datos representativos. Incluye el uso de disco, los bloqueos, el comportamiento con instantáneas antiguas y las condiciones de fallo.
Replicación: Valida la sincronización de secuencias, el comportamiento de WAIT en el standby, la latencia y la gestión de errores cuando esas funciones sean relevantes.
Migración y recuperación: Ensaya el método de actualización admitido, confirma que las copias de seguridad se pueden restaurar y documenta la ruta de recuperación si la migración falla.
Compatibilidad de apps
Ejecuta pruebas representativas de aplicación e integración con PostgreSQL 19 RC1. Incluye el comportamiento de SQL, la autenticación, las extensiones y los controladores (drivers) de bases de datos.
Consultas clave
Compara los planes de ejecución y el rendimiento real de las consultas que afectan a las operaciones del negocio.
Mantenimiento
Prueba REPACK y las mejoras de vacuum con datos representativos. Incluye el uso de disco, los bloqueos, el comportamiento con instantáneas antiguas y las condiciones de fallo.
Replicación
Valida la sincronización de secuencias, el comportamiento de WAIT en el standby, la latencia y la gestión de errores cuando esas funciones sean relevantes.
Migrar y recuperar
Ensaya el método de actualización admitido, confirma que las copias de seguridad se pueden restaurar y documenta la ruta de recuperación si la migración falla.
No en producción
Estas pruebas deberían hacerse fuera de producción. El anuncio de RC1 indica que todavía pueden aplicarse más correcciones antes de la disponibilidad general, así que una versión candidata no es una base para cargas de trabajo de producción.
Estas pruebas deberían hacerse fuera de producción. El anuncio de RC1 indica que todavía pueden aplicarse más correcciones antes de la disponibilidad general, así que una versión candidata no es una base para cargas de trabajo de producción.
¿Y las instalaciones existentes de PostgreSQL?
No todas las organizaciones necesitan PostgreSQL 19 de inmediato. Los equipos que ya usan versiones de PostgreSQL con soporte deberían mantener al día las actualizaciones de seguridad mientras evalúan si la actualización mayor aporta un valor operativo significativo.
PostgreSQL 14 requiere una atención más inmediata. El proyecto PostgreSQL ha programado el fin del soporte de la comunidad para la versión 14 el 12 de noviembre de 2026.
Las organizaciones que todavía usan PostgreSQL 14 deberían dar prioridad a pasar a una versión con soporte. Eso no significa necesariamente esperar a PostgreSQL 19 ni adoptarlo el mismo día de su lanzamiento.
Fuente: PostgreSQL versioning policy.
La importancia práctica de PostgreSQL 19
PostgreSQL 19 ofrece mejoras útiles en el mantenimiento de bases de datos, el control de la planificación de consultas y la replicación. También introduce cambios de comportamiento que exigen pruebas deliberadas. El reempaquetado nativo puede recuperar espacio, pero la operación concurrente tiene restricciones importantes de visibilidad de las transacciones y de recursos. Las indicaciones para el planificador pueden resolver consultas difíciles, pero pueden volverse perjudiciales cuando cambian las cargas de trabajo. Las mejoras de replicación ofrecen más control, pero siguen exigiendo una gestión cuidadosa de la consistencia y de los fallos.
Los equipos de bases de datos deberían aprovechar el periodo de versión candidata para verificar qué mejoras benefician a sus cargas de trabajo y qué cambios requieren preparación antes de una actualización en producción.
Referencias y lecturas adicionales
- PostgreSQL Global Development Group, PostgreSQL 19 RC1 Released. 15 de octubre de 2026.
- PostgreSQL 19 Release Notes. Detalles preliminares sobre funciones y compatibilidad.
- PostgreSQL 19 REPACK Documentation. Requisitos operativos y advertencia sobre MVCC.
- PostgreSQL 19 pg_plan_advice Documentation. Comportamiento y limitaciones del planificador.
- PostgreSQL 19 WAIT Documentation. Consistencia en el standby y comportamiento de los tiempos de espera.
- PostgreSQL 19 Routine Vacuuming. Comportamiento de vacuum y del mantenimiento paralelo.
- PostgreSQL Versioning Policy. Versiones con soporte y fechas de fin del soporte.
Verificación de fuentes: 6 de noviembre de 2026. PostgreSQL 19 sigue siendo una versión candidata, y las páginas de documentación de PostgreSQL 19 citadas aquí son versiones preliminares. Las fechas del 12 de noviembre para RC2 y del 19 de noviembre para la disponibilidad general están previstas, no son lanzamientos confirmados. Las funciones y los detalles de compatibilidad deberían volver a comprobarse con la documentación de la versión final antes de su publicación.