What Postgres 18's I/O boost helps, and what it doesn't

The headline from the Postgres 18 release in September was a single simple number: up to 3x faster reads from storage, courtesy of a new asynchronous I/O subsystem. PostgreSQL 19 Beta arrived this month with more work on that same subsystem, including I/O worker pools that scale automatically with load and improved asynchronous read-ahead for large requests, so it's a good moment to look at what this line of work actually does. The 3x figure comes from the Postgres team's own announcement, but there is trouble in how it gets heard. "Up to 3x faster reads" turns into "three times faster," and that is not the same claim.

The mechanism should be understood because it explains the gap. Earlier versions of Postgres generally waited for one storage read to complete before issuing the next within a given operation. The new subsystem lets the database issue many of those requests at once, so it spends less of its life idle, waiting on storage to answer. For operations that move large amounts of data off disk, the payoff will be worthwhile, and the release notes are precise about which ones qualify: sequential scans, bitmap heap scans, and vacuum. The up-to-3x figure lives inside that list, not outside it.

That precision is the whole story, because it draws a clean line between the queries this helps and the ones it doesn't:

• It helps most when you're I/O-bound. When a query spends its time waiting on the disk, reading a large table that doesn't fit in memory, the new subsystem addresses exactly that wait. A heavy analytical scan or a long vacuum is the case it was built for.
• It does little when you're already in memory. A query served from the buffer pool was never waiting on storage, so there is little for asynchronous I/O to improve. Workloads that fit in RAM will notice less.
• It speeds up getting the data, not processing it. This is the distinction that gets lost. Faster I/O pulls a million rows off disk more quickly, but it is still a million rows. The work the query does is unchanged, only the waiting is shorter.

That last line is where your expectations might start to drift. A slow query is rarely slow for one reason, and while there is time spent on disk, there is also the cost of the scan itself, the joins, the sort, and the number of times the query runs each minute. Postgres 18 shortens the disk wait for the operations above, but it does not reduce the rest of the work the query performs. A query that is slow because it reads heavily from storage stands to gain. A query that is slow because it does expensive work, or because the same costly read fires thousands of times an hour, will not move nearly as far as the headline implies.

The subsystem is serious engineering and an excellent reason to test 18 against your own workloads, particularly if large scans or long vacuums are a regular tax. The point is only to read the number for what it measures, so the upgrade is judged on what it does rather than the most generous interpretation of one statistic.

For the queries that are expensive because they repeat, the answer lies in a different direction. Instead of recomputing the same result each time, you compute it once and serve it from cache, which is what Readyset does for repeated reads, whatever the storage underneath is doing.

🔍 What We're Watching in the Database Ecosystem

Postgres War Stories: The Outages That Aren't Postgres Bugs

Some of the nastiest Postgres incidents start a layer below Postgres, in the kernel or glibc, where the database did exactly what it was told and still lost data. A sharp tour of the classics, like the fsync behavior that let Linux call a write durable when it never reached disk. The fixes are cheap, and most teams still ship without them.

The Database Storage Problem Is Solved. Here's What Comes Next

The argument here is that storage stopped being the hard part of databases a while ago, and the real challenge now is interoperability, getting operational data to analytical systems, AI tools, and downstream services without standing up another pipeline or keeping another copy in sync. AI didn't create that problem so much as make it impossible to ignore, since agents and copilots want current context and most architectures still scatter the same data across half a dozen places.

In Case You Missed It

If you're running Supabase and want lower read latency without touching application code, Vinicius walks through getting Readyset running in front of your project end-to-end, including the AWS and Docker setup for Supabase's default IPv6 mode.

Know a database aficionado who'd appreciate this? Forward it their way.