PostgreSQL 19 antes del RC1: REPACK, JIT apagado y lo que se cayó

PostgreSQL 19 entra en la recta final con tres cambios que le van a tocar a cualquiera que lo corra en producción: un comando REPACK nativo, jit apagado por defecto y compresión TOAST con lz4. También con una lista de funciones que se retiraron en la Beta 4. Una aclaración sobre el título: al 13 de octubre de 2026 el RC1 todavía no salió. Está agendado para el jueves 15, así que esta nota es un mapa de lo que ya se sabe desde las betas y de lo que conviene probar antes de que llegue.

PostgreSQL 19 es la próxima versión mayor del motor de base de datos open source PostgreSQL. Su release candidate 1 (RC1) está previsto para el 15 de octubre de 2026 y el GA se movió al 19 de noviembre. Incorpora REPACK (con CONCURRENTLY) para reconstruir tablas con bloat, desactiva JIT por defecto y usa lz4 como compresión TOAST por defecto. Además, retiró varias funciones respecto de las betas.

¿Cuándo sale PostgreSQL 19 y en qué estado está el RC1?

El RC1 sigue agendado para el 15 de octubre de 2026, y el GA pasó al 19 de noviembre, con un RC2 el 12 de noviembre. Lo anunció Jonathan S. Katz, del release team, el 10 de octubre en la lista pgsql-hackers (mensaje con las fechas actualizadas).

• Motivo del corrimiento: según el mismo mensaje, "the volume of fixes that have been added to the back branches" justificó sumar un segundo release candidate y alinear el GA con una release de actualización programada.
• Beta 4 el 24 de septiembre: según el anuncio oficial, incluyó fixes para el nuevo REPACK (crashes, índices inválidos y vistas materializadas, permisos y reporte de errores) y las reversiones que se detallan más abajo.
• Lectura práctica: un RC que se agrega para absorber fixes es una señal de prudencia, no de problema. Igual, sigue valiendo esperar a las primeras minor releases (19.1 en adelante) antes de migrar producción crítica.

¿Qué hace el comando REPACK en PostgreSQL 19?

REPACK reconstruye una tabla para recuperar el espacio que dejó el bloat, y unifica bajo un solo nombre lo que hacían VACUUM FULL y CLUSTER. Con la opción CONCURRENTLY lo hace sin bloquear lecturas ni escrituras durante casi toda la operación. El anuncio de la Beta 1 lo describe como un comando "and its nonblocking CONCURRENTLY option".

La sintaxis que documentan los análisis de la beta es esta (verificala contra la documentación oficial de REPACK):

REPACK t;                       -- reescribe sin ordenar
REPACK t USING INDEX t_pkey;    -- reescribe ordenando por índice
REPACK (CONCURRENTLY) t;        -- online, lock exclusivo solo al final

¿Qué limitaciones tiene REPACK CONCURRENTLY?

No es un reemplazo mágico de VACUUM. Según la documentación oficial, CONCURRENTLY exige una tabla con clave primaria o índice de identidad de réplica. No sirve para tablas unlogged ni dentro de una transacción. La documentación también aclara que sigue haciendo falta un lock exclusivo breve al final.

• El lock fuerte llega al final: la mayor parte del trabajo corre con un lock liviano. El ACCESS EXCLUSIVE se toma para el intercambio final de archivos, y su duración depende del tráfico de escritura que haya que reproducir, no del tamaño de la tabla.
• No es seguro para MVCC: la documentación oficial advierte que REPACK con CONCURRENTLY no es MVCC-safe. Cuidado con reportes largos o sesiones idle in transaction mientras corrés REPACK.
• Necesita espacio libre: como toda reescritura, hace falta disco para la copia nueva. Esto lo deduzco del funcionamiento del comando, no de una cifra de las fuentes: medilo en tu entorno.

¿REPACK reemplaza a pg_repack y pg_squeeze?

En la mayoría de los casos de compactación online, ese es el objetivo: traer a core lo que hoy resuelven pg_repack y pg_squeeze. Pero la beta es reciente y las restricciones de arriba son reales, así que mi postura es no desinstalar nada hasta probar REPACK con tus tablas, tu tráfico y tu réplica. Si el bloat te preocupa de fondo, la primera línea sigue siendo ajustar autovacuum.

¿Por qué PostgreSQL 19 apaga JIT por defecto?

Porque el costo de compilar con LLVM terminaba superando el tiempo de ejecución en muchas consultas chicas. JIT estaba activo por defecto desde PostgreSQL 12, y en la 19 el parámetro jit pasa a off. El anuncio de la Beta 1 lo lista entre los cambios a tener en cuenta: "Just-in-time compilation (JIT) is now disabled by default".

• El problema era el modelo de costos: según Dimitri Fontaine en su guía para prepararse para PostgreSQL 19, el modelo de costos de JIT del optimizador no era confiable, y consultas analíticas o scans paralelos grandes que antes compilaban ya no lo van a hacer si no volvés a activar jit.
• OLTP gana previsibilidad: las consultas cortas cuyo costo estimado cruzaba jit_above_cost pagaban compilación sin necesitarla.
• OLAP requiere decidir: si tus consultas analíticas grandes dependían de que JIT se activara solo, ahora hay que activarlo a mano con jit = on. No hay una cifra general: depende de tu carga.

Para decidir con datos, compará el mismo plan en ambos modos y activalo solo donde rinda:

SHOW jit;

-- comparar una consulta analítica real
SET jit = off;
EXPLAIN (ANALYZE, BUFFERS) SELECT ... ;
SET jit = on;
EXPLAIN (ANALYZE, BUFFERS) SELECT ... ;

-- si rinde, activarlo solo en la base o rol analítico
ALTER DATABASE analytics SET jit = on;

¿Qué cambia con lz4 como compresión TOAST por defecto?

El parámetro default_toast_compression pasa de pglz a lz4, que comprime y descomprime más rápido a costa de un poco más de espacio. Los datos ya almacenados no se tocan: solo los valores nuevos o actualizados usan el default nuevo. El anuncio oficial lo presenta como "better default compression and decompression performance".

• Sin reescritura al actualizar: tras el upgrade vas a tener valores en pglz y valores en lz4 conviviendo en la misma columna.
• Cambio silencioso: Fontaine lo describe como un cambio de comportamiento de almacenamiento y CPU a nivel de todo el cluster sin acción del usuario. Conviene medir tamaño de tablas y CPU antes y después en staging.
• Verificá el estado en tu build: el anuncio de la Beta 4 no lista la reversión del default de lz4. Confirmalo en las release notes del RC1 y, en tu servidor, con SHOW default_toast_compression;.

Si necesitás controlar columnas puntuales o ver qué método usa cada valor:

SHOW default_toast_compression;

ALTER TABLE documentos ALTER COLUMN cuerpo SET COMPRESSION lz4;

SELECT pg_column_compression(cuerpo) FROM documentos LIMIT 10;

¿Qué funciones se cayeron de PostgreSQL 19?

En la Beta 4 (24 de septiembre de 2026) se revirtieron seis cambios: SQL/PGQ, la activación y desactivación online de checksums, FOR PORTION OF, MERGE/SPLIT PARTITIONS, las funciones pg_get_role_ddl(), pg_get_tablespace_ddl() y pg_get_database_ddl(), y el cambio que forzaba LC_COLLATE a C en el postmaster. Así figura en el anuncio oficial de la Beta 4.

El proyecto lo justificó así: "The PostgreSQL community strongly believes that, first and foremost, PostgreSQL must be reliable" (anuncio de la Beta 4; la traducción es mía). Según Fontaine, uno de los motivos puntuales fue un problema de concurrencia de FOR PORTION OF en READ COMMITTED.

Mi lectura: no hay que ver esto como un fracaso. Es el proceso funcionando, y el anuncio aclara que podrían volver en una versión mayor posterior. Para vos, la consecuencia práctica es no diseñar nada que dependa de estas funciones en 19. Si tu plan de partitioning o de auditoría las asumía, seguís con las herramientas actuales.

¿Qué otros cambios pueden romper una actualización a PostgreSQL 19?

El más seguro de confirmar es la eliminación de la autenticación radius en pg_hba.conf, que el anuncio de la Beta 1 lista entre los cambios notables. La guía de Fontaine suma otros que conviene verificar en las release notes oficiales antes de actuar, porque los vi en una sola fuente.

• RADIUS eliminado: según esa guía, solo soportaba RADIUS sobre UDP, que el proyecto considera inseguro, así que si autenticás por RADIUS necesitás otro método antes de actualizar. Migrá a SCRAM-SHA-256, LDAP, GSSAPI o certificados.
• MD5 con advertencias: la misma guía indica que autenticarse con hashes MD5 genera warnings. Es buen momento para pasar a SCRAM.
• Strings estándar: según la misma guía, standard_conforming_strings queda forzado en on. Código viejo con backslash en strings normales puede cambiar de comportamiento.
• Defaults de locks: la guía menciona max_locks_per_transaction de 64 a 128.

¿Qué podés probar hoy antes del GA?

Levantá un cluster de prueba con la Beta 4 (o el RC1 cuando salga) y corré tus propios workloads, como pide el proyecto. No lo hagas en producción. Un VPS o una instancia cloud descartable alcanza, por ejemplo en Donweb Cloud o donde ya tengas laboratorio. Además de los Open Items del wiki, esta lista corta cubre lo que cambia en 19:

1. Revisá los defaults: corré SHOW jit; y SHOW default_toast_compression; y anotá qué ves en tu build.
2. Medí tus consultas pesadas con JIT on y off: sobre una copia de datos reales, usando EXPLAIN (ANALYZE, BUFFERS).
3. Probá REPACK en una tabla con bloat: verificá antes la clave primaria y que no haya transacciones largas abiertas. Medí cuánto dura el lock final bajo carga de escritura.
4. Buscá lo que se retira: grepeá pg_hba.conf por radius y revisá qué roles aún usan MD5.
5. Descartá dependencias de lo revertido: buscá en scripts y migraciones el uso de pg_get_role_ddl, FOR PORTION OF o MERGE PARTITIONS.

Como lectura complementaria, tenemos la nota sobre PostgreSQL 18 (skip scan, uuidv7 y stats que sobreviven al upgrade) y la guía de autovacuum, que explican de dónde viene gran parte del bloat que REPACK intenta resolver.

Preguntas frecuentes

¿Cuándo sale la versión final de PostgreSQL 19?

El GA está previsto para el 19 de noviembre de 2026. El release team lo movió una semana más allá del RC2 del 12 de noviembre para incorporar un lote de fixes.

¿Ya salió el RC1 de PostgreSQL 19?

No, al 13 de octubre de 2026 el RC1 todavía no salió: está agendado para el 15 de octubre. Fue la fecha que el release team ratificó el 10 de octubre, así que verificá postgresql.org/about/news para confirmar la publicación.

¿Puedo usar REPACK CONCURRENTLY en producción?

Todavía no conviene hacerlo sin pruebas propias, porque la beta recibió fixes recientes y el comando tiene restricciones. Probalo en staging con tablas que tengan clave primaria y carga de escritura similar a la real.

¿Actualizar a PostgreSQL 19 recomprime mis datos TOAST con lz4?

No: los valores ya almacenados mantienen su método de compresión original. Solo los valores nuevos o actualizados usan el default nuevo, así que vas a tener pglz y lz4 conviviendo.

¿Tengo que volver a activar JIT después de actualizar?

Solo si tu carga analítica se beneficiaba de él. Comparalo con EXPLAIN (ANALYZE) en ambos modos y activalo con ALTER DATABASE o ALTER ROLE únicamente donde rinda.

¿Volverán SQL/PGQ y las demás funciones revertidas?

El proyecto dijo que podrían incluirse en una versión mayor posterior, tras más tiempo de desarrollo y revisión. No hay una fecha confirmada en las fuentes que revisé.

Los datos de esta nota provienen de los anuncios oficiales de las betas, de la lista pgsql-hackers y de análisis de terceros al 13 de octubre de 2026. Las release notes finales del RC1 y del GA pueden diferir: verificalas en postgresql.org antes de planificar una migración.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting