Postgres 16 vs 17 vs 18: le vittorie che contano

Le tre versioni non si distinguono per un unico dato prestazionale complessivo. Ognuno corregge un punto specifico dell'architettura, con un pubblico ogni volta diverso: tabelle di grandi dimensioni per Postgres 17, storage ad alta latenza per Postgres 18. La tabella seguente riassume i fatti verificabili, tutti datati, prima di entrare nei dettagli di ciascun progetto.

Fonti: note di rilascio ufficiali del progetto PostgreSQL (postgresql.org), riferimenti incrociati con analisi pubblicate da Microsoft Tech Community e Crunchy Data dopo ogni versione principale. Accesso effettuato il 24 agosto 2026.

Prima di Postgres 17, VACUUM memorizzava l'elenco delle tuple morte da ripulire in un semplice array, dimensionato da maintenance_work_mem. Il problema non era la velocità di calcolo, ma la struttura stessa: questa tabella si attestava intorno a 1 GB, non importa quanto fosse configurato oltre. Su una tabella con più di 178 milioni di righe morte, VACUUM ha dovuto eseguire il loop in più passaggi, ciascuno rileggendo l'intero indice.

Postgres 17 sostituisce questo array con una struttura chiamata TidStore, un albero radice adattivo che comprime pesantemente lo spazio necessario per memorizzare gli identificatori di tupla. Le note di rilascio ufficiali del progetto indicano una riduzione della memoria utilizzata da VACUUM fino a 20 volte in alcuni casi, senza il soffitto artificiale associato alla vecchia struttura. Fonte: note di rilascio ufficiali di PostgreSQL 17, postgresql.org, 26 settembre 2024. Microsoft Tech Community e Crunchy Data hanno pubblicato ciascuno un'analisi tecnica di questa modifica subito dopo il rilascio. Entrambi confermano l'interesse concreto per tabelle di diverse centinaia di milioni di righe, con un elevato tasso di cancellazione o aggiornamento.

Questo progetto avvantaggia principalmente uno scenario specifico: una tabella di grandi dimensioni con un'elevata frequenza di eliminazione o aggiornamento. VACUUM in precedenza veniva eseguito in più passaggi a causa della mancanza di memoria disponibile. Su un tavolino, o con un carico prevalentemente di lettura, il guadagno rimane marginale, o addirittura invisibile.

Il secondo progetto Postgres 17 tocca un punto più discreto: il calcolo delle istantanee delle transazioni. Ogni query deve sapere quali altre transazioni sono in corso per applicare le regole di visibilità MVCC di Postgres. Su una macchina con un numero elevato di core e connessioni attive, questo calcolo ha generato contesa su una struttura interna condivisa. Questo è un collo di bottiglia documentato da molto tempo dai contributori del progetto.

Postgres 17 riduce questa contesa. L'effetto viene misurato principalmente su istanze ad alta concorrenza, con molte connessioni attive simultanee su hardware multi-core. Con un carico di concorrenza basso, la differenza con Postgres 16 rimane marginale: si tratta di un progetto di scalabilità, non di riduzione della latenza per richiesta isolata.

Questo guadagno non sostituisce un pool di connessioni, ne riduce semplicemente i costi interni. Se il numero di connessioni attive è già il tuo collo di bottiglia, la versione principale passa in secondo piano. La nostra guida all'ottimizzazione max_connections e il nostro Confronto delle modalità di transazione PgBouncer esplorano questo argomento in modo più dettagliato.

Postgres 18, rilasciato alla fine di settembre 2025, affronta un problema più strutturale. Fino ad allora, ogni lettura del disco Postgres bloccava il processo che lo richiedeva. Il nuovo sottosistema input-output asincrono (AIO) consente a un processo di avviare più letture in parallelo e continuare a lavorare mentre vengono completate, invece di attendere ciascuna in sequenza.

Il parametro io_method controlla questo comportamento: worker (processi dedicati all'I/O, predefinito) o io_uring su Linux, quando Postgres è stato compilato con questo supporto. Scansioni sequenziali, scansioni di heap bitmap e VACUUM sono i primi beneficiari, in particolare sullo storage ad alta latenza: dischi di rete, volumi cloud, piuttosto che NVMe locale.

PlanetScale, che offre un'offerta Postgres gestita, ha pubblicato i propri confronti Postgres 17 vs 18 incentrati su questa modifica I/O. Queste sono le loro misurazioni sulla propria infrastruttura, non cifre che abbiamo riprodotto qui in modo indipendente. Prendilo come un segnale che vale la pena testare l'argomento sul tuo carico effettivo, non come percentuale universale.

L'AIO generalizzato di Postgres 18 continua un progetto iniziato in Postgres 17, non un cambiamento isolato. La versione 17 aveva già introdotto l'interfaccia di streaming I/O, ma limitata ad ANALISI e scansioni sequenziali. Postgres 18 estende questa stessa logica a un ambito più ampio di operazioni, comprese le scansioni VACUUM e heap bitmap. Le due versioni quindi si leggono come una progressione, non come due scommesse separate su I/O.

Vale la pena monitorare altre tre modifiche a Postgres 18, anche se non riguardano direttamente le prestazioni grezze.

Lo skip scan sull'indice B-tree a più colonne consente a Postgres di utilizzare un indice composito anche quando la query non filtra sulla sua colonna principale. Prima di Postgres 18, questo scenario spesso richiedeva una scansione completa della tabella o la creazione di un ulteriore indice dedicato.

Le colonne virtuali generate (GENERATED ALWAYS AS (...) VIRTUAL) diventano il comportamento predefinito quando STORED non è specificato. Una colonna virtuale viene calcolata in lettura anziché essere scritta su disco, riducendo così la quantità scritta ogni volta che la riga di origine viene inserita o aggiornata.

Postgres 18 aggiunge infine il supporto per OAuth 2.0 dal lato dell'autenticazione (RFC 8628, flusso del dispositivo), insieme ai meccanismi esistenti come SCRAM, certificati o LDAP. Un punto rilevante per qualsiasi organizzazione che già centralizza le proprie identità tramite un provider OAuth/OIDC esterno.

In Aurabase, il database dei tenant attualmente viene eseguito in Postgres 16.15, non 17. Questo può essere verificato direttamente nel repository: l'immagine CNPG di riferimento (docker/Postgres.CNPG.Dockerfile) inizia da ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm, bloccata da digest, la stessa versione principale del livello condiviso (docker/Postgres.Dockerfile). Verificato il 24 agosto 2026.

Il codice documenta anche il perché. Un commento di correzione in k8s_tenant.rs spiega che un fallback precedente puntava erroneamente a postgresql:17.2. Il motivo addotto all'epoca, ovvero che l'immagine standard non avrebbe incluso pgvettoriale, si è rivelato falso dopo la verifica. Entrambe le immagini hanno pgvector: 0.8.0 su 17.2, 0.8.5 su 16-standard-bookworm misurato sul cluster della flotta.

Il rischio reale, documentato nel commento stesso, è altrove: CloudNativePG vieta qualsiasi downgrade di versione principale una volta creato un Cluster. Una flotta rifornita per errore in Postgres 17 sarebbe irreversibile, mentre tutto ciò che è stato convalidato end-to-end in Aurabase era in Postgres 16.

// Versione principale mantenuta se TENANT_POSTGRES_IMAGE non è definito
let repli = "ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm";

tracing::warn!(
    image = repli,
    "TENANT_POSTGRES_IMAGE non défini : repli sur la version validée."
);

Questo non è un giudizio su Postgres 17 in quanto tale. È una politica di prudenza operativa: non passare da un parco di produzione a una versione principale finché non è seguita la convalida end-to-end. Lo stesso ragionamento vale per qualsiasi team che gestisce Postgres tramite CloudNativePG o un operatore Kubernetes equivalente. La domanda non è solo il miglioramento delle prestazioni atteso, ma anche il percorso di ritorno se qualcosa va storto.

Dovresti migrare a Postgres 17 o 18 adesso?

Tre criteri permettono di decidere senza attendere una cifra universale. Innanzitutto, la dimensione e il tasso di mutazione delle tabelle più grandi: se VACUUM è già in esecuzione in più passaggi, il cantiere di memoria Postgres 17 si applica direttamente al tuo caso. Poi, il tuo spazio di archiviazione: su un SSD locale a bassa latenza, l'I/O asincrono di Postgres 18 fornisce meno che su un volume di rete. Infine, torniamo indietro: su un operatore che vieta downgrade importanti, testare prima su un ambiente usa e getta non è una precauzione facoltativa.

Concretamente, la stessa regola si applica a qualsiasi flotta gestita da un operatore Kubernetes. Per prima cosa esegui il provisioning di un cluster di test nella versione di destinazione, quindi riproduci su di esso un carico rappresentativo della tua produzione. Tocca il cluster effettivo solo dopo che questo test è stato convalidato end-to-end, non limitarti a leggere le note di rilascio. Se la tua decisione riguarda anche la scelta tra base dedicata e base condivisa per assorbire questo tipo di cambiamento, il nostro articolo base dedicata vs base condivisa esplora questo angolo.

La scelta tra Postgres 16, 17 e 18 non riguarda solo quale versione sia “più veloce”. Postgres 17 risolve un vero problema strutturale di VACUUM su tabelle di grandi dimensioni e riduce la contesa ad alta concorrenza. Postgres 18 va oltre con l'I/O asincrono, una modifica dell'architettura che richiede test sul carico e sullo storage effettivi prima di essere generalizzata.

Il criterio più spesso dimenticato non è la prestazione, bensì la reversibilità. Su un operatore come CloudNativePG, un aggiornamento importante della versione non viene annullato a posteriori. Prima di convertire una flotta di produzione, la vera questione non è solo il guadagno atteso, ma anche il percorso di ritorno in caso di fallimento del test. Se ti stai preparando per questo aggiornamento di versione, la nostra lista di controllo per l'ottimizzazione di Postgres in produzione descrive in dettaglio le impostazioni da riconvalidare dopo una modifica importante della versione.