A dos meses del fin de soporte de PostgreSQL 14: practique la recuperación antes de actualizar
Hay equipos que tienen programada la fecha para actualizar la versión de su base de datos, pero desconocen cuánto tiempo tomaría revertir el proceso si falla. Si opera PostgreSQL 14, el entregable necesario ahora no es solo el nombre de una nueva versión, sino un plan de migración con capacidad de recuperación. A fecha del 14 de septiembre de 2026, quedan aproximadamente dos meses para la fecha oficial de fin de soporte.
Hecho confirmado: el soporte de la comunidad y los contratos de hosting son diferentes
La política oficial de versiones de PostgreSQL contempla cinco años de soporte para las versiones principales (major versions) e indica el 12 de noviembre de 2026 como la fecha de la versión final de la rama 14. Este es el calendario de soporte de la comunidad. Las ventanas de actualización de los servicios administrados, el soporte extendido independiente y las tarifas deben verificarse por separado en la documentación y los contratos de cada proveedor.
También se deben distinguir las actualizaciones menores dentro de la misma versión principal de las actualizaciones mayores. Aplicar la versión corregida más reciente de la rama 14 no sustituye la migración a la versión 15 o superior. Por el contrario, tampoco es adecuado posponer continuamente la aplicación de correcciones necesarias en la versión actual con el pretexto de que existe un plan de migración a una versión mayor.
Primer entregable: la lista de dependencias antes que el tamaño de los datos
A partir de aquí, se presentan recomendaciones operativas prácticas y no la política oficial de soporte en sí. En primer lugar, registre en un único documento la versión de la base de datos por servicio, las extensiones y sus versiones, los controladores de conexión, los trabajos por lotes (batch), las ubicaciones de almacenamiento de copias de seguridad y la configuración de replicación. No elija la versión de destino únicamente por ser la más reciente; compruebe también el entorno de hosting real y el alcance de compatibilidad de las extensiones.
Asumir que será rápido porque se trata de una base de datos pequeña no es suficiente. Si cambian las extensiones o las consultas utilizadas en rutas críticas para el negocio, como la primera consulta tras iniciar sesión o la actualización del estado de un pago, la migración puede fracasar aunque la copia de datos tome poco tiempo. El propósito de esta lista es identificar dependencias que carezcan de un responsable asignado.
Segundo entregable: el resultado de la restauración en lugar del mensaje de éxito del respaldo
Restaure una copia de seguridad reciente en un entorno aislado y ejecute los flujos representativos de lectura y escritura de la aplicación. En este ejercicio, verifique primero el destino de conexión para asegurarse de no enviar escrituras a la base de datos de producción. Las copias restauradas que contienen datos reales deben manejarse dentro del alcance de los controles de acceso existentes.
Diferenciar la hora de inicio del respaldo, la hora de finalización de la restauración y la hora de conclusión de la validación evita confundir el tiempo necesario para transferir los archivos con el tiempo en que el servicio puede volver a escribir datos. En lugar de validar únicamente muestras pequeñas artificialmente rápidas, mida los tiempos con una copia restaurada de tamaño cercano al de producción y registre también las limitaciones de costo y espacio.
Superar las comprobaciones de pg_upgrade no sustituye la validación del servicio
La documentación oficial de pg_upgrade explica que la opción --check permite realizar comprobaciones de compatibilidad antes de la actualización real. La compatibilidad de los módulos externos debe examinarse por separado y también se requieren las bibliotecas compartidas adecuadas para el nuevo servidor. No interprete el éxito del comando de comprobación como una validación completa de las consultas y el rendimiento de la aplicación.
En particular, el método --link presenta la restricción de que, una vez iniciado el nuevo clúster, el clúster original ya no puede utilizarse tal cual. Si elige el método basándose únicamente en la velocidad, podría perder la vía de reversión prevista. Realice ensayos bajo las mismas condiciones del método de migración real y defina claramente el momento en que se requerirá un retorno basado en restauración.
Criterios que deben definirse antes de reanudar las escrituras
Defina por escrito los criterios de éxito con antelación para no tener que improvisar acuerdos el día de la migración. Por ejemplo, puede vincular con un responsable la finalización de lecturas y escrituras de las API clave, la reanudación de procesos por lotes sin procesamiento duplicado, la coincidencia de agregaciones críticas del negocio en tablas principales y la verificación del estado de replicación. Este no es un ejemplo para imponer los mismos valores de referencia a todos los servicios.
Si se reanudan las escrituras en la nueva base de datos y posteriormente se debe regresar a la copia de seguridad anterior, surge el problema de cómo conservar los cambios ocurridos en ese intervalo. No trate el simple procedimiento de encender el servidor anterior como equivalente a un procedimiento de reversión sin pérdida de datos. Los responsables del servicio deben consensuar el alcance admisible de pérdida de datos y tiempo de inactividad.
Tareas para esta semana y objeciones habituales
Si resulta difícil migrar todas las bases de datos a la vez, mida los tiempos de restauración, validación y reversión con un único servicio que tenga la menor cantidad de dependencias y utilice los resultados como insumo para la planificación de los demás servicios. Reunir en un solo documento a los responsables, las fechas tentativas de migración y los criterios de aborto en caso de fallo en la validación transformará un proyecto que solo tiene cronograma en tareas accionables.
Es comprensible el argumento de que el desarrollo del producto es más urgente en este momento. Sin embargo, mantener el desconocimiento sobre cómo recuperarse hasta el último momento reducirá el tiempo disponible para verificaciones. Este artículo no defiende las mejoras de rendimiento de una versión específica ni representa la opinión de toda la comunidad. Es una recomendación operativa centrada en estar preparado para afrontar un fallo en la migración, más que en la velocidad de adopción de las funciones más recientes.