Postgres 16 versus 17 versus 18: winst die er toe doet

De drie versies onderscheiden zich niet door één algemeen prestatiecijfer. Elk corrigeert een specifiek punt van de architectuur, met elke keer een ander publiek: grote tabellen voor Postgres 17, opslag met hoge latentie voor Postgres 18. De onderstaande tabel vat de verifieerbare feiten samen, allemaal gedateerd, voordat we op de details van elk project ingaan.

Bronnen: officiële release-opmerkingen van het PostgreSQL-project (postgresql.org), waarnaar wordt verwezen met analyses die na elke grote release zijn gepubliceerd door Microsoft Tech Community en Crunchy Data. Betreden op 24 augustus 2026.

Vóór Postgres 17 bewaarde VACUUM de lijst met dode tupels die moesten worden opgeschoond in een eenvoudige array, met een grootte van maintenance_work_mem. Het probleem was niet de snelheid van de berekening, maar de structuur zelf: deze tabel bleef rond de 1 GB hangen, ongeacht hoeveel er verder werd geconfigureerd. Op een tafel met meer dan ongeveer 178 miljoen dode rijen moest VACUUM meerdere passages herhalen, waarbij elke keer de volledige indexen opnieuw werden gelezen.

Postgres 17 vervangt deze array door een structuur genaamd TidStore, een adaptieve radixboom die de ruimte die nodig is om tuple-identifiers op te slaan, zwaar comprimeert. De officiële release-opmerkingen van het project duiden op een vermindering van het geheugen dat door VACUUM wordt gebruikt, tot wel 20 keer in sommige gevallen, zonder het kunstmatige plafond dat bij de oude structuur hoort. Bron: officiële releaseopmerkingen van PostgreSQL 17, postgresql.org, 26 september 2024. Microsoft Tech Community en Crunchy Data publiceerden kort na de release elk een technische analyse van deze wijziging. Beide bevestigen de concrete interesse voor tabellen van enkele honderden miljoenen rijen, met een hoog verwijderings- of updatepercentage.

Dit project profiteert vooral van een specifiek scenario: een grote tabel met een hoge verwijderings- of updatesnelheid. VACUUM draaide voorheen meerdere malen vanwege een gebrek aan beschikbaar geheugen. Op een kleine tafel of bij een overwegend leesbelasting blijft de winst marginaal of zelfs onzichtbaar.

Het tweede Postgres 17-project raakt een discreter punt aan: de berekening van transactiemomentopnamen. Elke zoekopdracht moet weten welke andere transacties worden uitgevoerd om de MVCC-zichtbaarheidsregels van Postgres af te dwingen. Op een machine met een groot aantal cores en actieve verbindingen zorgde deze berekening voor discussie over een gedeelde interne structuur. Dit is een knelpunt dat al lange tijd wordt gedocumenteerd door projectcontribuanten.

Postgres 17 reduceert deze bewering. Het effect wordt vooral gemeten bij instanties met hoge gelijktijdigheid, met veel gelijktijdige actieve verbindingen op multi-core hardware. Bij een lage gelijktijdigheidsbelasting blijft het verschil met Postgres 16 marginaal: het is een schaalbaarheidsproject, geen vermindering van de latentie per geïsoleerd verzoek.

Deze winst vervangt geen verbindingspooler, maar verlaagt eenvoudigweg de interne kosten. Als het aantal actieve verbindingen al uw knelpunt is, komt de hoofdversie op de achtergrond. Onze max_connections afstemmingsgids en onze PgBouncer-transactiemodusvergelijking onderzoeken dit onderwerp in meer detail.

Postgres 18, uitgebracht eind september 2025, pakt een meer structureel probleem aan. Tot dan toe blokkeerde elke gelezen Postgres-schijf het proces dat erom vroeg. Dankzij het nieuwe asynchrone input-output (AIO)-subsysteem kan een proces meerdere leesbewerkingen parallel initiëren en blijven werken terwijl ze zijn voltooid, in plaats van op elkaar te wachten.

De parameter io_method regelt dit gedrag: worker (processen speciaal voor I/O, standaard) of io_uring op Linux, toen Postgres met deze ondersteuning werd gecompileerd. Sequentiële scans, bitmap-heap-scans en VACUUM zijn de eerste begunstigden, vooral bij opslag met hoge latentie: netwerkschijven, cloudvolumes, in plaats van lokale NVMe.

PlanetScale, dat een beheerd Postgres-aanbod aanbiedt, heeft zijn eigen Postgres 17 versus 18-vergelijkingen gepubliceerd, gericht op deze I/O-verandering. Dit zijn hun metingen op hun eigen infrastructuur, geen cijfers die we hier onafhankelijk hebben weergegeven. Beschouw het als een signaal dat het onderwerp de moeite waard is om te testen op basis van uw werkelijke belasting, en niet als een universeel percentage.

De algemene AIO van Postgres 18 zet een project voort dat in Postgres 17 is gestart en is geen geïsoleerde verandering. Versie 17 had de streaming I/O-interface al geïntroduceerd, maar beperkt tot ANALYSE en sequentiële scans. Postgres 18 breidt dezelfde logica uit naar een bredere reikwijdte van bewerkingen, inclusief VACUUM- en bitmap-heap-scans. De twee versies lezen daarom als een progressie, niet als twee afzonderlijke weddenschappen op I/O.

Drie andere Postgres 18-wijzigingen zijn de moeite van het monitoren waard, ook al hebben ze niet direct betrekking op de ruwe prestaties.

Met de skip-scan op een B-tree-index met meerdere kolommen kan Postgres een samengestelde index gebruiken, zelfs als de query niet op de hoofdkolom filtert. Vóór Postgres 18 vereiste dit scenario vaak een volledige scan van de tabel, of het maken van een extra speciale index.

De door gegenereerde virtuele kolommen (GENERATED ALWAYS AS (...) VIRTUAL) worden het standaardgedrag wanneer STORED niet is opgegeven. Een virtuele kolom wordt berekend bij het lezen in plaats van bij het schrijven naar schijf, waardoor er minder wordt geschreven telkens wanneer de bronrij wordt ingevoegd of bijgewerkt.

Postgres 18 voegt eindelijk ondersteuning toe voor OAuth 2.0 aan de authenticatiekant (RFC 8628, device flow), naast bestaande mechanismen zoals SCRAM, certificaten of LDAP. Een relevant punt voor elke organisatie die haar identiteiten al centraliseert via een externe OAuth/OIDC-provider.

Bij Aurabase draait de tenantdatabase momenteel in Postgres 16.15, en niet in 17. Dit kan rechtstreeks in de repository worden geverifieerd: de referentie-CNPG-afbeelding (docker/Postgres.CNPG.Dockerfile) begint vanaf ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm, vastgezet door digest, dezelfde hoofdversie als de gedeelde laag (docker/Postgres.Dockerfile). Geverifieerd op 24 augustus 2026.

De code documenteert ook waarom. Een correctiecommentaar in k8s_tenant.rs legt uit dat een eerdere terugval ten onrechte naar postgresql:17.2verwees. De destijds opgegeven reden, dat de standaardafbeelding geen pgvector zou bevatten, bleek bij verificatie niet waar te zijn. Beide afbeeldingen hebben pgvector: 0.8.0 op 17.2, 0.8.5 op 16-standaard-boekenwurm gemeten op de vlootcluster.

Het echte risico, gedocumenteerd in de opmerking zelf, ligt elders: CloudNativePG verbiedt elke grote versiedowngrade zodra een cluster is gemaakt. Een vloot die per ongeluk werd bevoorraad in Postgres 17 zou onomkeerbaar zijn, terwijl alles wat bij Aurabase end-to-end werd gevalideerd, zich in Postgres 16 bevond.

// De hoofdversie blijft behouden als TENANT_POSTGRES_IMAGE niet is gedefinieerd
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."
);

Dit is geen oordeel over Postgres 17 als zodanig. Het is een beleid van operationele voorzichtigheid: schakel een productievloot niet over naar een hoofdversie totdat end-to-end validatie heeft plaatsgevonden. Dezelfde redenering geldt voor elk team dat Postgres beheert via CloudNativePG of een gelijkwaardige Kubernetes-operator. De vraag is niet alleen de verwachte prestatiewinst, maar ook de weg terug als er iets misgaat.

Moet u nu naar Postgres 17 of 18 migreren?

Drie criteria maken het mogelijk om te beslissen zonder te wachten op een universeel cijfer. Ten eerste de grootte en mutatiesnelheid van uw grootste tabellen: als VACUUM al in meerdere passages draait, is de Postgres 17-geheugenwerksite rechtstreeks op uw geval van toepassing. Dan uw opslag: op een lokale SSD met lage latentie biedt de asynchrone I/O van Postgres 18 minder dan op een netwerkvolume. Eindelijk de weg terug: bij een operator die grote downgrades verbiedt, is het eerst testen op een wegwerpomgeving geen optionele voorzorgsmaatregel.

Concreet geldt dezelfde regel voor elke vloot die wordt beheerd door een Kubernetes-operator. Richt eerst een testcluster in de doelrelease in en speel vervolgens daarop een lading af die representatief is voor uw productie. Raak het daadwerkelijke cluster pas aan nadat deze test end-to-end is gevalideerd en lees niet alleen de release-opmerkingen. Als uw beslissing ook betrekking heeft op de keuze tussen een dedicated basis en een gedeelde basis om dit soort veranderingen op te vangen, onderzoekt ons artikel dedicated versus gedeelde basis deze invalshoek.

De keuze tussen Postgres 16, 17 en 18 gaat niet alleen over welke versie “het snelst” is. Postgres 17 lost een echt structureel VACUUM-probleem op grote tafels op en vermindert de conflicten bij hoge gelijktijdigheid. Postgres 18 gaat nog een stap verder met asynchrone I/O, een architectonische verandering die tests op uw daadwerkelijke belasting en opslag vereist voordat deze kan worden gegeneraliseerd.

Het vaakst vergeten criterium is niet de prestatie, maar de omkeerbaarheid. Bij een operator als CloudNativePG wordt een grote versie-upgrade achteraf niet ongedaan gemaakt. Voordat een productievloot wordt overgeschakeld, is de echte vraag niet alleen de verwachte winst, maar ook het retourtraject als de test mislukt. Als u zich voorbereidt op deze versie-upgrade, geeft onze Postgres-afstemmingschecklist in productie details over de instellingen die opnieuw moeten worden gevalideerd na een grote versiewijziging.