Benchmarking Postgres 17 vs 18: What the New I/O System Really Delivers Postgres 18 quietly changes something fundamental about how the database talks to storage. For the first time, you can choose how Postgres performs disk I/O. It sounds technical, but it affects one of the most important parts of database performance: how quickly data moves between memory and disk. PlanetScale’s team decided to find out what that really means in practice. They ran a series of benchmarks comparing Postgres 17 with the new Postgres 18 , testing all of the new I/O options under a variety of conditions. The results show that Postgres 18 is faster and more flexible, but also that the gains depend heavily on your storage and workload. What Changed in Postgres 18 In earlier versions, every I/O operation in Postgres was synchronous. The database asked the operating system for data and waited until it was ready. That made behavior predictable but sometimes limited throughput. Postgres 18 introduces a new parameter called io_method. It determines how Postgres issues and manages disk operations. There are now three modes: [object Object], [object Object], [object Object] On paper, this should allow Postgres to keep disks busy while freeing up CPU time for query processing. The benchmark aimed to see how much that helps in practice. How PlanetScale Tested It The team used sysbench, a standard tool for database stress testing. They focused on the oltp_read_only workload, which measures how well Postgres handles reads. That choice matters because io_uring only affects read paths at the moment. The database contained around 300 GB of data spread across 100 tables, each with 13 million rows. With only 64 GB of RAM available, the dataset couldn’t fit entirely in memory, forcing the system to hit disk often-exactly the scenario where better I/O should help. They ran each configuration for five minutes, with a ten-minute warm-up period. Tests varied in three main ways: [object Object], [object Object], [object Object] In total, 96 benchmark runs covered every combination of Postgres version and I/O method. Hardware Overview The tests ran on AWS EC2 instances with identical CPUs and memory but different disk setups: [object Object], [object Object], [object Object], [object Object] This spread let them see how the new I/O methods behave when the disk is the bottleneck versus when it’s not. Results Low Concurrency With a single connection, Postgres 18 was generally faster than 17. The new worker mode performed especially well, while io_uring often lagged behind on network-attached disks. On local NVMe storage, the differences narrowed. For small queries (range size 100), worker and sync still led. For larger range scans, all three modes were closer, and disk latency mattered more than the I/O method. Moderate Load At ten concurrent connections, patterns began to shift. On slower disks, io_uring struggled. On faster hardware, it caught up, though worker remained the most consistent performer across all environments. Heavy Concurrency At fifty connections, Postgres 18 pulled ahead of 17 across the board. On network-attached storage, performance was similar between I/O modes because the disks themselves were the limiting factor. On local NVMe drives, io_uring finally showed its potential, edging out worker in throughput for large range scans. The lesson: io_uring can help in very fast, high-concurrency environments, but it doesn’t automatically win in every scenario. Cost Perspective The hardware story isn’t complete without cost. Here are the approximate monthly AWS prices used in the benchmark: [object Object], [object Object], [object Object], [object Object] Even though the NVMe instance isn’t the cheapest per hour, it provides far better throughput and comes with nearly 1.8 TB of local SSD space. In performance per dollar, it wins by a wide margin. Why io_uring Isn’t Always Faster It’s tempting to expect io_uring to dominate, but several factors limit its impact today. [object Object], [object Object], [object Object], [object Object], [object Object] So while io_uring is an exciting step forward, it’s not a universal speed boost. It’s a tool that pays off only in the right environment. What This Means for You If you upgrade to Postgres 18 , you’ll get the worker I/O method by default. It’s a safe and smart choice, delivering smoother parallel performance without the complexity of io_uring . If you run on local NVMe disks and handle lots of concurrent reads, it’s worth experimenting with io_uring. You might see small but measurable gains. For most other setups, worker will likely perform just as well or better. The broader message from these benchmarks is simple: hardware still matters more than I/O method. Fast, local storage beats higher-end network volumes in both speed and cost efficiency. Final Thoughts Postgres 18 is not a revolutionary release, but it makes meaningful progress. It gives database administrators more control over how
