March 1, 2026
Knobocalypse: DBAs vs the 25x bomb
The real cost of random I/O
One test says random reads are 25x pricier—cue comment war
TLDR: A test claims random reads can be ~25x slower than sequential ones, challenging the popular “set it low on SSDs” advice. Comments split between keeping a low setting for real-world wins, demanding automatic tuning inside the database, and joking about knob overload—because this tiny number reshapes query speed.
A new Postgres experiment just dropped a spicy number: reading scattered data (“random reads”) looked about 25 times slower than reading in order. Translation for non-DB nerds: flipping through a book at random is way slower than reading page by page. That clashes with the internet’s favorite tip: “SSDs are fast—set the cost low!” Cue the comments, chaos, and caps lock.
On one side, the “1.1 crew” swears by dialing the setting way down so the database prefers indexes, with sgarland saying it usually works fine and rarely backfires—and if it does, get a better index. On the other, data realists like Normal_gaussian argue that real workloads aren’t truly random anyway, and they want auto-tuning so apps aren’t juggling settings mid-transaction. Meanwhile, jasonhansel drops the crowd-pleaser: why not have the database measure the drive itself once in a while, like a mini speed test, and tune accordingly?
The vibe: myth-busting meets knob fatigue. Some are clutching pearls over a 25x headline number; others say the lab test is extreme and “production isn’t a science fair”. Jokes fly about “Knobocalypse Now” and “set-it-and-forget-it? more like set-it-and-fret-it.” But the core drama is simple: do you trust a tidy rule (set it low), the scary math (it’s higher!), or do you let the machine self-calibrate? The only thing everyone agrees on: this one tiny number can make your queries fly—or faceplant.
Key Points
- •PostgreSQL’s random_page_cost default (4.0) dates back ~25 years and may not reflect current storage realities.
- •An experiment with a 10M-row table, controlled caching (128MB shared_buffers and effective_cache_size), and direct I/O was used to measure random vs sequential I/O.
- •Sequential scan: Buffers shared read=454,546; Execution Time=708.420 ms; yielding a per-page sequential read time of 1.559 µs.
- •Index scan: Buffers shared hit=342,789 read=9,684,524; Execution Time=392,976.430 ms; yielding a per-tuple random read time of 39.298 µs.
- •Derived random_page_cost ≈ 25.2, significantly higher than the default 4.0, contradicting advice to lower it on SSDs; CPU per-tuple costs are minor compared to I/O.