Tuning async IO in PostgreSQL 18

Summary

PostgreSQL 18 was stamped earlier this week, and as usual there’s a lot of improvements. One of the big architectural changes is asynchronous I/O (AIO), allowing asynchronous scheduling of I/O, giving the database more control and better utilizing the storage.I’m not going to explain how AIO works, or present detailed benchmark results. There have been multiple really good blog posts about that. There’s also a great talk from pgconf.dev 2025 about AIO, and a recent “Talking Postgres” podcast episode with Andres, discussing various aspects of the whole project. I highly suggest reading / watching those.I want to share a couple suggestions on how to tune the AIO in Postgres 18, and explain some inherent (but not immediately obvious) trade-offs and limitations.Ideally, this tuning advice would be included in the docs. But that requires a clear consensus on the suggestions, usually based on experience from the field. And because AIO is a brand new feature, it’s too early for that. We have done a fair amount of benchmarking during development, and we used that to pick the defaults. But that can’t substitute experience from running actual production systems.So here’s a blog post with my personal opinions on how to (maybe) tweak the defaults, and what trade offs you’ll have to consider.io_method / io_workersThere’s a handful of parameters relevant to AIO (or I/O in general). But you probably need to worry about just these two, introduced in Postgres 18:io_method = worker (options: sync, io_uring)io_workers = 3The other parameters (like io_combine_limit) have reasonable defaults. I don’t have great suggestions on how to tune them, so just leave those alone. In this post I’ll focus on the two important ones.io_methodThe io_method determines AIO actually handles requests - what process performs the I/O, and how is the I/O scheduled. It has three possible values:sync - This is a “backwards compatibility” option, doing synchronous I/O with posix_fadvice where supported. This pr...