What is a cold read?

Why cold reads matter in benchmarking.

TLDR: A cold read happens when data isn't in cache and has to be fetched directly from storage. This happens constantly in production - after restarts, failovers, scaling events. Most benchmarks miss it because caches warm up in seconds. When you strip away the cache, gp3 takes tens of seconds. ABS stays sub-second. That gap is what matters.

Every storage system has layers. At the top sits cache — fast, temporary memory (usually RAM) that holds recently accessed data so it can be served quickly without touching the actual disk.

When you request data and it's already in cache, that's a warm read. Fast. Easy. The storage device barely has to do anything.

A cold read is the opposite. The data isn't in cache. It hasn't been accessed recently, or the cache has been cleared, or there simply isn't enough memory to hold it. So the system has to go all the way down to the storage layer — the actual SSD or block device — to fetch it.

Cold reads are slower by nature. That's expected. But how much slower depends entirely on the quality of your storage.

Why should you care?

Because cold reads happen in production far more often than people think:

→ A node restarts or fails over — cache starts empty
→ A database process crashes and recovers - everything has to be re-read from disk
→ Your working set grows beyond available RAM - common with ClickHouse, Postgres, and other data-heavy workloads where datasets are hundreds of GB or more
→ Cache churn evicts data that gets requested again shortly after
→ You scale out and new nodes come online with nothing cached

Every one of these is a cold read scenario. No safety net, no caching layer absorbing the impact. Just your storage, naked.

Why most benchmarks miss cold reads

Standard storage benchmarks run sustained, repetitive workloads. Within seconds, the OS page cache, the drive's DRAM cache, and the controller cache all warm up. Reads start getting served from memory instead of storage.

The numbers look great. But you're not actually measuring your disk anymore - you're measuring how well your caching layers hide latency.

That's fine for understanding steady-state performance. But it tells you nothing about what happens during the moments that matter most - the restarts, the failovers, the recovery windows.

Where this gets real

We benchmarked cold read performance on ABS vs. gp3 using ClickBench — 43 analytical queries, OS page cache dropped before every query. Same cores, same memory, same architecture.

→ ~10.5× median speedup across all queries
→ ~14.1× on IO-heavy queries
→ gp3 expanded into tens of seconds on large scans. ABS stayed sub-second.

Cold read performance answers one question: how fast does your system recover when things go wrong?

Full benchmark report here.