PostgreSQL 18 Brings Asynchronous I/O

PostgreSQL 18, released September 2025, introduces asynchronous I/O. Until now, all reads were synchronous: the backend process issued a system call and waited until the kernel returned the data. PostgreSQL 18 can now queue multiple read requests and continue execution while the kernel or workers handle them.

Why is it important

Blocking reads were the main source of query stalls on cold data. On cloud volumes and remote disks, latency often dominates execution time. With asynchronous I/O, PostgreSQL overlaps disk operations with computation and other reads. Benchmarks show up to two to three times faster execution in cold-scan workloads.

Scope of the Feature

PostgreSQL 18 supports async reads in sequential scans, bitmap heap scans, and vacuum. Index access methods still use synchronous reads. Writes and WAL remain synchronous to preserve durability guarantees.

How It Works

A new setting io_method controls the mode. The default remains synchronous. The two async modes are:

• worker: backends enqueue read requests to a pool of I/O workers. Workers perform the reads and fill shared buffers, then notify the backend.
• io_uring: on Linux kernels with io_uring support, the backend submits multiple read requests directly to the kernel without blocking.

Tuning involves io_workers (for worker mode) and effective_io_concurrency, which defines how many requests can be issued at once. The new pg_aios view shows in-flight requests.

Observability Changes

Backends no longer block directly on read(). Instead, you may see wait events such as AioIoCompletion. Some execution time is now hidden from EXPLAIN ANALYZE. Monitoring requires correlation between PostgreSQL’s pg_aios view, wait events, and system-level I/O metrics.

When It Helps

Asynchronous I/O is most effective for:

• Cold sequential scans of large tables
• Analytical queries reading many uncached pages
• Maintenance tasks like vacuum or index builds on uncached data
• Cloud environments where storage latency is higher
• But workloads with high cache hit ratios will see little change.

Caveats

The feature is new. Some access methods are not yet supported. Misconfigured concurrency settings can saturate the storage system. io_uring mode requires specific kernel versions and filesystems. Gains are workload dependent and must be validated with testing.

Conclusion

PostgreSQL 18 replaces decades of blocking reads with an asynchronous option. The impact will be most visible in analytical and cloud workloads where I/O dominates. For the first time, PostgreSQL backends can overlap disk activity with useful work, narrowing the gap with systems that already exploit kernel async I/O.