Una versión mayor al año, cinco años de parches
PostgreSQL publica una versión mayor aproximadamente una vez al año y la mantiene cinco años. Pasado ese plazo, aparece una última versión menor y la rama entra en fin de vida, siempre con la entrega de noviembre: PostgreSQL 13 se detuvo el 13 de noviembre de 2025 y PostgreSQL 14 se detendrá el 12 de noviembre de 2026. Las ramas todavía mantenidas van de la 14 a la 18; la 18 está disponible desde el 25 de septiembre de 2025, y la 19 está anunciada para septiembre de 2026.
Lo que el fin del soporte cambia realmente
- Ningún parche más — una vulnerabilidad publicada después del fin de vida no se corregirá en su rama: el código se queda tal cual, indefinidamente.
- Las extensiones se descuelgan —
PostGIS,pgvectoroTimescaleDBdejan de publicar paquetes para una rama muerta, y la siguiente necesidad se vuelve bloqueante. - Los paquetes de la distribución desaparecen — se acaban las actualizaciones por
apt, y una reinstalación del VPS no recupera necesariamente la misma versión. - El cumplimiento normativo lo detecta — una auditoría, un cuestionario de cliente o un contrato de seguro señalan un componente sin mantenimiento mucho antes de que ocurra un incidente.
- Los clientes y los controladores avanzan — las herramientas recientes (
psql,pg_dump, drivers de aplicación) dan por supuestas versiones de servidor mantenidas; la brecha acaba produciendo errores difíciles de leer.
Saber en qué versión está funcionando
El servidor es la autoridad, no su archivo de despliegue. Conéctese y ejecute SELECT version();, o SHOW server_version; para obtener el valor desnudo. En Debian y Ubuntu, pg_lsclusters enumera cada clúster con su versión, su puerto y su estado, incluidos los olvidados en una actualización anterior. En contenedor, la etiqueta de imagen induce a error: sustituir postgres:16 por una etiqueta más reciente no convierte los archivos ya escritos en el volumen.
Planificar la actualización de versión
Hacer la copia de seguridad y luego verificarla
Exporte los roles y los parámetros globales con
pg_dumpall --globals-only, y después cada base de datos conpg_dump -Fc. Una copia de seguridad solo cuenta si se ha restaurado: vuelva a aplicarla en un clúster desechable y compare los recuentos de filas de sus tablas principales.Elegir entre exportación lógica y conversión in situ
pg_dumpseguido depg_restorereconstruye todo en un clúster nuevo: sencillo, reversible, pero el tiempo de parada sigue al volumen.pg_upgradeconvierte el catálogo del clúster existente en unos minutos, siempre que instale los binarios de ambas versiones uno junto al otro.Ensayar la migración sobre una copia
No pruebe en la máquina que sirve el tráfico. Levante un segundo VPS, restaure allí la copia de seguridad y ejecute
pg_upgrade --check: valida la compatibilidad sin escribir nada y enumera los ajustes manuales previstos. Cronometre la operación: esa medida fija su ventana.Conmutar cortando las escrituras
Detenga la aplicación y luego el servidor de forma limpia. Lance la conversión o la restauración, arranque sobre el clúster nuevo y devuelva el tráfico tras un primer control. Elija el modo con conocimiento de causa:
--linky--swapaceleran la conmutación, pero dejan el clúster anterior inutilizable.Controlar después de la conmutación
Confirme la versión con
SELECT version();, actualice sus extensiones conALTER EXTENSION ... UPDATEy regenere las estadísticas del optimizador convacuumdb --all --analyze-in-stages. No elimine el directorio de datos anterior hasta después de varios días de explotación real, y hágalo con el script que indicapg_upgrade.Reanudar un ciclo de copias de seguridad completo
Sus archivos anteriores a la conmutación describen un clúster que ya no existe. Vuelva a hacer una copia de seguridad completa sobre la nueva versión y pruebe su restauración: nuestra guía sobre copias de seguridad cifradas con restic cubre la rotación y el control de integridad. En un VPS Cloud, ese calendario sigue siendo suyo.
pg_dump/restore o pg_upgrade: cómo decidir
Desplace la tabla
| Criterio | pg_dump / pg_restore | pg_upgrade |
|---|---|---|
| Principio | Exportación lógica y después reimportación en un clúster nuevo | Conversión del catálogo del clúster existente |
| Tiempo de parada | Proporcional al volumen de datos | Unos minutos, poco sensible al volumen en modo `--link` o `--swap` |
| Espacio en disco | Sitio para el archivo y después para los dos clústeres | `--link` no vuelve a copiar los archivos, pero impone el mismo sistema de archivos |
| Vuelta atrás | El clúster anterior queda intacto y el archivo sigue siendo restaurable | Tras `--link` o `--swap`, el clúster anterior ya no puede arrancarse |
| Control previo | El fallo se descubre tarde, durante la importación | `pg_upgrade --check` valida antes de cualquier escritura |
| Estadísticas del optimizador | Hay que reconstruirlas por completo tras la importación | Transferidas en gran parte desde PostgreSQL 18; antes, hay que reconstruirlas |
| Paralelismo | `pg_dump -j` y `pg_restore -j` | `--jobs` para tratar varias bases de datos en paralelo |
| Terreno predilecto | Volúmenes modestos, cambio de máquina, reorganización | Grandes volúmenes, actualización in situ, ventana corta |
El verdadero control es la restauración
Una rama en fin de vida no emite ninguna alerta, y una copia de seguridad nunca restaurada tampoco. Antes de la conmutación, liste el archivo con pg_restore --list, restáurelo por completo en una máquina aparte y compare los recuentos de filas de sus tablas sensibles. Anote después la fecha de fin de vida de su rama en la agenda que lleva sus renovaciones: un vencimiento silencioso se convierte en una tarea planificada.
