Postgres releases are usually incremental in a good way — a batch of solid improvements, none of which change how you think about the database. Version 18 is mostly that, with one exception: asynchronous I/O is a genuine architectural change to how the server reads from disk, and it matters more on some infrastructure than others.
The rest of the release is a useful collection of things that remove long-standing workarounds.
What changed in 2026
- Async I/O landed as a real subsystem. Rather than each read blocking a backend process, Postgres can now issue multiple read requests concurrently and process results as they arrive.
- UUIDv7 became native. Time-ordered UUID generation moved into the server, removing the need for an extension or application-side generation.
- Generated columns gained a virtual form. Computed-on-read columns joined the previously stored-only option, and virtual became the default when unspecified.
- Authentication options expanded. Support for token-based authentication flows made integrating Postgres with modern identity infrastructure less awkward.
What each change is actually for
| Feature |
Problem it solves |
Who benefits |
| Asynchronous I/O |
Backend blocks on each disk read |
Read-heavy workloads on higher-latency storage |
| Native UUIDv7 |
Random UUIDs fragment indexes badly |
Anyone using UUID primary keys |
| Virtual generated columns |
Stored columns waste space for cheap computations |
Wide tables with derived values |
| B-tree skip scan |
Multi-column index unusable without leading column |
Queries filtering on non-leading columns |
| Token-based authentication |
Password management for service connections |
Cloud and enterprise deployments |
| Faster upgrade path |
Statistics lost on major version upgrade |
Anyone doing major upgrades |
The UUID change deserves attention because the problem it fixes is common and quietly expensive. Random UUID primary keys scatter inserts across the index, causing page splits and poor cache locality. Time-ordered UUIDs keep inserts roughly sequential while retaining the distributed-generation property that made UUIDs attractive. If you are using random UUIDs as primary keys on a large table, this is the most consequential item in the release for you.
Where async I/O actually helps
The benefit scales with storage latency. On network-attached cloud storage, where a read might take a meaningful fraction of a millisecond, being able to have several reads in flight simultaneously is a substantial throughput improvement for sequential scans and bitmap heap scans.
On local NVMe with very low latency, the gain is smaller, because the blocking you were doing was not costing much. This is the measurement to make before treating the release as a performance upgrade — check your storage latency profile rather than assuming.
Also note that the benefit concentrates in read paths that fetch many pages: large sequential scans, index scans touching many heap pages, and vacuum. Point lookups served from cache see no change, because there was no I/O to overlap.
For the general question of when Postgres is the right choice at all, Postgres vs SQLite covers the tradeoff, and SQLite in production covers the cases where the simpler option wins.
Common mistakes
- Upgrading for async I/O without measuring storage latency. The benefit is proportional to the latency you were blocking on.
- Switching to UUIDv7 without reindexing. Existing random UUIDs stay fragmented; the benefit applies to new data unless you rebuild.
- Using virtual generated columns for expensive computations. They compute on every read. Stored is right when the computation is costly and reads are frequent.
- Skipping the upgrade testing on extensions. Major version upgrades require extension compatibility, which is the usual source of upgrade delays.
- Assuming skip scan makes indexes optional. It helps when the leading column has low cardinality; it is not a substitute for an appropriate index.
FAQ
Is the upgrade to 18 disruptive?
It is a major version upgrade with the usual requirements — extension compatibility, testing, and a planned migration. Improvements to statistics retention make the post-upgrade period smoother than previous major upgrades.
Should I switch primary keys to UUIDv7?
If you already use random UUIDs and have large tables, it is worth planning. If you use sequential integers and have no distributed-generation requirement, there is no reason to change.
Does async I/O require configuration?
There are settings governing the I/O method and concurrency. Defaults are reasonable; tuning is worthwhile if you have measured a benefit and want more of it.
Do I need new drivers?
Standard client protocols are unchanged. Token-based authentication support requires client-side capability if you intend to use it.
Where to go next
For deciding between databases, read Postgres vs SQLite. For safe schema changes at scale, zero-downtime deployment, and for isolated development databases, database branching explained.