PostgreSQL 18, Ten Months In: Is the Upgrade Actually Worth It?

PostgreSQL 18 has been out for ten months, long enough that the “wait for the first few point releases” advice no longer applies. It’s on 18.4 as of May 2026, and PostgreSQL 19 is still in beta, which makes 18 the newest version you should actually be running in production today, not the newest version that exists. If you’ve been putting off the upgrade decision, here’s what actually changed and whether it’s worth your maintenance window.

The async I/O subsystem is the real headline

Postgres has historically issued storage reads one at a time, waiting for each to complete before starting the next. PostgreSQL 18 introduces an asynchronous I/O subsystem that can issue multiple read requests concurrently, and the project’s own benchmarks show 2-3x throughput improvements on sequential scans, bitmap heap scans, and vacuum operations, specifically on workloads that are bound by storage latency rather than CPU.

Turning it on is a configuration change, not a schema or query change:

# postgresql.conf
io_method = worker      # works on all platforms
# or, on Linux:
io_method = io_uring    # lower overhead, requires a recent kernel

The sync option preserves the old one-request-at-a-time behavior if you need to rule out AIO as a variable while debugging something else. For most storage-bound workloads, this is close to a free performance win: no application changes, just a config flag and a restart.

uuidv7() fixes a real primary-key anti-pattern

If you’ve used gen_random_uuid() for primary keys, you’ve likely also hit the downside: UUIDv4 values are fully random, so every insert lands at an unpredictable point in the B-tree index. That causes index bloat and poor cache locality, the exact opposite of what an auto-incrementing integer gives you for free.

-- Before: fully random insert order, poor index locality
CREATE TABLE orders (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  created_at timestamptz NOT NULL DEFAULT now()
);

-- PostgreSQL 18: timestamp-ordered, still globally unique
CREATE TABLE orders (
  id uuid PRIMARY KEY DEFAULT uuidv7(),
  created_at timestamptz NOT NULL DEFAULT now()
);

uuidv7() embeds a timestamp in the leading bits of the UUID, so new rows insert in roughly chronological order, close to the locality benefit of a sequential integer, while keeping the collision-resistance and non-guessability that made you choose a UUID in the first place. This is a strong default for any new table’s primary key going forward; it’s not worth a migration for existing tables unless index bloat on that table is an active, measured problem.

Virtual generated columns: compute at read time, not write time

Generated columns aren’t new, but PostgreSQL 18 adds a virtual variant that computes its value at query time instead of storing it on disk:

ALTER TABLE orders ADD COLUMN total_with_tax numeric
  GENERATED ALWAYS AS (subtotal * 1.08) VIRTUAL;

This trades a small per-query CPU cost for zero storage overhead and, critically, no table rewrite when you add the column, which matters a lot on a large table where a stored generated column would mean a long, locking ALTER TABLE. Use virtual for columns you read occasionally and want to add without downtime; keep using stored generated columns for anything read on nearly every query, where recomputing on the fly would add up.

The upgrade itself hurts less

The most underrated change in 18 isn’t a new feature, it’s what pg_upgrade no longer breaks. Before 18, a major version upgrade discarded the query planner’s statistics, so the freshly upgraded cluster ran on stale assumptions until autovacuum’s ANALYZE finished rebuilding them, sometimes producing a window of genuinely bad query plans on a busy system right after the upgrade you scheduled specifically to avoid disruption. PostgreSQL 18 carries statistics through the upgrade, so performance stays close to the pre-upgrade baseline instead of dipping and recovering.

What to check before you upgrade

Area	What to verify
Extensions	Confirm every extension you depend on has a PostgreSQL 18–compatible build
io_method	Test worker first; io_uring needs a sufficiently recent Linux kernel
OAuth	Only relevant if you’re adopting the new oauth authentication method in pg_hba.conf; existing auth methods are unaffected
Connection poolers	Verify your pooler (PgBouncer, pgcat) has a tested-compatible release for 18’s wire protocol changes
Staging load test	Run your actual query mix against a staging copy before flipping the production upgrade

Should you wait for 19 instead?

No, not for a production system. PostgreSQL 19 is still in beta as of mid-2026, with general availability expected around September or October based on the project’s usual yearly cadence. Its headline feature, the REPACK command for online table rewrites, is worth testing against a staging snapshot now if bloat management is a pain point for you, but running a beta release against production data goes directly against the PostgreSQL project’s own guidance. Eighteen is the version to run today; nineteen is the version to be testing in parallel.

If your team’s upgrade path involves more than a version bump, whether that’s connection pooling changes, zero-downtime migration planning, or a broader infrastructure review, that’s the kind of work worth scoping properly rather than squeezing into the same maintenance window as the Postgres upgrade itself.

Ten months of point releases is a reasonable maturity bar. If you’re still on Postgres 16 or earlier and storage I/O shows up in your slow query logs, this is a good week to schedule the upgrade.