Fin de soporte de PostgreSQL 14: cómo preparar la actualización empresarial
Por Carlos Isidoro De Ayala Diaz ·
Fin de soporte de PostgreSQL 14: cómo inventariar bases de datos, revisar extensiones, ensayar la actualización y preparar una reversión segura y comprobable.
Localiza cada PostgreSQL 14 y la aplicación que depende de él
PostgreSQL 14 dejará de recibir correcciones el 12 de noviembre de 2026, según el calendario oficial del proyecto. El primer paso no es instalar otra versión, sino comprobar dónde sigue funcionando la 14. Puede existir en servidores propios, máquinas virtuales, contenedores, servicios administrados, equipos de desarrollo, réplicas, copias de contingencia o aplicaciones antiguas que ya no aparecen en el inventario habitual. Para cada instancia conviene registrar propietario, finalidad, versión menor exacta, sistema operativo o proveedor, tamaño, crecimiento, disponibilidad requerida y relación con otros sistemas.
El inventario debe llegar hasta la aplicación. Hay que identificar controladores, ORM, herramientas de informes, procesos por lotes, integraciones, trabajos programados y usuarios técnicos que abren conexiones. También extensiones instaladas, lenguajes procedurales, collation, codificación, roles, tablespaces, réplica física o lógica y mecanismos de copia. Una base pequeña puede ser crítica si mantiene pedidos o identidades; una grande puede admitir una ventana amplia si solo conserva histórico. La prioridad se decide por impacto y dependencia, no únicamente por gigabytes.
Antes del cambio, PostgreSQL 14 debe estar en su última versión menor disponible y las copias deben probarse. El proyecto PostgreSQL recomienda mantener la versión menor corriente porque incorpora correcciones de errores, seguridad y posibles problemas de integridad. Actualizar dentro de la misma versión mayor no sustituye la migración, pero evita ensayar desde un estado antiguo y reduce variables. El inventario también anota quién puede autorizar una parada, quién valida la aplicación y quién administra infraestructura, porque una actualización técnica sin responsables operativos queda incompleta.
Elige la versión de destino después de revisar compatibilidad
El calendario de soporte ayuda a descartar un destino con poco recorrido, pero no decide por sí solo qué versión conviene. Hay que contrastar las versiones admitidas por el proveedor de la aplicación, los controladores que utiliza el código, las extensiones necesarias y el servicio de alojamiento. Saltar de PostgreSQL 14 a una versión mayor posterior es posible sin instalar todas las intermedias, aunque la política oficial recomienda leer las notas de todas las versiones atravesadas. Cada cambio relevante se convierte en una comprobación concreta sobre consultas, tipos, permisos, configuración o herramientas de operación.
Las extensiones requieren atención propia. Deben existir paquetes compatibles en el destino, conservar la misma finalidad y disponer de procedimiento de actualización. pg_upgrade puede informar de actualizaciones posteriores necesarias, pero esa advertencia no garantiza que una extensión de terceros funcione con la aplicación. También se revisan parámetros eliminados o renombrados, métodos de autenticación, reglas de pg_hba.conf, certificados, zonas horarias y collations. Cambiar de sistema operativo o de proveedor al mismo tiempo aumenta el alcance y debe documentarse como una migración combinada.
La compatibilidad se valida con una copia representativa y con las mismas dependencias de producción. Compilar el proyecto o abrir la pantalla inicial no basta: se seleccionan consultas intensivas, cierres, importaciones, búsquedas, informes, tareas nocturnas y operaciones que usan bloqueos o transacciones largas. Se registran plan y tiempo de ejecución antes y después para investigar variaciones significativas. Si el sistema es de un tercero, su confirmación de soporte y sus instrucciones forman parte de la decisión; no se deduce compatibilidad porque una conexión básica haya funcionado.
Ensaya el método de actualización con datos y tiempos reales
Una actualización de versión mayor necesita pg_upgrade o una exportación y restauración lógica, de acuerdo con la política de PostgreSQL. pg_upgrade reutiliza o transfiere los archivos de datos después de crear las estructuras del nuevo clúster y ofrece una comprobación previa con --check. Los modos que enlazan, clonan o intercambian archivos tienen ventajas de tiempo y espacio, pero cambian las condiciones de reversión. Una migración lógica con pg_dump y pg_restore puede facilitar cambios de plataforma o reorganización, aunque el tiempo de exportación, transferencia, creación de índices y validación puede ser mayor.
El ensayo debe utilizar una copia reciente, infraestructura comparable y el método previsto para producción. Se cronometra cada fase: copia o sincronización inicial, comprobaciones, parada de escrituras, actualización, análisis, actualización de extensiones, arranque de servicios y validación. También se mide el espacio temporal y la carga. Si se plantea replicación lógica para reducir la interrupción, se comprueban claves, secuencias, objetos no replicados, retraso y procedimiento de cambio; la documentación de pg_upgrade advierte que los clústeres con replicación lógica necesitan instrucciones específicas.
La validación combina estructura, datos y comportamiento. Se comparan bases, esquemas, tablas, filas donde resulte apropiado, roles, permisos, secuencias, extensiones, trabajos y parámetros esenciales. Después se ejecutan recorridos de negocio con cuentas de prueba y se revisan registros, errores y rendimiento. Una copia marcada como correcta debe poder restaurarse en un entorno aislado; que el programa de backup termine sin error no prueba su recuperación. El resultado del ensayo es un runbook con órdenes, tiempos, responsables, criterios de avance y condiciones que obligan a volver atrás.
Publica con una ventana, criterios de reversión y seguimiento
La puesta en producción parte de un punto de corte comunicado. Se detienen o controlan escrituras, integraciones, colas y tareas programadas para que ningún dato cambie durante una fase que exige consistencia. Antes de empezar se confirma la última copia recuperable, el acceso de los responsables y la capacidad disponible. El equipo anota cada hito y no continúa si falla una comprobación obligatoria. La ventana incluye tiempo para validar y, si es necesario, revertir; reservar únicamente el tiempo estimado para ejecutar comandos deja a la empresa sin margen de decisión.
La reversión depende del método. Puede requerir reactivar el clúster anterior, restaurar una copia o repetir las operaciones generadas después del corte. Si la nueva aplicación escribe datos que la versión antigua no entiende, volver a apuntar la conexión no es una solución segura. Por eso se define hasta qué momento puede regresarse, qué datos se perderían o reconciliarían y quién autoriza la decisión. Los modos de pg_upgrade que reutilizan archivos deben evaluarse especialmente: la rapidez del cambio no debe eliminar la única copia que permitía volver al estado conocido.
Tras abrir el servicio se revisan conexiones, bloqueos, errores, consultas lentas, réplicas, copias, espacio, tareas y recorridos críticos durante un periodo acordado. El clúster antiguo se conserva aislado solo el tiempo definido por la política y después se retira con evidencia, para evitar que alguien vuelva a usar una base desactualizada. Élite Solutions Tech puede ayudar desde Murcia a inventariar dependencias, preparar pruebas de aplicación y documentar el despliegue para empresas regionales o nacionales. En el formulario de contacto basta indicar versión, plataforma y aplicación afectada; no envíes credenciales, copias ni datos personales.