Benchmarking Postgres 17 vs. 18

Summary

Benchmarking Postgres 17 vs 18By Ben Dicken | October 14, 2025Postgres 18 released a few weeks ago, and there's plenty of hype around the improvements it's bringing. Most notably, Postgres 18 introduces the io_method configuration option, allowing users more control over how disk I/O is handled.Setting this to sync results in the same behavior as 17 and earlier versions. With this, all I/O happens via synchronous requests.18 introduces two alternatives: worker and io_uring. worker (the new default) causes Postgres to use dedicated background worker processes to handle all I/O operations. io_uring is the change many are excited about for performance reasons, as it uses the Linux io_uring interface to allow all disk reads to happen asynchronously. The hope is that this can lead to significantly better I/O performance.We conducted detailed benchmarks to compare the performance on Postgres 17 and 18. Let's see if these improvements are all they're hyped up to be.sysbench was used for executing the benchmarks. The io_uring improvements only apply to reads, so the focus here will be on the oltp_read_only benchmark. This includes both point selects and queries that do range scans and aggregations controlled by the --range_size argument. Though it would be interesting to also benchmark write and read/write combo performance as well, sticking to read-only helps focus this discussion. We set the data size to be TABLES=100 and SCALE=13000000 which produces a ~300 GB database (100 tables with 13 million rows each).The benchmarks were conducted on four different EC2 instance configurations:InstancevCPUsRAMDiskDisk typeIOPSThroughputr7i.2xlarge864 GB700 GBgp33,000125 MB/sr7i.2xlarge864 GB700 GBgp310,000500 MB/sr7i.2xlarge864 GB700 GBio216,000-i7i.2xlarge864 GB1,875 GBNVMe300,000-All these instances run on the same (or extremely similar) Intel CPUs. We include the i7i instance to show what Postgres is capable of with fast, local NVMe drives. This is what we use for PlanetScale Met...