Es recurrente que, con el paso del tiempo, las organizaciones no presten atención a la importancia de realizar los updates o cambiar a las nuevas versiones que van apareciendo de la base de datos. Ya sea por la comodidad de dejar quieto lo que está funcionando y los posibles problemas que conlleva realizar esta tarea, o por sistemas donde no se tiene el privilegio de detener la base de datos por ser críticos, detener el servicio representa pérdidas de dinero y disgusto a los clientes.
Cada nueva versión es más rápida y eficiente manejando los datos. Pero quedarse rezagado representa un riesgo de seguridad y desaprovechar las optimizaciones del motor de PostgreSQL y las nuevas funcionalidades que van incorporando, lo que resulta en aplicativos o servicios que se van degradando y ralentizando por no aprovechar los nuevos algoritmos y mejoras de código que funcionan y manejan los datos de forma mucho más eficiente.
Al momento que escribo este artículo, la versión de Postgres es la 18.3. Es viable realizar un pg_upgrade cuando estás en la misma versión o al menos en la anterior sin muchos saltos de actualizaciones. Pero cuando tenemos un salto significativo de versión (desde la versión 6 hasta la 15 o 16, para saltar a la 18), la utilidad pg_upgrade no es lo más recomendado. Ejecutar un pg_upgrade que salta de versiones antiguas de un solo golpe no ofrece el resultado esperado; lo ideal sería realizar el upgrade versión por versión, pero esto es un trabajo que implica mucho tiempo, es muy costoso e implica detener la base de datos muchas veces, maximizando los riesgos de que la base de datos no levante o su performance se vea más afectado en vez de obtener mejoras en el rendimiento.
Upgrades de PostgreSQL sin pg_upgrade: Guía para migrar terabytes de Datos sin detener el servicio
Utilizar replicación es una buena alternativa que considero la más eficiente. La replicación permite arrancar con una base de datos fresca y sin desgastes de configuración; permite cambiar de forma simultánea, si es necesario, a un nuevo servidor físico y pasar a la última versión del sistema operativo. Si se actualiza el sistema operativo, se añade la ventaja de que puedes adecuar y optimizar todos los parámetros recomendados dentro de las buenas prácticas, como por ejemplo adecuar los parámetros del kernel. La replicación permite transferir de forma controlada y progresiva la data a la nueva versión sin utilizar pg_dump; la data se transfiere tabla por tabla, registro por registro. Una vez que se logra sincronizar ambas bases de datos (origen con la versión destino actualizada), se realizan otra serie de pasos para completar la actualización-migración completa, ejecutar el apagado del aplicativo y promover la nueva versión a producción.
En la mayoría de los casos, con un trabajo bien planificado, solo se pueden necesitar algunos minutos; en el escenario más ideal, hasta en 1 minuto se puede “switchear” el aplicativo de una versión a la otra. Hemos realizado actualizaciones con ese resultado donde el downtime solo duró un minuto. Una vez que se promueve a la nueva versión, se deben cargar dos componentes esenciales que son las secuencias y los índices, y se hace el switch del aplicativo para que estrene su nueva versión de base de datos.
Escenarios donde la actualización con replicación es más conveniente
Salto de versión: Principalmente cuando el salto de versión es alto; planear hacer un pg_upgrade de una versión 12 a una 18 es muy riesgoso. Si se ejecuta un upgrade por cada lanzamiento de versión, en algún punto del camino se presentan los problemas y, al final, la base de datos no alcanza el rendimiento esperado por la disparidad de los distintos cambios y disparidad en los componentes sobre la plataforma.
Tamaño de los datos: Cuando las bases de datos son grandes o gigantes (desde 1 TB hacia arriba: 5 TB, 10 TB y más) y si la actualización se realiza moviendo la data a otro servidor, los tiempos para realizar un restore con pg_dump no son nada alentadores. Si el sistema es crítico y el downtime debe ser mínimo, por mucha memoria y recursos que disponga el servidor, el proceso de descomprimir el backup, validar el contenido, verificar la estructura, realizar la carga y escribir al disco le toma su tiempo a Postgres, ya que debe validar la consistencia de los datos.
A continuación, visualizamos la siguiente tabla que muestra los tiempos aproximados que toma hacer un restore en base al tamaño de los datos. Estos datos los hemos obtenido en laboratorio realizando el restore para los primeros 3 valores y determinando el tiempo para los demás tamaños. Esto se debe a que pg_dump es un proceso lineal, mientras que la replicación lógica es progresiva: se toma su tiempo para completar la transferencia pero no se apaga la base de datos, mientras que con un restore se debe apagar para garantizar la consistencia de datos. El laboratorio se realizó para cada tamaño con los mismos recursos de hardware y con la versión 18.3 de Postgres. Tengamos en cuenta que los valores cambian para cada tipo de hardware en base a su potencia y cantidad de memoria.
Tabla Comparativa: Downtime según el Tamaño de la Base de Datos
| Volumen de Datos | Downtime: Método Tradicional (pg_restore) | Downtime: Replicación (Switchover) |
| 1 TB | 6-12 Horas (Riesgo Moderado) | 1-5 Minutos (Continuidad) |
| 2 TB | 12-24 Horas (Interrupción Critica) | 1-5 Minutos (Continuidad) |
| 5 TB | 2-6 Días (Inceptable) | 1-5 Minutos (Continuidad) |
| 10 TB | +1 Semana (Catastrófico) | 1-5 Minutos (Continuidad) |
| 20 TB | Inviable | 1-5 Minutos (Continuidad Total) |
Nota técnica: El tiempo de 1 a 5 minutos mediante replicación lógica se refiere exclusivamente a la ventana de cambio (switchover), asumiendo una sincronización previa completa de los datos en segundo plano.
“Tiempos estimados basados en entornos con almacenamiento SSD de alto rendimiento y una carga moderada de índices. Los resultados pueden variar según la infraestructura.”
Ambiente clusterizado o HA: Te podrás estar preguntando si mi base de datos Postgres está en un cluster, ¿aplica este método que estamos evaluando? La respuesta es sí. Debido a la naturaleza de que cada nodo en un cluster Postgres debe tener la misma versión, no es tan simple como detener un nodo, cambiarlo de versión y volver a agregarlo al cluster.
Problema de compatibilidad: Si se intenta actualizar un solo nodo dentro de un cluster de Patroni o Repmgr, vas a romper el consenso del cluster.
El Problema de la Compatibilidad (Binary vs. Logical): Los clusters como Patroni usan Replicación Física (Streaming Replication). Esta replicación copia los bloques de datos bit a bit. Por diseño de PostgreSQL, la replicación física no es compatible entre versiones mayores. Un nodo con Postgres 18 no puede ser un “follower” (réplica física) de un maestro con Postgres 12. Si actualizas un nodo a v18, ese nodo se vuelve un “extraño” para el resto del cluster de v12.
El Escenario Correcto: El Puente Lógico: Usando la replicación lógica como estrategia correcta, el plan no es tocar los nodos actuales del cluster, sino crear un destino paralelo.
- Paso A: Mantienes tu cluster de 3 nodos en v12 funcionando normalmente.
- Paso B: Levantas un nuevo servidor independiente (o un nuevo cluster vacío) con Postgres 18.
- Paso C: Establecer la Replicación Lógica desde el Maestro de v12 hacia el nuevo Maestro de v18.
- Paso D: Una vez sincronizados, haces el “Switchover” (mueves la aplicación al v18) y luego destruyes el cluster viejo de v12.
¿Qué pasa con Patroni/Pgpool?
- Patroni: Solo gestiona la alta disponibilidad dentro de una misma versión. No está diseñado para “mezclar” versiones durante un upgrade.
- Pgpool-II: Podría ayudarte en el momento del corte (switchover) para redirigir el tráfico sin cambiar las IPs en la aplicación, pero no ayuda en la migración de los datos per se.
No se puede actualizar un nodo de un cluster de alta disponibilidad de forma aislada esperando que siga perteneciendo al grupo. La actualización de la versión mayor rompe la simetría binaria. La solución es tratar al nuevo servidor (v18) como un suscriptor lógico externo hasta que esté listo para tomar el mando.
Dónde está la magia de la actualización con replicación: Existen varios mecanismos para ejecutar la replicación lógica desde un maestro, ya sea clusterizado o base de datos standalone (solo). Se pueden implementar scripts que hagan la tarea de mover los datos registro por registro (claro está, después de haber migrado previamente la estructura) o utilizar una vieja pero buena herramienta de replicación como Bucardo. Una vez que mueves la data y ya está sincronizada, es tan simple como parar el aplicativo, exportar secuencia y apuntar a la nueva IP.
En Arcanum Data podemos ayudarte a dar este paso y actualizar tus versiones de Postgres para mejorar la velocidad y el rendimiento de tus sistemas de forma exitosa.
