PostgreSQL
Planificación de upgrades mayores y menores, compatibilidad de extensiones, drivers, SQL y aplicaciones, con pruebas, rollback y ventanas de mantenimiento.
Actualizar PostgreSQL no es cambiar un número de versión. Es migrar un sistema con datos, extensiones, collations, drivers, consultas, procedimientos operativos y una ventana real de rollback.
PostgreSQL publica major versions con nuevas capacidades y cambios internos, mientras que las minor versions corrigen errores y seguridad dentro de una misma major.
minor upgrade
18.3 → 18.4
→ mismo formato principal de datos
→ instalación de binarios/parches
→ reinicio o acción del proveedor
major upgrade
17 → 18
→ cambia el formato interno
→ exige migración mediante pg_upgrade, dump/restore, replicación lógica o servicio administradoNo planifiques con números memorizados. Antes de cada upgrade confirma la política oficial, releases soportadas, notas de versión y compatibilidad del proveedor.
Cada major recibe soporte durante un periodo limitado. Permanecer fuera de soporte implica:
El plan debe comenzar antes del fin de soporte, no durante la última semana.
Un minor upgrade suele conservar compatibilidad binaria dentro de la major, pero todavía requiere disciplina:
Un bug corregido puede cambiar un plan o resultado que accidentalmente dependía del comportamiento anterior.
Valida compatibilidad y migra rápidamente reutilizando o copiando archivos físicos.
Ventajas:
Costes:
--link.pg_dump / pg_dumpall
→ crear cluster limpio
→ restaurar schema y datos
→ reconstruir índices y statisticsVentajas:
Costes:
nuevo cluster
→ copiar schema
→ initial sync
→ replicar cambios
→ validar lag y datos
→ detener writes brevemente
→ sincronizar sequences
→ cutoverVentajas:
Costes:
El proveedor puede automatizar infraestructura, pero sigue siendo responsabilidad del equipo validar:
1. inventario del cluster
2. instalar versión y extensions destino
3. ejecutar checks
4. tomar backup y establecer freeze de cambios
5. detener origen de forma limpia
6. ejecutar pg_upgrade
7. iniciar destino
8. actualizar extensions
9. regenerar statistics
10. ejecutar smoke/integration tests
11. observar y liberar tráfico--link evita copiar los archivos y reduce espacio/tiempo, pero el cluster anterior comparte data files. Iniciar o modificar el antiguo después del upgrade puede destruir la posibilidad de rollback.
Debes registrar:
Sin inventario, el upgrade descubre dependencias durante el incidente.
Antes del upgrade:
SELECT extname, extversion
FROM pg_extension
ORDER BY extname;Confirma:
ALTER EXTENSION ... UPDATE.Una extensión instalada pero no actualizada puede dejar objetos con versión antigua.
Actualizar sistema operativo, glibc o ICU puede cambiar reglas de comparación.
Riesgos:
Después de detectar mismatch, sigue la guía de la versión: valida datos, reconstruye índices afectados y actualiza la versión registrada de la collation.
PostgreSQL mantiene gran compatibilidad, pero debes probar:
La base “arranca” antes de que el sistema esté validado.
Una major puede cambiar:
Una query puede mejorar o empeorar sin modificar SQL. Captura queries representativas y compara:
EXPLAIN (ANALYZE, BUFFERS, SETTINGS)No intentes conservar todos los planes antiguos. Identifica regresiones reales y corrige estadísticas, query o índices.
Revisa release notes por:
No construyas aplicaciones contra columnas internas de pg_catalog sin considerar evolución.
No copies postgresql.conf completo al nuevo cluster.
Proceso:
pg_settings.Un tuning antiguo puede ser contraproducente en hardware o versión nueva.
No basta comparar count(*) global.
Opciones:
La validación debe poder ejecutarse sin saturar producción.
Planifica una secuencia explícita:
anunciar ventana
→ detener jobs y writers
→ esperar/terminar transacciones controladamente
→ verificar lag cero
→ sincronizar sequences
→ cambiar endpoint
→ smoke tests
→ abrir tráfico progresivamente
→ observarDefine quién autoriza continuar o abortar.
Antes del corte, rollback puede ser reiniciar el origen.
Después de escrituras en destino, existen dos historias. Volver requiere:
Por eso debe definirse un point of no return.
Durante cutover pueden perderse conexiones después de commit. Requests reintentados pueden duplicar operaciones. Idempotency keys y reconciliación son parte del upgrade de producción, no solo del código cotidiano.
En replicación física, primary y standby deben seguir combinaciones compatibles. Estrategias:
No asumas que una replica de otra major puede seguir WAL físico ordinario.
Monitorea:
Define baseline antes del cambio.
--link reduce espacio, pero dificulta rollback. Logical migration requiere capacidad doble.
Puede bloquear toda la estrategia o exigir retirar/migrar datos.
Reindex puede durar más que el upgrade.
El nuevo primary comienza a producir IDs existentes.
Retiene WAL y llena disco durante migración.
Puede quedar olvidada y retener locks; resuélvela antes.
Updates/deletes pueden requerir replica identity y generar coste alto.
objetivo y versiones
responsables
prechecks
backups y restore verificado
comandos/acciones exactas
estimaciones de duración
checks por etapa
criterios de abort
cutover
rollback/forward fix
observación posteriorpg_upgrade, dump/restore y logical replication tienen trade-offs diferentes.pg_upgrade --link complica rollback?postgresql.conf completo?Antipatrones de PostgreSQL con contexto transforma reglas simplistas en criterios de decisión.