PostgreSQL 19 Beta 1: grafos, autovacuum y JIT off

El 4 de junio de 2026 el PostgreSQL Global Development Group publicó la Beta 1 de PostgreSQL 19, la primera versión de prueba de la próxima major. No es un parche de mantenimiento: trae consultas de grafos dentro del propio motor (SQL/PGQ), un autovacuum que por fin corre en paralelo, un comando nuevo para reorganizar tablas sin downtime y un cambio silencioso que te puede mover los tiempos de tus queries: el JIT viene apagado por defecto. Si tenés Postgres corriendo en tu Cloud Server, esto es lo que cambia y lo que conviene probar antes de la GA, prevista para fines de 2026.

PostgreSQL 19 es la próxima versión mayor del sistema de base de datos relacional open source PostgreSQL. Su Beta 1 salió el 4 de junio de 2026 e incorpora consultas de grafos de propiedades (SQL/PGQ), autovacuum con workers en paralelo, el comando REPACK para reorganizar tablas online, checksums que se activan o desactivan sin reiniciar el cluster y JIT deshabilitado por defecto. La versión estable (GA) se espera para septiembre u octubre de 2026.

¿Conviene instalar una beta de PostgreSQL en producción?

PostgreSQL 19 Beta 1: grafos SQL/PGQ, autovacuum paralelo y JIT off

No. Una beta sirve para probar y reportar bugs, no para sostener datos reales. El formato del catálogo de sistema puede cambiar entre la beta y la versión final, así que un cluster que armes hoy con la Beta 1 podría requerir un pg_dump + restore (o un pg_upgrade) cuando salga la GA. La forma correcta de aprovechar este período es levantar una instancia descartable en tu Cloud Server, cargar un dump representativo de tu base y medir cómo se comportan tus consultas con los cambios de esta versión, en especial el JIT y el autovacuum. Los desarrolladores del proyecto piden justamente eso: testear cargas reales antes de la GA para que los problemas aparezcan ahora y no en octubre.

¿Qué son las consultas de grafos SQL/PGQ en PostgreSQL 19?

SQL/PGQ (Property Graph Queries) es la parte del estándar SQL que permite hacer consultas de grafos sobre tablas relacionales que ya tenés, sin migrar a una base de datos de grafos aparte ni instalar una extensión externa. Definís un "grafo de propiedades" que mapea tablas a nodos (vertices) y a relaciones (edges), y después lo consultás con patrones de grafo. La definición se ve así (ejemplo del deep dive de Snowflake):

CREATE PROPERTY GRAPH store_graph
VERTEX TABLES (
    customers LABEL customer,
    orders LABEL "order"
)
EDGE TABLES (
    customer_orders
        SOURCE customers
        DESTINATION orders
        LABEL placed_order
);

La idea de fondo: si tu modelo de "amigos de amigos", recomendaciones, dependencias o detección de fraude vive en tablas con joins recursivos cada vez más enredados, ahora podés expresar esos recorridos con sintaxis de grafo nativa, sin sumar otra pieza de infraestructura. InfoQ lo resume como correr "graph queries sobre tablas relacionales existentes sin requerir una base de grafos separada ni migración de datos". Es la feature más vistosa del release, aunque —ojo— buena parte de la comunidad de operadores está más entusiasmada con las mejoras de mantenimiento que con los grafos.

¿Cómo funciona el autovacuum en paralelo y qué hay que vigilar?

Hasta PostgreSQL 18, cada worker de autovacuum procesaba una tabla de forma secuencial, índice por índice. En PostgreSQL 19, el autovacuum puede repartir la limpieza de índices entre varios workers en paralelo, controlado por el nuevo parámetro autovacuum_max_parallel_workers, y suma un sistema de scoring que prioriza las tablas más castigadas en vez de barrer a ciegas. Para una tabla con muchos índices y mucho movimiento (el clásico cuello de botella de una base OLTP grande), esto recorta el tiempo de cada pasada.

El detalle fino —y la trampa— es la memoria. El consumo se multiplica entre los workers, así que antes de subir el valor conviene rehacer la cuenta:

Recalculá tu techo de RAM. El consumo potencial es autovacuum_max_workers × autovacuum_max_parallel_workers × maintenance_work_mem. Si ya tenías maintenance_work_mem alto y muchos workers, el paralelismo puede disparar el uso de memoria del servidor.
Empezá conservador. En un Cloud Server con RAM acotada, un valor moderado de autovacuum_max_parallel_workers (por ejemplo, 2) y medir antes de escalar es más seguro que copiar configuraciones de servidores enormes.
Configurable por tabla. El paralelismo se puede ajustar globalmente y también por tabla, así que podés reservarlo para las pocas tablas grandes que realmente lo necesitan.

¿Por qué PostgreSQL 19 desactiva el JIT por defecto?

El cambio que más callado pasa y más te puede afectar: la compilación just-in-time (JIT) ahora viene en off por defecto, cuando en versiones anteriores estaba activa. El JIT compila partes de la query en tiempo de ejecución; en consultas analíticas largas a veces ayuda, pero en cargas OLTP (muchas consultas cortas) muchas veces pagabas el costo de compilar sin obtener beneficio. Por eso el proyecto decidió apagarlo de fábrica.

Qué implica para vos según tu carga:

Si tu base es OLTP (web, APIs, transacciones cortas): probablemente vas a ganar previsibilidad. Eran justamente estas cargas las que pagaban el peaje del JIT sin verlo reflejado en velocidad.
Si corrés analítica o reportería pesada (OLAP): medí. Hay queries largas que se beneficiaban del JIT en silencio. Si las tuyas son de esas, vas a tener que poner jit = on explícitamente y comparar tiempos durante la prueba de upgrade, porque si no lo hacés podés llevarte una sorpresa de performance.

La recomendación práctica es clara: no asumas nada, benchmarká tus consultas reales con y sin JIT antes de migrar.

¿Qué es el comando REPACK y en qué se diferencia de VACUUM FULL?

PostgreSQL 19 incorpora al core un comando nuevo, REPACK, que reorganiza una tabla para recuperar espacio en disco y, con la opción CONCURRENTLY, lo hace sin bloquear la tabla. La diferencia con VACUUM FULL es justamente esa: VACUUM FULL toma un lock exclusivo y deja la tabla inutilizable mientras corre, algo impensable en producción durante horario activo. REPACK ... CONCURRENTLY apunta a hacer ese trabajo de recompactar tablas infladas (bloat) online, sin downtime.

Si hasta ahora resolvías el bloat con la extensión pg_repack instalada por afuera, esta funcionalidad pasa a estar en el motor. Para un Cloud Server donde no podés darte el lujo de cortar el servicio para mantenimiento, es probablemente la mejora operativa más valiosa del release.

¿Qué otros cambios trae PostgreSQL 19 para tu servidor?

Más allá de los titulares, hay un puñado de cambios que vas a sentir en el día a día de administrar la base:

Checksums de datos online. Ahora podés activar o desactivar los data checksums sin reiniciar ni reinicializar el cluster, algo que antes obligaba a una recreación dolorosa.
I/O asíncrono que se autoajusta. Siguiendo lo que arrancó PostgreSQL 18, con io_method=worker la cantidad de workers de I/O escala sola entre los nuevos io_min_workers y io_max_workers.
Compresión TOAST con lz4 por defecto. default_toast_compression pasa de pglz a lz4, con mejor velocidad de compresión y descompresión para los valores grandes.
INSERT ... ON CONFLICT DO SELECT. El upsert ahora puede devolver las filas en conflicto con RETURNING, cubriendo un caso que antes había que resolver con vueltas de más.
Members de MultiXact de 64 bits. Elimina el modo de falla por agotamiento del contador de 32 bits que, en cargas de alta concurrencia con muchos locks compartidos de fila, podía forzar vacuums offline de emergencia. Si alguna vez te despertó a las 3 AM un "multixact member exhaustion", este cambio es para vos.
pg_plan_advice. Una extensión nueva para estabilizar y controlar las decisiones del planner, útil cuando un plan "se da vuelta" y degrada una query crítica.
RADIUS afuera. Se removió el soporte de autenticación RADIUS, así que si lo usabas, planificá la alternativa antes de actualizar.

¿Qué podés hacer hoy con PostgreSQL 19 Beta 1?

Lo más productivo en estos meses, mientras falta para la GA, es prepararte sin riesgo:

Levantá una instancia de prueba aislada en tu Cloud Server (un contenedor o una VM descartable), nunca sobre tus datos productivos.
Cargá un dump representativo y reproducí tus consultas más pesadas con y sin JIT para detectar regresiones antes de que sean un problema.
Revisá tu config de memoria de autovacuum con la fórmula de arriba antes de habilitar paralelismo.
Probá REPACK CONCURRENTLY contra una tabla inflada y medí cuánto espacio recuperás sin bloquear.

Si todavía estás en versiones anteriores, esta beta es la señal para planificar el camino de actualización. Como lectura complementaria sobre la base de la que parte este release, en el blog ya cubrimos «PostgreSQL 18: I/O asíncrono y skip scan aceleran tu Cloud Server», y para la parte de respaldos —imprescindible antes de cualquier upgrade— tenés «Backups de PostgreSQL con pgBackRest en Ubuntu» y «Backups con Restic en Ubuntu».

Preguntas frecuentes

¿Cuándo salió PostgreSQL 19 Beta 1?

El 4 de junio de 2026. Es la primera versión de prueba del ciclo de PostgreSQL 19 y arranca el período de beta, durante el cual habrá más betas y release candidates.

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

La GA está prevista para septiembre u octubre de 2026, según el anuncio oficial. La fecha exacta depende de cómo evolucione el testeo durante la beta.

¿Puedo usar PostgreSQL 19 Beta 1 en producción?

No conviene. Es software de prueba pensado para detectar bugs; el formato interno puede cambiar antes de la GA y no hay garantía de compatibilidad de datos. Usala solo en entornos descartables.

¿Por qué el JIT ahora viene apagado por defecto?

Porque muchas cargas OLTP pagaban el costo de compilar sin obtener mejora de velocidad. Si tu trabajo es analítico y dependías del JIT, podés volver a activarlo con jit = on y benchmarkear.

¿Qué ventaja tiene REPACK sobre VACUUM FULL?

Con la opción CONCURRENTLY, REPACK recompacta una tabla y recupera espacio sin tomar un lock exclusivo, es decir, sin downtime. VACUUM FULL bloquea la tabla por completo mientras corre.

¿El autovacuum paralelo puede agotar la memoria de mi servidor?

Sí, si no ajustás la configuración. El consumo potencial es autovacuum_max_workers × autovacuum_max_parallel_workers × maintenance_work_mem; recalculá ese techo antes de subir el paralelismo en un servidor con RAM limitada.

¿Necesito una base de datos de grafos aparte para usar SQL/PGQ?

No. SQL/PGQ corre consultas de grafo sobre tus tablas relacionales existentes dentro del propio PostgreSQL, sin migrar datos ni instalar un motor de grafos separado.