Principales conclusiones

•   PostgreSQL 12 llegó al final de su ciclo de vida el 14 de noviembre de 2024, y su última versión de la comunidad, la 12.22, se lanzó una semana después; a partir de entonces, la comunidad ya no ofrecerá más parches de seguridad ni correcciones de errores.
•   La base de datos sigue funcionando tras el fin de vida útil (EOL), y ahí radica el problema: las vulnerabilidades CVE sin parchear se acumulan silenciosamente hasta que una auditoría de cumplimiento o un ataque las convierten en un asunto urgente.
•   Las opciones viables son actualizar a una versión compatible (18, 17, 16 o 15) o recurrir al soporte ampliado ofrecido por el proveedor o por el proveedor de servicios en la nube para seguir recibiendo parches mientras planificas la migración.
•   Las actualizaciones importantes de PostgreSQL requieren tiempo real para realizar pruebas: los problemas de compatibilidad relacionados con las extensiones y los controladores suelen suponer más trabajo que la propia migración.

Tu instancia de PostgreSQL 12 no se colgó el 15 de noviembre de 2024. Probablemente ni siquiera tuvo ningún pequeño fallo. Y ahí está la trampa.

PostgreSQL 12 llegó al final de su ciclo de vida el 14 de noviembre de 2024. La comunidad lanzó una última versión fuera de ciclo, la 12.22, una semana después para corregir una regresión, y luego cerró la rama definitivamente. El software sigue funcionando. Pero ya no se ofrecen parches de seguridad ni correcciones de errores. La mayoría de los equipos lo dejan discretamente en producción y pasan a tareas más urgentes. Entonces, meses más tarde, resulta que una vulnerabilidad recién revelada afecta a la línea 12.x, no hay ningún parche de la comunidad a la vista y un sistema que «funcionaba bien» de repente presenta un fallo conocido e irreparable.

Esta guía explica qué es lo que realmente cambió en esa fecha de fin de vida útil, cuáles son los riesgos reales en la práctica y cuáles son tus opciones para volver a tener el sistema actualizado, incluyendo comentarios sinceros sobre los puntos en los que cada opción puede resultar complicada.

¿Qué significa el fin de la vida útil de PostgreSQL 12?

El fin de vida útil (EOL) significa que el Grupo Global de Desarrollo de PostgreSQL ha lanzado la última versión 12.x y ha cerrado la rama. No habrá parches de seguridad ni correcciones de errores. Si una vulnerabilidad recién revelada afecta a PostgreSQL 12, permanecerá sin parchear por parte de la comunidad de forma permanente. Una base de datos en EOL que procese datos regulados o que dé soporte a una aplicación conectada a Internet se convierte en un riesgo cada vez mayor cada vez que aparece un nuevo fallo en su rama, ya que no se va a publicar ninguna corrección por parte de la comunidad.

Fechas importantes de fin de vida útil (EOL) de PostgreSQL que hay que tener en cuenta

El proyecto PostgreSQL ofrece soporte para cada versión principal durante cinco años desde su lanzamiento inicial; a continuación, publica una última versión menor y da el proyecto por concluido. No hay niveles separados de «activo» y «mantenimiento» como en Node.js LTS. Se trata de un único periodo de cinco años, tras el cual la rama queda retirada.

Versión	Publicado	Final de la vida	Estado
18	Septiembre de 2025	Noviembre de 2030	Compatible (última versión)
17	Septiembre de 2024	Noviembre de 2029	Compatible
16	Septiembre de 2023	Noviembre de 2028	Compatible
15	Octubre de 2022	Noviembre de 2027	Compatible
14	Septiembre de 2021	Noviembre de 2026	Disponible (termina pronto)
13	Septiembre de 2020	Noviembre de 2025	EOL
12	Octubre de 2019	Noviembre de 2024	EOL
11	Octubre de 2018	Noviembre de 2023	EOL

Si estás en la versión 12, te faltan dos versiones principales para llegar a la rama más antigua compatible. Si estás en la versión 13, te has unido al club de las versiones al final de su vida útil en noviembre de 2025. La versión 14 parece segura sobre el papel, pero su fin de vida útil (EOL) llega el 12 de noviembre de 2026, más cerca de lo que la mayoría de la gente cree.

Por qué se retiran las versiones de PostgreSQL

Retirar una versión principal no significa que la comunidad se esté mostrando difícil. Se trata de una decisión deliberada que contribuye a la buena salud del proyecto. Hay varios factores que la impulsan.

El plazo de cinco años está fijado por diseño

PostgreSQL se compromete a ofrecer cinco años de soporte técnico por cada versión principal, contados a partir del lanzamiento inicial. Esa previsibilidad resulta realmente útil: basta con consultar cualquier versión para saber su fecha de caducidad con años de antelación.

El problema es que al reloj no le importa tu retraso en la migración. PostgreSQL 12 salió al mercado en octubre de 2019, por lo que su fin de vida útil (EOL) en noviembre de 2024 quedó fijado de hecho desde el primer día. Los equipos que consideraron esa fecha como «algún día» se encontraron con que llegó puntualmente, como suele ocurrir con las fechas.

El mantenimiento de las sucursales antiguas resulta caro

Cada versión principal compatible constituye una rama independiente que los responsables del mantenimiento deben actualizar, probar y publicar. La adaptación de una sola corrección de seguridad a cinco o seis ramas activas supone un auténtico trabajo de ingeniería, que llevan a cabo los colaboradores del proyecto y las empresas que los patrocinan.

Llega un momento en el que el coste de mantener activa una rama antigua supera los beneficios. Las rutas de código se divergen. La infraestructura de pruebas se queda obsoleta. Una corrección que resulta sencilla en la rama actual puede requerir una intervención complicada en un código con cinco años de antigüedad. Retirar la rama más antigua permite al proyecto dedicar esa energía a las versiones que la mayoría de los usuarios utilizan realmente.

Las actualizaciones de seguridad retroactivas tienen una vida útil limitada

Algunas vulnerabilidades son fáciles de corregir en código antiguo. Otras dependen de una arquitectura que ha cambiado en las versiones más recientes, y aplicar esas correcciones a una rama mucho más antigua puede resultar, en el mejor de los casos, complicado y, en el peor, realmente arriesgado. La propia adaptación podría provocar regresiones en rutas de código que nadie ha utilizado en años.

Una vez que una versión llega al final de su ciclo de vida (EOL), la carga que supone la adaptación a versiones anteriores recae sobre ti o sobre quienquiera que contrates para que se encargue de ello.

Riesgos de utilizar una versión de PostgreSQL al final de su ciclo de vida

Los riesgos de seguir utilizando PostgreSQL 12 no son hipotéticos. Se agravan cuanto más se espera.

Vulnerabilidades de seguridad sin parchear

Cualquier vulnerabilidad revelada en PostgreSQL 12 tras su fin de vida útil (EOL) seguirá sin resolverse por parte de la comunidad, y punto. La versión 12.22, lanzada fuera de ciclo el 21 de noviembre de 2024, fue la última versión de parche que recibirá la versión 12; se publicó para corregir una regresión en la 12.21, no para ampliar el soporte. Cualquier vulnerabilidad revelada a partir de entonces o bien no afecta a la versión 12, o bien, aunque la afecte, nunca contará con una solución por parte de la comunidad.

La tendencia general agrava aún más la situación. Los sistemas de seguimiento de vulnerabilidades registraron 16 CVE de PostgreSQL en el primer semestre de 2026 —ya más que en todo el año 2025— con una puntuación media de gravedad superior a 7. La versión de seguridad de mayo de 2026 corrigió por sí sola 11 vulnerabilidades en las ramas compatibles, con puntuaciones de gravedad de hasta 8,8. No todas ellas afectan a la versión 12. La preocupación es lo que ocurre cuando un problema recién revelado sí lo hace: la comunidad ya no ofrece una solución para él.

Si deseas obtener más información sobre cómo proteger tu entorno frente a los riesgos derivados de la falta de parches, puedes consultar nuestra guía detallada sobre las mejores prácticas de seguridad de PostgreSQL. También puedes conocer las vulnerabilidades de PostgreSQL y los riesgos de seguridad que pueden suponer en nuestra guía exhaustiva.

Esta es precisamente la laguna que el soporte ampliado ofrecido por el proveedor viene a cubrir. Encontrarás más información al respecto en la sección de opciones que figura a continuación.

Cumplimiento y fallos de auditoría

PCI DSS exige explícitamente la aplicación de parches a las vulnerabilidades conocidas y el seguimiento de la tecnología que ha llegado al final de su vida útil dentro del ámbito de aplicación. La HIPAA y SOC 2 no mencionan directamente el software al final de su vida útil, pero los evaluadores consideran que una base de datos que ya no puede recibir parches de seguridad es un problema en potencia. En cualquier caso, «el proveedor dejó de aplicar parches» es una postura difícil de defender, independientemente de lo bien protegida que esté el resto de tu infraestructura.

Los auditores comprueban directamente el estado de soporte de las versiones mediante cuestionarios, análisis de vulnerabilidades e inventarios de activos. «Estamos trabajando en la actualización» no es una respuesta convincente cuando la fecha de fin de vida útil (EOL) ya ha vencido en noviembre de 2024. Las deficiencias detectadas acarrean costes reales: pérdida de contratos, plazos de corrección y, en los sectores regulados, multas.

Deriva del ecosistema

La seguridad acapara toda la atención, pero el problema más lento es que todo lo relacionado con la base de datos está dejando atrás la versión 12. Los responsables del mantenimiento de las extensiones dejan de realizar pruebas con ella. Los controladores de cliente dejan de ofrecer compatibilidad. Los proveedores gestionados añaden recargos por soporte ampliado, bloquean nuevas implementaciones o programan actualizaciones obligatorias.

Ninguna de estas situaciones es catastrófica por sí sola, pero se van acumulando. Al final, el responsable de mantenimiento de una biblioteca lanza una versión que da por sentado el comportamiento de PostgreSQL 14 o superior, o tu integración de monitorización deja de admitir la versión 12.x. Te encuentras con una base de datos a la que no puedes tocar sin riesgo y de la que no puedes prescindir fácilmente.

Opciones tras el fin de la vida útil de PostgreSQL 12

Tienes cuatro opciones viables. La más adecuada depende de tu tolerancia al riesgo: ¿puedes asumir las molestias que conlleva una actualización ahora mismo, o necesitas mantenerte al día con los parches y cumplir con la normativa mientras planificas una ruta de migración estable?

1. Soporte ampliado con garantía del fabricante

Si no puedes realizar la migración de inmediato, pero tampoco puedes quedarte con un software sin parches, el soporte ampliado es la solución intermedia. Hay algunos proveedores que ofrecen este servicio. El servicio «Endless Lifecycle Support» de TuxCare cubre actualmente PostgreSQL 13, y la empresa ha anunciado planes para añadir la versión 14 antes de su fecha de fin de vida útil (EOL).

El objetivo del soporte ampliado no es evitar actualizar para siempre, sino convertir una fecha límite ineludible en un proyecto planificado. En lugar de una migración de emergencia que hay que encajar a toda prisa entre el desarrollo de nuevas funcionalidades, se obtiene una instancia actualizada y el margen de maniobra necesario para migrar cuando se esté preparado, en lugar de cuando un CVE o un auditor te obligue a hacerlo.

Esta opción es adecuada para equipos que operan en entornos regulados, aquellos que utilizan configuraciones muy personalizadas o cualquier persona cuyo plazo realista de migración se sitúe dentro de unos meses. Además, te ofrece una ruta de aplicación de parches documentada que podrás mostrar a los auditores mientras la actualización propiamente dicha aún está en curso.

2. Actualizar a PostgreSQL 18

PostgreSQL 18 es la versión actual, con soporte hasta noviembre de 2030. Pasar directamente a ella te ofrece el mayor margen de tiempo antes de tener que volver a realizar este ejercicio, además de las últimas mejoras en rendimiento y nuevas funcionalidades.

La contrapartida es la distancia: pasar de la versión 12 a la 18 supone seis saltos de versión principal, lo que implica más cambios de comportamiento que verificar de una sola vez: diferencias en el planificador, ajustes obsoletos y compatibilidad de las extensiones en todos los ámbitos. Utiliza pg_upgrade (con los binarios de la nueva versión instalados junto a los antiguos) en lugar de un volcado y una restauración completos, pero calcula un tiempo de prueba considerable:

pg_upgrade \

  –old-datadir /var/lib/postgresql/12/main \

  –new-datadir /var/lib/postgresql/18/main \

  –old-bindir /usr/lib/postgresql/12/bin \

  –new-bindir /usr/lib/postgresql/18/bin \

  –comprobar

Las rutas que se muestran son las predeterminadas de Debian/Ubuntu; adáptalas a tu distribución. Ejecútalo con –check primero: detecta muchos problemas graves antes de que te comprometas a nada, aunque no detectará todos los problemas a nivel de aplicación o de rendimiento.

3. Actualizar a PostgreSQL 17, 16 o 15 (todavía con soporte técnico)

Si la versión 18 te parece un salto demasiado grande, PostgreSQL 17 (fin de vida útil en noviembre de 2029), 16 (fin de vida útil en noviembre de 2028) y 15 (fin de vida útil en noviembre de 2027) siguen contando con el apoyo de la comunidad y se acercan más al comportamiento de la versión 12. Muchos equipos optan por una de estas versiones como paso intermedio deliberado: ofrecen un periodo de soporte lo suficientemente largo como para que merezca la pena, y presentan menos sorpresas que la última versión.

No obstante, ten en cuenta el calendario. Si eliges la versión 15 en 2026, apenas dispondrás de un año y medio antes de tener que volver a planificar el fin de vida útil (EOL); las versiones 17 o 16 ofrecen a la estrategia intermedia un margen de maniobra real. Optar por una de estas en lugar de la 18 tiene sentido cuando tus extensiones aún no se han certificado para la versión más reciente, o cuando prefieres una versión con un historial de producción más extenso.

Consejo de experto: Ejecuta SELECT * FROM pg_extension; en tu instancia 12.x en producción antes de elegir un objetivo y, a continuación, comprueba cada extensión con respecto a la versión candidata. Las extensiones, y no el núcleo de PostgreSQL, suelen ser el motivo por el que las actualizaciones se estancan a mitad del proyecto.

4. Soporte ampliado para la nube gestionada

Si utilizas Amazon RDS, Google Cloud SQL o una implementación de Azure Database for PostgreSQL que cumpla los requisitos, es posible que tu proveedor ofrezca soporte ampliado de pago para determinadas versiones al final de su ciclo de vida (EOL); las normas de disponibilidad e inscripción varían según el servicio y la versión. Amazon RDS incorporó PostgreSQL 12 al programa de soporte ampliado de RDS tras finalizar su periodo de soporte estándar el 28 de febrero de 2025, con recargos por vCPU. Google Cloud SQL comenzó a cobrar tarifas de soporte ampliado para las versiones principales en fin de vida útil (EOL) el 1 de mayo de 2025. Azure ahora inscribe automáticamente los servidores que utilizan versiones sin soporte en el «Soporte ampliado» de forma automática, y la facturación para la versión 13 comenzará el 1 de agosto de 2026.

Esto te permite disponer de actualizaciones de seguridad gestionadas por el proveedor sin tener que mantener tus propias versiones retrocompatibles de PostgreSQL, lo cual resulta realmente útil. Sin embargo, los recargos aumentan con el tiempo —la tarifa de AWS sube tras los dos primeros años—, así que considéralo como un periodo de gracia limitado, no como una estrategia a largo plazo. Lee atentamente los precios por instancia antes de dar por sentado que es la opción más económica.

Aquí tienes la decisión de un solo vistazo:

Si tu situación es…	La mejor jugada
No puedo realizar la migración a corto plazo, pero necesito mantenerme al día con los parches y cumplir con la normativa	Soporte ampliado ofrecido por el proveedor (por ejemplo, el «Endless Lifecycle Support» de TuxCare)
¿Estás listo para la migración y quieres el mayor plazo de soporte posible?	Actualizar a PostgreSQL 18
¿Estás listo para la migración y quieres evitar sorpresas?	Actualizar a la versión 17 o 16
En la nube gestionada, ganarse un respiro a corto plazo	Asistencia técnica ampliada del proveedor

Planificar la migración antes de que se convierta en una urgencia

Los equipos que gestionan bien el fin de vida útil (EOL) lo tratan como cualquier otro proyecto programado. Los que tienen dificultades suelen considerar la fecha de fin de vida útil como el momento en el que hay que empezar a pensar en ello, lo cual supone aproximadamente un año de retraso.

Un plan de migración viable suele incluir:

•   Inventario. Todas las instancias 12.x, incluidas la réplica olvidada y el servidor de análisis que nadie se hace cargo.
•   Auditoría de dependencias. Extensiones, controladores de cliente, ORM y herramientas de replicación, todos ellos comprobados con respecto a tu versión de destino.
•   Una decisión sobre la versión objetivo. Se ha elegido en función de la compatibilidad con las extensiones y la perspectiva de soporte, no por corazonadas.
•   Una ruta de actualización probada. pg_upgrade o la replicación lógica para un tiempo de inactividad prácticamente nulo, probados en el entorno de pruebas antes de intervenir en el de producción.
•   Un puente provisional. Cómo garantizar la seguridad desde ahora hasta el día de la migración. A menudo, esto implica recurrir al soporte ampliado del proveedor o de la nube; los controles compensatorios documentados son la alternativa menos segura.
•   Un plan de reversión. Porque siempre surgirá algún imprevisto y querrás una salida que no sea «restaurar desde la copia de seguridad de anoche».

La realidad: A los proveedores les encanta calificar las actualizaciones importantes de «sin complicaciones». Pero no lo son. Incluso una ejecución correcta de pg_upgrade te obliga a volver a validar extensiones, reajustar configuraciones y observar cómo cambian los planes de consulta. Para un entorno de producción con dependencias significativas, hay que prever semanas de pruebas, no solo una ventana de mantenimiento.

Qué hacer si PostgreSQL 12 sigue en producción

PostgreSQL 12 no va a dejar de funcionar, y precisamente por eso es fácil ignorarlo hasta que un CVE o una auditoría lo conviertan en algo urgente. La conclusión sincera: toma una decisión a sabiendas. Actualiza a una versión compatible si puedes hacerlo. Si no puedes, asegúrate de aplicar los parches necesarios para que ese «todavía no» no se convierta en «expuesto durante un año».

En cuanto al soporte ampliado, TuxCare ofrece actualmente soporte para la versión 13 si necesitas una opción comercial de aplicación de parches mientras planificas la actualización, y se ha anunciado la cobertura de la versión 14 antes de su fin de vida útil (EOL). Comprueba la cobertura exacta de la versión con cualquier proveedor antes de considerar el soporte ampliado como una solución provisional.

Empieza por hacer un mapa de tu entorno 12.x: cuántas instancias hay, qué extensiones utilizan y qué depende de ellas. Ese inventario por sí solo suele aclarar qué camino es el más adecuado. El peor resultado es aquel en el que nunca te decides por nada.

Preguntas frecuentes