Una beta con dos caras

PostgreSQL 19 Beta 3 llegó el 13 de agosto de 2026 junto a la tanda habitual de parches menores de las ramas estables (18.6, 17.11, 16.15, 15.19, 14.24). Es una de las últimas betas antes de la disponibilidad general prevista para septiembre -- sin fecha exacta todavía confirmada por el proyecto -- y trae dos frentes de mejora que sí importan para cualquiera que gestione una base de datos Postgres con tráfico real: reorganización de tablas sin bloqueos, y replicación lógica más flexible.

REPACK: la extensión de terceros que deja de hacer falta

El nuevo comando REPACK combina lo que hasta ahora exigía VACUUM FULL (que bloquea la tabla entera) o CLUSTER, con una opción CONCURRENTLY que permite reorganizar el contenido de una tabla sin bloquear lecturas ni escrituras.

Quien ya gestiona Postgres en producción sabe que este problema -- una tabla hinchada que necesita reorganizarse sin parar el servicio -- históricamente se resolvía con pg_repack, una extensión de terceros que había que instalar y mantener aparte. Que esto llegue como comando nativo del núcleo no es solo comodidad: es una pieza menos de infraestructura externa de la que depender, y una capacidad que antes exigía instalar algo adicional pasa a estar disponible de fábrica.

Replicación lógica: menos ventanas de mantenimiento

La replicación lógica ahora puede activarse sin reiniciar el servidor cuando wal_level ya está configurado en replica -- elimina una ventana de mantenimiento que antes era obligatoria solo para dar ese paso. A eso se suma CREATE PUBLICATION ... EXCEPT, que simplifica el caso habitual de "replicar todo menos estas tablas concretas" sin tener que enumerar manualmente el resto.

El particionado, con una marcha atrás pública

El otro gran frente de la 19 es el particionado: ALTER TABLE ... MERGE/SPLIT PARTITIONS prometía fusionar o dividir particiones sin el baile manual de crear tablas nuevas y mover datos. Pero el 27 de agosto de 2026 -- ya avanzada esta beta -- el equipo revirtió específicamente el sub-comando MERGE PARTITIONS de la versión 19. No hay nada malo en esto en sí mismo: es exactamente el tipo de decisión que separa un proyecto que cuida su calidad de uno que lanza por calendario. Pero para quien estuviera planificando una migración de particionado alrededor de ambos comandos, es una pieza menos con la que contar hasta que reaparezca en una versión futura.

¿Vale la pena probarla ya?

Si gestionas una instancia de Postgres que ya sufre el problema de reorganizar tablas grandes sin downtime, vale la pena seguir de cerca esta beta y probarla en un entorno de pruebas -- REPACK CONCURRENTLY por sí solo puede simplificar bastante la operación diaria. Para producción, como con cualquier major version, el ciclo habitual de compatibilidad con extensiones (PostGIS, pgvector, TimescaleDB si las usas) sigue siendo obligatorio antes de tocar nada real, y más aún estando todavía en fase beta.

¿Para quién es esto?

Para quien administra Postgres en un homelab o en producción y ya ha peleado con pg_repack o con ventanas de mantenimiento para activar replicación lógica, esta beta merece una prueba temprana. Para quien planificaba construir sobre MERGE PARTITIONS concretamente, toca esperar a que reaparezca en una versión posterior antes de comprometer nada.