PostgreSQL 14 caduca el 12 de novembre i al teu servidor no l'hi dirà ningú

El 12 de novembre, PostgreSQL 14 rep la seva última versió menor i la branca es queda sense pedaços de seguretat. El que ve després es bifurca segons on sigui aquella base de dades: a uns els arribarà en forma de càrrec nou a la factura, i a d'altres no els arribarà per cap banda.

La política és pública, i fa anys que està escrita

PostgreSQL manté cada versió major cinc anys des de la seva publicació inicial. Després, en paraules literals de la seva política: «es publicarà una última versió menor i el programari quedarà llavors sense suport». No hi ha zona grisa ni suport estès del projecte: hi ha una data i, a partir d'aquí, ja no surten pedaços de seguretat per a aquesta branca.

En aquesta mateixa taula ja hi són posades les quatre dates següents:

És una agenda a quatre anys vista, publicada, que gairebé ningú no ha copiat al seu propi calendari. Aquest mes passa una cosa semblant per un altre costat: el mateix que li passa aquest mes a Zabbix 7.4, encara que allà la mecànica és la de perdre el suport complet, no la de l'última versió menor.

Dos camins des de la mateixa caducitat

La mateixa caducitat produeix dues coses completament diferents segons on estigui corrent la base de dades.

Si està gestionada: la data es converteix en diners

Els proveïdors gestionats no t'apaguen la base de dades quan la versió caduca. Te la deixen funcionant i te la cobren. A Amazon RDS se'n diu Extended Support i, segons la seva pròpia documentació, «serà un SKU i una línia separada a la teva factura; és a dir, pagaràs el suport estès a més dels teus càrrecs de base de dades, emmagatzematge i còpies».

L'exemple que publica AWS a la seva pròpia pàgina de preus, per a PostgreSQL 12 a la regió d'Ohio, és de 0,100 $ per vCPU i hora durant els dos primers anys i 0,200 $ a partir del tercer. La tarifa depèn de la regió i de la data, així que aquest número no és universal; el mecanisme sí. Fent el compte sobre una instància modesta de 4 vCPU: 0,400 $ l'hora, 3.504 $ l'any, i 7.008 $ quan entra el tercer any. A sobre del que ja pagues.

Matís honest, perquè importa: les xifres de dalt són l'exemple publicat per a la versió 12 en una regió concreta, i el calendari de RDS és seu, no el de la comunitat. El suport estès arrenca l'endemà que aquella versió acabi el seu suport estàndard a RDS, que no ha de ser necessàriament el 12 de novembre. Si tens la 14 a RDS, la data que t'aplica s'ha de mirar al seu calendari, no al de PostgreSQL.

Si és teva: la data no es converteix en res

En un servidor propi —una màquina virtual, un contenidor, un paquet de Debian— el 12 de novembre no passa absolutament res. No hi ha factura, no hi ha avís, no hi ha correu del proveïdor, no hi ha cap casella que es posi en vermell. El procés continua escoltant al 5432 i responent igual de ràpid. L'única cosa que ha canviat és invisible: a partir d'aquell dia, quan aparegui una vulnerabilitat en aquesta branca, no hi haurà pedaç.

El núvol et cobra i, en cobrar-te, t'avisa. El teu propi servidor no et cobra, i precisament per això no t'avisa. Dels dos, el que està pitjor és el segon, encara que sigui el que sembla gratis.

I a més aquella versió no la vas triar tu

A l'enquesta de desenvolupadors de Stack Overflow del 2026, PostgreSQL és la base de dades més usada: un 57,9% de les 12.061 respostes a aquesta pregunta, davant del 42,1% de SQLite i el 35,1% de MySQL. A efectes de manteniment compta una altra cosa: bona part d'aquestes instal·lacions no les va posar un administrador de bases de dades. Van venir dins d'una altra cosa.

En els quatre casos la versió la va decidir un altre, fa anys, i el rellotge dels cinc anys ja corria llavors. Per això la pregunta útil avui no és «quan actualitzo?», sinó «quants PostgreSQL tinc i en quina versió està cadascun?». Si la resposta triga més de deu minuts, aquesta és la feina real, i no comença el 12 de novembre.

Quan pagar el suport estès és el correcte

De vegades el correcte és pagar. Un salt de versió major a PostgreSQL no és un apt upgrade. Cal passar per pg_upgrade o per un bolcat i restauració, revisar les extensions (que van pel seu compte i de vegades encara no tenen versió compatible), comprovar que els plans d'execució no es degraden, i tenir assajat el camí de tornada. Això no es fa en una tarda.

Si el salt cau damunt del tancament de l'exercici, d'una campanya o d'una altra migració que ja està en marxa, comprar un any de suport estès a consciència és una decisió defensable: 3.504 $ són molt més barats que una restauració que ningú no havia assajat. El que no és defensable és pagar-lo sense haver-ho decidit, descobrir-ho tres mesos després revisant la factura, i que la versió continuï sent la mateixa.

La migració és també el moment en què es revisen els permisos «provisionals» que es van posar per fer la còpia o la rèplica i que fa anys que hi són. Ja vam explicar que el permís de replicació de PostgreSQL mai no va ser de només lectura; un canvi de versió és bona ocasió per arreglar-ho.

El que faríem aquesta setmana

Res d'això no és complicat. És avorrit, que és diferent, i per això es queda sense fer fins que la versió fa dos anys que no rep pedaços o fins que algú d'administració pregunta què és aquella línia nova. A everyWAN això cau a dades i aplicacions i, quan la decisió és si actualitzar o pagar, a consultoria: no som resellers de cap d'aquestes plataformes, així que la recomanació no ens canvia la factura.

Fonts (verificades l'1-nov-2026): política de versions i dates d'última versió menor de les branques 14 a 18 — postgresql.org/support/versioning. Mecànica i facturació del suport estès, inclosa la frase sobre els descomptes d'instàncies reservades — AWS Cloud Financial Management; tarifa d'exemple (PostgreSQL 12, US East Ohio) — pàgina de preus d'Amazon RDS per a PostgreSQL. Quota d'ús de PostgreSQL — enquesta de desenvolupadors de Stack Overflow 2026. Què és càlcul nostre: els 3.504 $ i 7.008 $ anuals surten de multiplicar la tarifa publicada per 4 vCPU i 8.760 hores; qualsevol pot repetir el compte amb el seu propi nombre de vCPU. Què no afirmem: no donem la data de fi de suport estàndard de PostgreSQL 14 a RDS ni a cap altre gestionat, perquè cada proveïdor publica el seu propi calendari i cal consultar-lo; i l'observació sobre on apareix PostgreSQL sense que ningú l'instal·lés és experiència nostra de camp, no una dada de l'enquesta.