Resumen
PostgreSQL 14 dejará de recibir correcciones el 12 de noviembre de 2026. Eso no significa que tu base de datos deje de funcionar ese día, pero sí que cualquier fallo o vulnerabilidad que se descubra después ya no tendrá arreglo oficial. Si no sabes qué versión usa tu web o tu aplicación, o sabes que es la 14 o anterior, es el momento de planificar la actualización con calma, y no con prisas cuando haya un problema. Podemos revisar contigo qué versión tienes y preparar una ruta de migración segura y sin sorpresas. postgresql
Cada año, la comunidad de PostgreSQL deja de dar soporte a la versión más antigua. Es algo normal y previsible, pero muchas empresas no lo notan hasta que ya es tarde. Una base de datos sin parches sigue guardando tus facturas, clientes y pedidos como siempre, pero cada mes que pasa queda un poco más expuesta.
Punto 1 — Qué significa realmente «fin de soporte»
Qué pasa: a partir del 12 de noviembre, el equipo de PostgreSQL deja de publicar correcciones para la versión 14, tanto de errores como de seguridad.
Qué significa en palabras sencillas: es como un coche al que el fabricante deja de suministrar recambios y avisos de seguridad. Puede seguir circulando, pero cualquier avería o fallo nuevo corre por tu cuenta.
Cómo te afecta: tu base de datos seguirá funcionando, pero cualquier fallo de seguridad que se descubra después de esa fecha quedará sin parche oficial y expuesto.
Qué se hace para solucionarlo: conocer la fecha límite y decidir con tiempo si se actualiza ahora o más adelante, en lugar de descubrirlo cuando ya hay un incidente.
Punto 2 — Por qué los parches de seguridad importan más de lo que parece
Qué pasa: la última actualización de agosto corrigió 28 vulnerabilidades de seguridad en las versiones soportadas, además de numerosos errores.
Qué significa en palabras sencillas: en pocos meses se encuentran decenas de fallos que alguien podría aprovechar. Los parches los cierran, pero solo en las versiones que siguen recibiendo soporte.
Cómo te afecta: si sigues en una versión sin soporte, esos fallos no se cierran. Para una tienda online, un CRM o cualquier sistema con datos de clientes, eso supone riesgo de fuga de información, sanciones legales y pérdida de confianza.
Qué se hace para solucionarlo: pasar a una versión con soporte activo y mantener un calendario regular de actualizaciones menores, que son rápidas y de bajo riesgo.
Punto 3 — Cómo saber qué versión tienes
Qué pasa: mucha gente no sabe qué versión de PostgreSQL usa su web. Quien la montó hace años y no la ha tocado desde puede tener una versión muy antigua sin saberlo.
Qué significa en palabras sencillas: no puedes decidir si actualizar si no sabes de dónde partes.
Cómo te afecta: sin saberlo, puedes estar fuera de soporte desde hace tiempo o a punto de estarlo.
Qué se hace para solucionarlo: consultarlo es sencillo. Quien administra tu servidor solo tiene que ejecutar este comando:
SELECT version();
Si el resultado empieza por 14 o por un número menor, conviene planificar la actualización. Si no tienes a nadie que pueda hacerlo, nosotros lo revisamos por ti.
Punto 4 — Tus tres caminos posibles
Qué pasa: actualizar no es una única decisión, tienes tres opciones con ventajas e inconvenientes distintos.
Qué significa en palabras sencillas: puedes dar el salto ya a una versión estable y probada, esperar a la próxima gran versión, o quedarte donde estás asumiendo el riesgo.
Cómo te afecta cada una:
- Pasar ahora a una versión actual y estable (la 17 o la 18): es la opción más prudente. Son versiones maduras, con soporte por delante y ya probadas en producción por miles de empresas.
- Esperar a PostgreSQL 19: el objetivo actual es publicar la versión final a finales de octubre. Aun así, lo recomendable es dejar pasar unas semanas de estabilidad antes de llevarla a producción, como comentábamos en nuestro artículo anterior sobre las novedades de la 19. Si tu fecha límite es noviembre, esperar puede dejarte sin margen.
- Quedarte en la 14: posible, pero con el riesgo de seguridad asumido y sin parches oficiales a partir del 12 de noviembre. Solo tiene sentido como solución temporal y con una fecha clara para salir de ella.
Qué se hace para solucionarlo: para la mayoría de negocios, la mejor combinación es migrar a una versión estable ahora y revisar más adelante si compensa dar el salto a la 19.
Punto 5 — Cómo se hace la migración sin sorpresas
Qué pasa: actualizar una base de datos asusta porque, si algo sale mal, afecta directamente a la web y a los clientes.
Qué significa en palabras sencillas: con un buen plan, el cambio se prueba antes en una copia y solo se aplica en producción cuando se sabe que todo funciona.
Cómo te afecta: una migración improvisada puede causar caídas, errores y pérdida de datos. Una bien preparada pasa casi desapercibida para tus clientes.
Qué se hace para solucionarlo:
- Backup probado: antes de tocar nada, comprobar que existe una copia que se puede restaurar de verdad, tal y como explicábamos en el artículo de las 7 señales.
- Entorno de pruebas: copiar la base de datos a un servidor aparte y probar allí la actualización con tus datos reales.
- Revisar extensiones y compatibilidad: comprobar que lo que usa tu web (extensiones, plugins, consultas especiales) funciona con la versión nueva.
- Plan de vuelta atrás: definir de antemano cómo volver al estado anterior si algo no sale como se esperaba.
- Ventana de actualización acordada: elegir el momento de menor tráfico y avisar con tiempo para minimizar el impacto.
¿Cuándo actualizar?
Con seis semanas por delante, hay margen suficiente para hacerlo bien, pero no para dejarlo de lado. La recomendación es:
- Esta semana: averiguar qué versión tienes.
- En octubre: probar la actualización en un entorno de pruebas y preparar el plan.
- Antes del 12 de noviembre: migrar a una versión con soporte activo.
Si quieres saber en qué punto está tu base de datos, podemos hacer una revisión rápida de versión, seguridad y copias de seguridad, y proponerte un plan de migración claro y con presupuesto estimado.