Op 25 september 2025 heeft de PostgreSQL Global Development Group PostgreSQL 18 uitgebracht. Het is de jaarlijkse major release van de open-source database en de aankondiging plaatst één verandering nadrukkelijk voorop: een nieuw subsysteem voor asynchrone I/O. Daaromheen zitten verbeteringen voor het query-plannen, voor major-versie-upgrades, voor ontwikkelaars (virtuele gegenereerde kolommen, uuidv7(), RETURNING met oude én nieuwe waarden) en voor authenticatie (OAuth, afbouw van md5-wachtwoorden).
Dit artikel zet de release op een rij aan de hand van de officiële aankondiging. Het is geen upgradehandleiding; het beschrijft wat er nieuw is en waar dat in de praktijk raakt aan beheer en ontwikkeling.
Asynchrone I/O als kern van de release
PostgreSQL las tot en met versie 17 blokken van schijf in principe één voor één: een verzoek uitzetten, wachten, het volgende verzoek uitzetten. Het nieuwe AIO-subsysteem (asynchronous I/O) laat de database meerdere I/O-verzoeken tegelijk uitstaan hebben in plaats van ze na elkaar af te handelen. Volgens de aankondiging levert dat in bepaalde scenario's tot 3× snellere leesprestaties op.
De asynchrone afhandeling wordt in deze versie gebruikt voor sequentiële scans, bitmap heap scans en vacuum. Welk mechanisme daarvoor wordt ingezet, bepaalt de nieuwe instelling io_method:
# postgresql.conf
io_method = worker # standaard: aparte I/O-workerprocessen
# io_method = io_uring # Linux, gebruikt de io_uring-interface van de kernel
# io_method = sync # gedrag zoals in eerdere versies
De drie waarden zijn worker, io_uring en sync. De laatste optie geeft het oude, synchrone gedrag terug en is daarmee een terugvalmogelijkheid als de nieuwe aanpak op een specifiek platform niet het gewenste resultaat geeft.
Waarom dit een grote stap is
Het I/O-pad van PostgreSQL is decennialang synchroon geweest. Dat het nu asynchroon kan, is minder een losse feature dan een architectuurwijziging waar volgende releases verder op kunnen bouwen. De 3×-winst geldt voor de genoemde scenario's, niet als algemeen getal voor elke werklast.
Query-prestaties en indexen
Naast het I/O-werk noemt de aankondiging een reeks verbeteringen aan planner en indexgebruik:
- Skip scan op multikolom-B-tree-indexen. Een index op
(a, b)was tot nu toe weinig nuttig voor een query die alleen opbfiltert. PostgreSQL 18 kan zulke indexen wel gebruiken bij queries die de=-voorwaarde op de voorafgaande kolom(men) weglaten. OR-voorwaarden inWHEREkunnen nu vaker via indexen worden afgehandeld.- Hash joins zijn sneller en merge joins kunnen incrementele sorteringen gebruiken.
- GIN-indexen kunnen parallel worden opgebouwd, wat vooral bij full-text-search- en JSONB-indexen tijd scheelt.
- Op ARM gebruikt
popcount(de basis vanbit_count) nu NEON- en SVE-instructies.
Sneller op snelheid na een major upgrade
Een terugkerend probleem bij major-versie-upgrades was dat de planner-statistieken niet meegingen. Na pg_upgrade moest een cluster eerst opnieuw geanalyseerd worden voordat queryplannen weer klopten. PostgreSQL 18 bewaart de planner-statistieken door de upgrade heen, zodat een geüpgraded cluster sneller op het verwachte prestatieniveau zit.
pg_upgrade zelf kreeg ook aandacht: snellere verwerking van clusters met heel veel objecten, parallelle controles via --jobs, en een nieuwe --swap-optie die datadirectory's verwisselt in plaats van bestanden te kopiëren, klonen of linken.
Voor ontwikkelaars: kolommen, UUID's en RETURNING
Virtuele gegenereerde kolommen. Een gegenereerde kolom kan nu virtueel zijn: de waarde wordt berekend op het moment van uitvragen in plaats van opgeslagen. Virtueel is in PostgreSQL 18 de standaardoptie. Opgeslagen gegenereerde kolommen ondersteunen daarnaast nu logische replicatie.
RETURNING met OLD en NEW. Bij INSERT, UPDATE, DELETE en MERGE kan de RETURNING-clausule zowel de vorige als de nieuwe waarde van een rij teruggeven. Dat maakt auditlogica en "wat is er precies veranderd"-vragen eenvoudiger zonder aparte selectie vooraf.
uuidv7(). De nieuwe functie genereert tijdgeordende, willekeurige UUID's. Omdat opeenvolgende waarden oplopen, gedragen ze zich beter in indexen en caches dan volledig willekeurige UUID's. Als tegenhanger is uuidv4() toegevoegd als alias voor gen_random_uuid().
Temporele constraints. PRIMARY KEY- en UNIQUE-constraints ondersteunen WITHOUT OVERLAPS, en FOREIGN KEY-constraints kennen een PERIOD-clausule. Daarmee kan de database zelf afdwingen dat bijvoorbeeld twee geldigheidsperiodes van dezelfde sleutel elkaar niet overlappen, een controle die tot nu toe in applicatiecode of triggers moest zitten.
Verder is CREATE FOREIGN TABLE ... LIKE toegevoegd om een vreemde tabel te definiëren op basis van een bestaande tabelstructuur.
Tekst en collaties
De release voegt de collatie PG_UNICODE_FAST toe met volledige Unicode-semantiek, verbetert upper en lower, en introduceert de functie casefold voor hoofdletterongevoelige vergelijkingen. LIKE werkt nu ook met niet-deterministische collaties.
Een wijziging met gevolgen voor beheer: full-text search gebruikt nu de standaard-collatieprovider van het cluster in plaats van altijd libc. De aankondiging waarschuwt dat FTS- en pg_trgm-indexen na pg_upgrade mogelijk opnieuw moeten worden opgebouwd.
Authenticatie en beveiliging
- OAuth 2.0. Een nieuw
oauth-authenticatiemechanisme maakt koppeling met single-sign-on-systemen mogelijk. De concrete validatie loopt via extensies. - md5 afgebouwd. Wachtwoordauthenticatie met
md5is in PostgreSQL 18 verouderd (deprecated) en wordt in een toekomstige release verwijderd. De aanbevolen vervanging is SCRAM. SCRAM-passthrough wordt nu ondersteund voorpostgres_fdwendblink. - TLS. Een nieuwe parameter
ssl_tls13_ciphersstelt de TLS 1.3-ciphersuites aan serverzijde in; FIPS-modus wordt gevalideerd. - pgcrypto ondersteunt SHA-2 voor wachtwoordhashing.
Twee upgradepunten om vooraf te kennen
Ten eerste zet initdb paginachecksums nu standaard aan. Bij een upgrade vanaf een cluster zonder checksums is de optie --no-data-checksums bij pg_upgrade nodig, of moet het doelcluster passend worden aangemaakt. Ten tweede geldt de md5-deprecatie: omgevingen die nog md5 in pg_hba.conf gebruiken, hebben nu een concrete aanleiding om naar SCRAM over te stappen.
Replicatie, vacuum en observability
Bij logische replicatie worden schrijfconflicten nu gerapporteerd in het logboek en in de view pg_stat_subscription_stats. CREATE SUBSCRIPTION gebruikt standaard parallelle streaming bij het toepassen van transacties, en pg_createsubscriber kreeg een --all-optie om in één keer logische replica's van alle databases in een instantie te maken. Inactieve replicatieslots kunnen automatisch worden opgeruimd, zodat ze geen onbeperkte hoeveelheid WAL vasthouden.
Vacuum bevriest pagina's proactiever tijdens reguliere runs, wat de noodzaak van agressieve vacuums vermindert. EXPLAIN toont automatisch het aantal bufferbenaderingen, EXPLAIN ANALYZE laat het aantal index-lookups zien, en EXPLAIN ANALYZE VERBOSE bevat CPU-, WAL- en gemiddelde leesstatistieken. De view pg_stat_all_tables is uitgebreid met tijdsduur van vacuum-operaties en met I/O- en WAL-statistieken per verbinding.
Wire protocol 3.2
Een detail met een lange geschiedenis: PostgreSQL 18 introduceert versie 3.2 van het wire protocol, de eerste nieuwe versie sinds 3.0 in PostgreSQL 7.4 uit 2003. libpq blijft standaard versie 3.0 gebruiken; clients kunnen ondersteuning voor de nieuwe versie toevoegen. Voor bestaande applicaties verandert er daardoor niets zonder expliciete actie.
Samengevat
PostgreSQL 18 is een release met een duidelijke hoofdlijn (asynchrone I/O) en een lange staart van kleinere verbeteringen die in dagelijks gebruik zichtbaar worden: indexen die vaker bruikbaar zijn, upgrades die hun statistieken behouden, uuidv7() als betere standaardsleutel, en een authenticatielaag die richting OAuth en SCRAM beweegt. De punten om vooraf te toetsen zijn de standaard-checksums bij initdb, mogelijke herindexatie van FTS- en pg_trgm-indexen en de md5-deprecatie.
