PostgreSQL 19 RC1: checklist de staging antes de migrar

PostgreSQL 19 RC1 se publicó el 15 de octubre de 2026. Una release candidate debería parecerse mucho a la versión inicial, pero todavía puede recibir correcciones; por eso RC1 no es GA ni una recomendación para actualizar producción. El anuncio del proyecto prevé un RC2 el 12 de noviembre y disponibilidad general el 19 de noviembre, siempre que no aparezca un problema que obligue a cambiar el calendario.

La decisión útil ahora es más pequeña: ¿puede la aplicación atravesar una migración mayor en un staging que se pueda desechar y reconstruir? El siguiente checklist ordena esa respuesta sin presentar una ejecución, un tiempo de migración o un benchmark como evidencia.

Aísla el experimento

Usa un clúster de staging separado, con datos sanitizados, secretos propios y una red que no pueda recibir tráfico productivo por accidente. Copia la configuración necesaria, pero no las credenciales ni los dumps con datos personales. Mantén una ruta clara para devolver el tráfico al clúster anterior si el resultado no es aceptable.

La documentación 19 consultada todavía identifica esa versión como no soportada y conserva una fecha de documentación provisional. Trátala como referencia de la candidata, no como contrato definitivo de GA. Antes de planificar una migración o cambiar el clúster, vuelve a comprobar el anuncio, el calendario y las notas de la versión.

Inventario de solo lectura

Antes de migrar, captura el estado del origen y del staging sin modificar la base. En psql, estas consultas son ejemplos de inventario; no se ejecutaron como parte de este artículo:

SHOW server_version;
SHOW server_encoding;

SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

SELECT datname, datcollate, datctype
FROM pg_database
WHERE datallowconn
ORDER BY datname;

Para revisar identidades y permisos sin cambiarlos, usa comandos de inspección como \du y \dn+, además de las vistas de information_schema que correspondan al rol de auditoría. Registra roles, propietarios, grants, search_path, jobs, foreign data wrappers, publicaciones, suscripciones y extensiones instaladas. Una consulta de solo lectura no demuestra que el rol de la aplicación conserve el mismo resultado después de restaurar; esa equivalencia debe verificarse en el staging.

Para consultas críticas, guarda un plan con EXPLAIN sin ANALYZE y con los parámetros representativos que el equipo pueda compartir. Así se revisa la forma del plan sin ejecutar la sentencia; no es un benchmark ni sustituye una prueba funcional posterior.

Elige la ruta de migración mayor

El anuncio oficial indica que pasar desde una versión anterior requiere una estrategia de upgrade mayor, por ejemplo pg_upgrade o pg_dump/pg_restore. La elección depende de topología, tamaño, extensiones, ventana de mantenimiento, replicación y procedimiento de recuperación.

Ruta	Qué transforma	Qué debe comprobar staging
pg_upgrade	Convierte un clúster existente a la nueva versión con un procedimiento de migración mayor	Compatibilidad de binarios, extensiones, collations, nombres, roles, índices y validaciones que la herramienta pueda bloquear
Dump/restore lógico	Recrea objetos y datos mediante SQL y herramientas lógicas	Orden de restauración, propietarios, grants, secuencias, extensiones, encoding, errores de carga y jobs
Replicación lógica	Mantiene un destino lógico para una transición controlada	Cobertura de tablas, secuencias, DDL, lag, conflictos, slots y procedimiento de corte

pg_upgrade --check solo verifica la compatibilidad y no cambia los datos. En una ejecución real sobre un clon de staging, --copy es el modo predeterminado y copia los archivos; --clone usa clones del sistema de archivos cuando la plataforma los admite y deja el origen intacto, pero hay que verificar esa independencia. --link usa hard links: después de iniciar el clúster nuevo, ambos pueden compartir archivos ya escritos y no es seguro arrancar el viejo; el retorno requiere restaurar un backup. --swap puede modificar destructivamente el origen cuando empieza la transferencia. No uses --link ni --swap en un entorno donde el rollback dependa de arrancar el origen; cualquier comprobación debe hacerse sobre un clon de staging, nunca sobre la base productiva.

Un backup físico y un dump lógico no son intercambiables. El físico necesita un backup base consistente del clúster y de todos sus tablespaces; para PITR también necesita conservar la secuencia de WAL requerida desde el backup. La configuración externa —por ejemplo postgresql.conf, pg_hba.conf, pg_ident.conf y archivos incluidos fuera del directorio respaldado— requiere una copia independiente. El backup no incluye automáticamente todo lo que rodea al clúster ni convierte por sí solo una versión mayor a PostgreSQL 19. El lógico puede alimentar la migración mayor, pero exige validar roles, propietarios, extensiones, tipos y objetos que no viajen como filas.

Diseña la reversión antes de migrar

No llames rollback a borrar el clúster nuevo. Conserva el clúster anterior sin modificaciones hasta que el staging y el periodo de observación hayan pasado; documenta cómo se conmuta el tráfico, cómo se evita que se escriba simultáneamente en ambos lados y cómo se recuperan las escrituras posteriores al corte.

Si el plan usa backup físico, prueba una restauración en un destino aislado y comprueba que el resultado es utilizable por el servidor de la versión correspondiente. Si usa dump/restore o replicación lógica, conserva el origen y prueba también qué datos escritos después de la última sincronización requieren una reconciliación. El rollback real es un procedimiento de datos y tráfico, no solo cambiar una etiqueta de imagen.

Revisa los cambios que pueden romper compatibilidad

Las notas oficiales de PostgreSQL 19 son una lista de comprobación para staging, no una prueba de que tu instalación tenga cada caso:

Área	Revisión propuesta
Contraseñas MD5	Buscar autenticación MD5 y registrar la advertencia de deprecación; decidir una migración de autenticación compatible.
RADIUS	Confirmar si algún método depende de RADIUS: PostgreSQL 19 lo elimina y requiere otra estrategia.
Cadenas	Revisar dumps antiguos creados con standard_conforming_strings = off; en 19 el servidor fuerza ese ajuste a on.
Nombres	Detectar nombres de base, rol o tablespace con retornos de carro o saltos de línea, que la migración puede rechazar.
Índices	Inventariar índices btree_gist sobre inet/cidr; pg_upgrade puede impedir el paso y exige corregir el diseño.
JIT	Registrar si una carga analítica depende de JIT: en 19 queda desactivado por defecto. No asumir una mejora o una regresión sin medir la carga propia.
Extensiones y collations	Confirmar versión, proveedor de collation, biblioteca del sistema y soporte de cada extensión para PostgreSQL 19.

La página de desarrollo también describe novedades como REPACK, REPACK (CONCURRENTLY) y WAIT para consistencia read-your-writes en réplicas. Úsalas como temas de pruebas separadas, no como motivo para cambiar el plan de migración ni como promesa de rendimiento. Una prueba de REPACK debe respetar la ventana y la política de la aplicación; una prueba de WAIT debe especificar qué LSN, réplica y contrato de lectura se están evaluando.

Valida la aplicación y los permisos

Después de restaurar o actualizar el clon, ejecuta la suite autorizada de la aplicación y revisa, como mínimo:

• migraciones, lecturas, escrituras, transacciones y errores esperados;
• clientes y drivers en sus versiones soportadas;
• roles, propietarios, GRANT, search_path, funciones SECURITY DEFINER y conexiones de workers;
• colas, tareas programadas, foreign data wrappers, publicaciones y suscripciones;
• backups, restauración y observabilidad del nuevo proceso;
• consultas críticas con planes comparables, sin convertir la revisión en un benchmark inventado.

Si una consulta solo funciona con permisos de superusuario en staging, no la marques como compatible: reproduce el rol de la aplicación y registra el permiso mínimo que requiere. Del mismo modo, una extensión presente en el catálogo no demuestra que sus objetos, binarios y collations estén listos para la nueva versión.

Decide qué hacer con RC1

Continúa en staging si el upgrade elegido, los restores, las extensiones y los flujos críticos son reproducibles y el rollback está ensayado en un entorno aislado. Espera a RC2 si necesitas las correcciones previstas para el 12 de noviembre o si la documentación y las herramientas aún no cubren tu topología. Espera a GA para producción salvo que exista una razón excepcional, un proceso explícito de soporte pre-release y autorización del responsable de la plataforma.

El calendario de 12 y 19 de noviembre es una previsión del proyecto, no una garantía. Revisa el anuncio más reciente antes de planificar una migración o convertir este checklist en un cambio operativo.

Fuentes oficiales: PostgreSQL 19 RC1, notas de PostgreSQL 19, guía de actualización de clúster, documentación de pg_upgrade, backup continuo y WAL, cambios de migración de PostgreSQL 16 y calendario previo de releases.