PostgreSQL 18: Async I/O, uuidv7, Generated Columns, and Why Developers Should Care

PostgreSQL keeps doing the rare thing in software: getting better every year without getting worse. Version 18 is a meaty release, and unusually for a database upgrade, several of its headline changes are things application developers not just DBAs will actually feel. A new asynchronous I/O subsystem, a built-in time-ordered UUID generator, more flexible generated columns, and smarter indexing each address real, everyday pain. This guide walks the changes that matter for the people writing the queries, and why they are worth an upgrade.

Asynchronous I/O: faster reads under load

Historically PostgreSQL issued disk reads one at a time and waited for each fine on fast storage with small working sets, less so when a query must pull many pages that are not cached. Version 18 introduces an asynchronous I/O subsystem that lets the database have multiple read requests in flight at once, so it spends less time waiting on storage. For read-heavy workloads, large scans, and analytical queries, this can meaningfully improve throughput, especially where data does not all fit in memory.

uuidv7(): the right way to do UUID keys

Developers love UUIDs for primary keys globally unique, generatable on the client, no central sequence. But traditional random UUIDs (v4) have a nasty side effect: because they are random, inserting them scatters writes across the index, causing fragmentation and poor cache behaviour as tables grow. UUIDv7 fixes this by embedding a timestamp so values are time-ordered: new rows cluster together in the index the way auto-incrementing integers do, while keeping UUID uniqueness. PostgreSQL 18 adds a built-in uuidv7() function, so you no longer need an extension or client-side library to get them.

-- Time-ordered UUID keys, built in — unique AND index-friendly.
CREATE TABLE orders (
    id          uuid PRIMARY KEY DEFAULT uuidv7(),
    customer_id bigint NOT NULL,
    created_at  timestamptz NOT NULL DEFAULT now()
);

-- New rows cluster at the "end" of the index like serial ids,
-- avoiding the write scattering that random uuidv4 causes.

Generated columns get more flexible

Generated columns let the database compute a column from other columns automatically. Previously PostgreSQL only supported stored generated columns the value is computed on write and saved to disk. Version 18 adds virtual generated columns, computed on the fly when you read them, so they cost no storage and never go stale. This is ideal for derived values you want to query like a normal column but do not want to physically persist.

CREATE TABLE products (
    price_cents   int  NOT NULL,
    tax_rate      numeric NOT NULL,
    -- computed on read: no storage, always current with its inputs
    total_cents   int GENERATED ALWAYS AS
                  (price_cents + round(price_cents * tax_rate)) VIRTUAL
);

Skip scan: more queries use your indexes

A classic gotcha: you have a multicolumn index on (a, b), but a query filters only on b, so PostgreSQL cannot use the index efficiently and falls back to a slower scan. Version 18 improves this with skip scan, which lets the planner use such an index even when the leading column is not constrained, by effectively "skipping" through its distinct values. The practical effect is that more of your existing queries can lean on indexes you already have, without you adding new ones.

A smoother upgrade path

Major PostgreSQL upgrades have long carried a hidden cost: after the upgrade, the database's query planner statistics were not carried over, so the freshly upgraded system could run with poor plans until those statistics were rebuilt sometimes a nasty performance dip right when you least want one. Version 18 improves this area so upgrades are less likely to leave you with a temporarily slow database, lowering the risk and stress of moving up a major version.

Should you upgrade?