El 12 de noviembre, PostgreSQL 14 recibe su última versión menor y la rama se queda sin parches de seguridad. Lo que viene después se bifurca según dónde esté esa base de datos: a unos les llegará en forma de cargo nuevo en la factura, y a otros no les llegará por ningún sitio.
La política es pública, y lleva años escrita
PostgreSQL mantiene cada versión mayor cinco años desde su publicación inicial. Después, en palabras literales de su política: «se publicará una última versión menor y el software quedará entonces sin soporte». No hay zona gris ni soporte extendido del proyecto: hay una fecha y, a partir de ahí, ya no salen parches de seguridad para esa rama.
En esa misma tabla están puestas ya las cuatro fechas siguientes:
| Versión mayor | Última versión menor |
|---|---|
| PostgreSQL 14 | 12 de noviembre de 2026 |
| PostgreSQL 15 | 11 de noviembre de 2027 |
| PostgreSQL 16 | 9 de noviembre de 2028 |
| PostgreSQL 17 | 8 de noviembre de 2029 |
| PostgreSQL 18 | 14 de noviembre de 2030 |
Es una agenda a cuatro años vista, publicada, que casi nadie ha copiado a su propio calendario. Este mes pasa algo parecido por otro lado: lo mismo que le pasa este mes a Zabbix 7.4, aunque allí la mecánica es la de perder el soporte completo, no la de la última versión menor.
Dos caminos desde la misma caducidad
La misma caducidad produce dos cosas completamente distintas según dónde esté corriendo la base de datos.
Si está gestionada: la fecha se convierte en dinero
Los proveedores gestionados no te apagan la base de datos cuando la versión caduca. Te la dejan corriendo y te cobran por ello. En Amazon RDS se llama Extended Support y, según su propia documentación, «será un SKU y una línea separada en tu factura; es decir, pagarás el soporte extendido además de tus cargos de base de datos, almacenamiento y copias».
El ejemplo que publica AWS en su propia página de precios, para PostgreSQL 12 en la región de Ohio, es de 0,100 $ por vCPU y hora durante los dos primeros años y 0,200 $ a partir del tercero. La tarifa depende de la región y de la fecha, así que ese número no es universal; el mecanismo sí. Echando la cuenta sobre una instancia modesta de 4 vCPU: 0,400 $ la hora, 3.504 $ al año, y 7.008 $ cuando entra el tercer año. Encima de lo que ya pagas.
Para quien ya había negociado su presupuesto: «los descuentos de instancias reservadas no se aplican al Extended Support de Amazon RDS», aunque AWS añade a continuación que «tus condiciones de descuento personalizadas sí podrían aplicarse» y remite a tu equipo de cuenta. Traducido: el descuento por comprometerte a tres años no toca esta línea; si tienes condiciones negociadas aparte, eso hay que confirmarlo.
Matiz honesto, porque importa: las cifras de arriba son el ejemplo publicado para la versión 12 en una región concreta, y el calendario de RDS es suyo, no el de la comunidad. El soporte extendido arranca al día siguiente de que esa versión termine su soporte estándar en RDS, que no es necesariamente el 12 de noviembre. Si tienes la 14 en RDS, la fecha que te aplica hay que mirarla en su calendario, no en el de PostgreSQL.
Si es tuya: la fecha no se convierte en nada
En un servidor propio —una máquina virtual, un contenedor, un paquete de Debian— el 12 de noviembre no pasa absolutamente nada. No hay factura, no hay aviso, no hay correo del proveedor, no hay una casilla que se ponga en rojo. El proceso sigue escuchando en el 5432 y respondiendo igual de rápido. Lo único que ha cambiado es invisible: a partir de ese día, cuando aparezca un fallo de seguridad en esa rama, no va a haber parche.
La nube te cobra y, al cobrarte, te avisa. Tu propio servidor no te cobra, y precisamente por eso no te avisa. De los dos, el que está peor es el segundo, aunque sea el que parece gratis.
Y además esa versión no la elegiste tú
En la encuesta de desarrolladores de Stack Overflow de 2026, PostgreSQL es la base de datos más usada: un 57,9% de las 12.061 respuestas a esa pregunta, frente al 42,1% de SQLite y el 35,1% de MySQL. A efectos de mantenimiento cuenta otra cosa: una buena parte de esas instalaciones no las puso un administrador de bases de datos. Vinieron dentro de otra cosa.
Sitios donde, por experiencia, aparece un PostgreSQL que nadie instaló a propósito:
- ·Debajo de la herramienta de inventario de red. Nosotros llevamos NetBox como fuente de verdad, y NetBox se apoya en PostgreSQL.
- ·Debajo de la monitorización y de la plataforma de despliegue: Zabbix y GitLab pueden guardar su estado ahí, igual que buena parte del tejido de integración continua.
- ·Dentro de la aplicación de un proveedor que se instaló llave en mano y que nadie ha vuelto a abrir.
- ·En una línea
image: postgres:14de un fichero compose escrito hace tres años, que sigue desplegándose igual cada vez que alguien reconstruye el entorno.
En los cuatro casos la versión la decidió otro, hace años, y el reloj de los cinco años ya estaba corriendo entonces. Por eso la pregunta útil hoy no es «¿cuándo actualizo?», sino «¿cuántos PostgreSQL tengo y en qué versión está cada uno?». Si la respuesta tarda más de diez minutos, ese es el trabajo real, y no empieza el 12 de noviembre.
Cuándo pagar el soporte extendido es lo correcto
A veces lo correcto es pagar. Un salto de versión mayor en PostgreSQL no es un apt upgrade. Hay que pasar por pg_upgrade o por un volcado y restauración, revisar las extensiones (que van por su cuenta y a veces no tienen versión compatible todavía), comprobar que los planes de ejecución no se degradan, y tener ensayado el camino de vuelta. Eso no se hace en una tarde.
Si el salto cae encima del cierre del ejercicio, de una campaña o de otra migración que ya está en marcha, comprar un año de soporte extendido a conciencia es una decisión defendible: 3.504 $ son mucho más baratos que una restauración que nadie había ensayado. Lo que no es defendible es pagarlo sin haberlo decidido, descubrirlo tres meses después revisando la factura, y que la versión siga siendo la misma.
La migración es también el momento en que se revisan los permisos «provisionales» que se pusieron para hacer la copia o la réplica y que llevan años ahí. Ya contamos que el permiso de replicación de PostgreSQL nunca fue de solo lectura; un cambio de versión es buena ocasión para arreglarlo.
Lo que haríamos esta semana
- 1.Contarlos. Un
SHOW server_version;en cada instancia a la que sepas llegar, y una pasada por las imágenes de los contenedores que estén desplegados. El número que sale casi nunca es el que la gente esperaba. Y al lado de cada una, anota de dónde vino: del repositorio de la distribución, del repositorio oficial de PostgreSQL o de dentro de un producto. De eso depende quién te la actualiza y con qué calendario, que no tiene por qué ser el de la comunidad. - 2.Separar las que no son tuyas. Las que van dentro de una aplicación de proveedor no las actualizas tú: las actualiza él, y hay que preguntarle con qué versión del producto y en qué plazo. Esa respuesta por escrito vale más que el parche.
- 3.Mirar la factura antes de que te la manden. Si hay algo gestionado, buscar su calendario de soporte y ver qué día concreto empieza a correr el cargo. Es la única de las tres que tiene una fecha dura y un número.
Nada de esto es complicado. Es aburrido, que es distinto, y por eso se queda sin hacer hasta que la versión lleva dos años sin parches o hasta que alguien de administración pregunta qué es esa línea nueva. En everyWAN esto cae en datos y aplicaciones y, cuando la decisión es si actualizar o pagar, en consultoría: no somos resellers de ninguna de estas plataformas, así que la recomendación no nos cambia la factura.
Fuentes (verificadas el 1-nov-2026): política de versiones y fechas de última versión menor de las ramas 14 a 18 — postgresql.org/support/versioning. Mecánica y facturación del soporte extendido, incluida la frase sobre los descuentos de instancias reservadas — AWS Cloud Financial Management; tarifa de ejemplo (PostgreSQL 12, US East Ohio) — página de precios de Amazon RDS para PostgreSQL. Cuota de uso de PostgreSQL — encuesta de desarrolladores de Stack Overflow 2026. Qué es cálculo nuestro: los 3.504 $ y 7.008 $ anuales salen de multiplicar la tarifa publicada por 4 vCPU y 8.760 horas; cualquiera puede repetir la cuenta con su propio número de vCPU. Qué no afirmamos: no damos la fecha de fin de soporte estándar de PostgreSQL 14 en RDS ni en ningún otro gestionado, porque cada proveedor publica su propio calendario y hay que consultarlo; y la observación sobre dónde aparece PostgreSQL sin que nadie lo instalara es experiencia nuestra de campo, no un dato de la encuesta.
¿Cuántos PostgreSQL tienes, y en qué versión?
Si la respuesta tarda más de diez minutos, el problema no es la 14: es el inventario. Levantamos la lista, separamos lo que actualizas tú de lo que actualiza tu proveedor, y te decimos si en tu caso sale a cuenta saltar ahora o pagar un año. No somos resellers de ninguna de ellas, así que da igual lo que decidas.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN