Postgres 19 beta: async I/O grows up, VACUUM finally chills

What happened

Snowflake's Postgres team — yes, that Snowflake, which spent 2024 quietly hiring half of the Postgres commit list after acquiring Crunchy Data — published a walkthrough of what's landing in Postgres 19 beta 1. The post hit 174 on Hacker News with the usual mixture of gratitude and grumbling. It is not a marketing piece. It is a working engineer's tour of the commits that matter, written by people whose day job is now shipping a managed Postgres.

The three headline items are asynchronous I/O via `io_uring`, an eager freezing strategy for VACUUM, and logical replication that survives `pg_upgrade`. Each one closes a wound that has been open long enough to have its own folklore. Async I/O has been a multi-release project — 17 laid the API, 18 shipped the worker-based backend, 19 finally wires up `io_uring` on Linux so a single backend can have dozens of reads in flight without spawning helper processes. Eager freezing is Melanie Plageman's answer to the anti-wraparound VACUUM stampede that has taken down more production databases than any single bug in the project's history. And logical replication slot preservation across major versions — a one-line summary that hides years of catalog-surgery work — means the standard blue/green upgrade pattern finally works without a bespoke dual-write shim.

Beta 1 is expected in May 2026 with GA in the September–October window. The commit fest is still open, so the final feature list will shift, but the async I/O and VACUUM work is locked in.

Why it matters

Start with `io_uring`. Postgres's process-per-connection model has always been the elephant in the room for I/O-bound workloads: every backend does its own synchronous `pread`, the kernel schedules them independently, and prefetching is a polite suggestion the OS may or may not honor. The `effective_io_concurrency` GUC has existed since 8.4 and, until 17, did approximately nothing on most workloads because it only affected bitmap heap scans via `posix_fadvise`. With `io_uring` as an async I/O method, a sequential scan can submit a batch of reads, keep the CPU busy on already-arrived pages, and let the kernel coalesce the rest. Early benchmarks from the pgsql-hackers list show 2-3x throughput improvements on cold-cache analytical scans against NVMe. That is the kind of number that used to require reaching for DuckDB or a columnar extension.

The VACUUM change is less flashy and more important. Anyone who has run Postgres at scale has lived through the 3 a.m. page where a 2 TB table hits `autovacuum_freeze_max_age`, autovacuum kicks off an anti-wraparound freeze that cannot be canceled, and I/O saturates for six hours. Eager freezing amortizes the cost by freezing pages during ordinary vacuums when they're already dirty and unlikely to be modified again, so the emergency freeze never has to visit them. It is the database equivalent of taking out the trash on your way to the car instead of when the kitchen catches fire. Plageman's benchmarks on the mailing list show anti-wraparound VACUUM work reduced by 60-90% on append-mostly workloads. For anyone running Postgres as an event store, log sink, or time-series backend, this is the single most valuable line in the release notes.

Logical replication across major versions is the sleeper. Until now, `pg_upgrade` preserved physical replication slots but not logical ones, which meant that any team using logical replication for CDC (Debezium, Materialize, Fivetran's log-based connector, homegrown outbox tailers) had to tear down and rebuild their entire downstream pipeline during a major upgrade. In practice, teams either stayed on old majors well past EOL or built elaborate parallel-write systems to bridge the gap. Preserving logical slots through `pg_upgrade` turns the major-version upgrade from a two-week project into an afternoon. The HN thread had a Materialize engineer noting that this alone will let their customers upgrade in place instead of provisioning a second cluster and cutting over.

The community reaction was more subdued than the feature list deserves, and that itself is a signal. Compare the muted "finally" energy of the Postgres 19 thread to the fireworks around MySQL 8's JSON support or MongoDB's transactions. Postgres has crossed into the phase where its releases are mostly about paying down debt on the fundamentals, not chasing new workloads. That is a mature-project posture and it is exactly what you want in the database under your revenue.

What this means for your stack

If you run Postgres on Linux with NVMe — which is to say, if you run Postgres — plan to enable `io_method = io_uring` in your 19 rollout and re-benchmark. The default will remain the worker-based backend for compatibility, but the uring path is where the wins are. Kernel 6.1+ is the practical floor; check your distro. AWS RDS and Aurora will lag by a quarter or two as usual; if you're on managed Postgres, ask your provider whether they plan to expose the setting or make it the default.

For VACUUM tuning, the eager freezing work means you can probably raise `autovacuum_freeze_max_age` closer to its ceiling without fear, and the emergency-freeze pathology becomes a rarer event. Teams that have been running custom vacuum cron jobs to preempt anti-wraparound (a shockingly common pattern) should be able to retire them after a shakeout period. Do not delete your monitoring — the new heuristics have edge cases and Plageman herself has flagged that heavy-update workloads may need `vacuum_freeze_min_age` retuning.

On the logical replication side, the upgrade story changes strategically. If you deferred a Postgres 15 → 17 upgrade because your Debezium pipeline made it too painful, 19 is your window. Wait for 19.1 or 19.2 to let the slot-preservation code settle, then bundle the upgrade with a Debezium version bump and clear a quarter of tech debt in a single change window. The alternative — riding an EOL major another year — is now the more expensive option.

Looking ahead

The interesting question is what Postgres does after it finishes paying down its I/O and VACUUM debts. Direct I/O is on the roadmap for 20. Columnar storage keeps showing up in mailing list threads. The Snowflake acquisition of Crunchy, EDB's ongoing dominance of the committer list, and Microsoft's Citus team all point toward a Postgres that is increasingly being pushed to eat the analytical workloads that OLAP vendors have owned for a decade. Postgres 19 is not that release. But it is the release that makes the machine underneath fast and boring enough that the next one could be.