A staging copy of one database, restored over the weekend onto PostgreSQL 18 beta. GA is expected in autumn. Two things I wanted to touch: asynchronous I/O and the built-in uuidv7().
Start with uuidv7, because it is about a mistake many of us already made, me included. Random UUIDv4 primary keys scatter inserts across the whole index. Every insert lands on a random page, the working set is the entire index, buffers churn. UUIDv7 is time-ordered: new rows go to the same few pages, like a sequence, but still globally unique.
SELECT uuidv7();
-- 01980a9c-... the prefix is a timestamp
On my copy I replayed one day of inserts into a v4-keyed table and into a v7-keyed clone. The v7 run was clearly faster and wrote visibly less WAL. Exact numbers are from my hardware, so I will not quote them. The direction matches the theory. And no extension needed anymore.
The new I/O subsystem is less visible but wider. io_method = worker is the default now, io_uring is an option on Linux. Cold sequential scans on the copy got noticeably better. This is the kind of feature you do not tune. You just receive it.
Now the restraint. A beta benchmark is preparation, not a migration ticket. Plans can change before GA, and numbers from a laptop-grade staging box show direction. Magnitude waits for real hardware. My plan: run the application test suite against the beta, keep notes on anything strange, decide after the release.
If your primary keys are UUIDv4, start that conversation now. The keys are the one part you cannot fix with a config flag. I picked v4 for that table years ago. I knew about the index then. It seemed far away.