Mancano due mesi alla fine del supporto di PostgreSQL 14: fate pratica con il ripristino prima dell'aggiornamento
Alcuni team hanno pianificato la data dell'aggiornamento della versione del database, ma non sanno quanto tempo servirebbe per tornare indietro in caso di fallimento. Se gestite PostgreSQL 14, il risultato tangibile di cui avete bisogno adesso non è semplicemente il nome di una nuova versione, bensì un piano di transizione con ripristino garantito. Al 14 settembre 2026, mancano circa due mesi alla data di fine del supporto ufficiale.
Fatti accertati: il supporto della community e il contratto di hosting sono cose diverse
La politica ufficiale sulle versioni di PostgreSQL prevede 5 anni di supporto per le major release, indicando il 12 novembre 2026 come data del rilascio finale per la versione 14. Questa è la tabella di marcia del supporto della community. Le finestre di aggiornamento dei servizi gestiti, il supporto esteso separato e le relative tariffe devono essere verificati autonomamente nella documentazione e nei contratti del rispettivo fornitore.
È inoltre necessario distinguere tra aggiornamenti minori all'interno della stessa major release e major upgrade. L'applicazione dell'ultima patch release di PostgreSQL 14 non sostituisce la migrazione alla versione 15 o superiore. Al contrario, non è opportuno continuare a rimandare l'applicazione delle correzioni necessarie sulla versione attuale solo perché si ha in programma un passaggio di major version.
Primo deliverable: l'elenco delle dipendenze prima della dimensione dei dati
Da qui in avanti non si tratta della policy di supporto ufficiale in sé, ma di suggerimenti operativi pratici. Innanzitutto, riassumete in un unico documento le versioni dei DB per ciascun servizio, i moduli di estensione con le relative versioni, i driver di connessione, i job batch, le posizioni di archiviazione dei backup e la configurazione della replica. Non scegliete la versione di destinazione solo perché è la più recente: verificate contestualmente l'effettivo ambiente di hosting e il supporto alle estensioni utilizzate.
Ipotizzare che l'operazione sarà rapida solo perché il database è piccolo non è sufficiente. Se le estensioni o le query utilizzate in percorsi critici per il business — come la prima query dopo il login o l'aggiornamento dello stato dei pagamenti — subiscono variazioni, la migrazione può fallire anche se la copia dei dati richiede poco tempo. Lo scopo di questo elenco è individuare le dipendenze prive di un responsabile.
Secondo deliverable: l'esito del ripristino anziché il messaggio di backup completato
Ripristinate un backup recente in un ambiente isolato ed eseguite i flussi rappresentativi di lettura e scrittura dell'applicazione. In questa esercitazione, verificate prima le destinazioni di connessione per evitare di inviare scritture al DB di produzione. Le copie ripristinate contenenti dati reali devono essere gestite entro i perimetri di controllo degli accessi già esistenti.
Separare l'ora di inizio del backup, l'ora di completamento del ripristino e l'ora di completamento della verifica evita di confondere il tempo necessario per recuperare i file con il tempo in cui il servizio torna effettivamente disponibile in scrittura. Più che validare un piccolo campione artificialmente rapido, misurate i tempi con una copia di dimensioni vicine a quelle di produzione, registrando anche i vincoli di costo e di spazio su disco.
Il superamento dei controlli di pg_upgrade non sostituisce la verifica del servizio
La documentazione ufficiale di pg_upgrade spiega che con l'opzione --check è possibile eseguire una verifica di compatibilità prima dell'aggiornamento vero e proprio. La compatibilità dei moduli esterni deve essere verificata separatamente e sono necessarie anche le librerie condivise adatte al nuovo server. Non interpretate il successo del comando di verifica come la conferma che tutte le query e le prestazioni dell'applicazione siano già convalidate.
In particolare, la modalità --link presenta il vincolo che, una volta avviato il nuovo cluster, il vecchio cluster non può più essere utilizzato così com'era. Scegliere questo metodo basandosi esclusivamente sulla velocità potrebbe far svanire il percorso di rollback previsto. È fondamentale provare la procedura nelle stesse condizioni della migrazione reale e definire chiaramente il momento a partire dal quale sarà necessario un ripristino da backup per tornare indietro.
Criteri da stabilire prima di riprendere le scritture
Definite in anticipo i criteri di successo per evitare di dover improvvisare accordi il giorno della transizione. Ad esempio, è possibile assegnare ai rispettivi responsabili il completamento delle letture e scritture delle API critiche, la ripresa dei processi batch senza doppie elaborazioni, la corrispondenza dei conteggi di business nelle tabelle principali e la verifica dello stato di replica. Non si tratta di imporre gli stessi valori di soglia a ogni servizio, bensì di un esempio metodologico.
Se si inizia a scrivere sul nuovo database e successivamente si è costretti a ripristinare il backup precedente, si pone anche il problema di come preservare le modifiche avvenute nel frattempo. La semplice procedura di riaccensione del vecchio server non coincide affatto con un ripristino privo di perdite di dati. L'intervallo di disservizio e il margine di perdita di dati accettabili devono essere concordati dai responsabili del servizio.
Cosa fare questa settimana e le possibili obiezioni
Se risulta difficile migrare tutti i database in una volta sola, misurate i tempi di ripristino, verifica e rollback partendo dal singolo servizio con minori dipendenze, utilizzando poi questi risultati come base per la pianificazione degli altri servizi. Raccogliere in un unico documento i responsabili, le date candidate per la migrazione e i criteri di interruzione in caso di verifica fallita trasforma un progetto fatto di sole scadenze in un piano operativo realmente eseguibile.
L'obiezione secondo cui lo sviluppo del prodotto avrebbe la priorità immediata è comprensibile. Tuttavia, rimanere all'oscuro delle procedure di ripristino fino all'ultimo riduce le finestre utili per effettuare le necessarie verifiche. Questo articolo non promuove i miglioramenti prestazionali di una versione specifica né esprime la posizione dell'intera community: è una proposta operativa focalizzata sulla preparazione alla gestione dei fallimenti di transizione, piuttosto che sulla fretta di adottare le funzionalità più recenti.