The Physics of Storage Latency — Dev Guide

Overview

Every storage decision you make is, underneath everything else, a physics decision. The two things that decide how fast you can get a piece of data back are how far it has to travel and what physical medium it's sitting on. That's it — that's the whole story behind why is fast, why a database call feels slower than reading a local variable, and why caching isn't an optimization trick — it's a direct consequence of physics.

Why It Exists

This matters before you look at any specific database, because it explains the reason those databases are built the way they are. A relational database puts frequently-used pages in memory instead of reading from disk every time, for the exact same reason your browser caches images instead of re-downloading them — because the gap between reading from and reading from disk is enormous, and no amount of clever software design can fully hide it. Once you know the actual numbers, a lot of storage-engine decisions later in this journey stop looking like arbitrary choices and start looking like the only sane option.

Real World Example

Say a web app loads a user's profile. If that profile is sitting in an in-memory cache, the response is close to instant — sub-millisecond. If it has to be read from a database on disk, that's now single-digit milliseconds — still fast, but roughly a thousand times slower than the cache. If loading that same profile means calling a third-party API in a different region, you can add 70–100 milliseconds just for the round trip, before the other service even does any work. Same request, same data, three wildly different response times — purely because of where the data physically lives.

How It Works

Storage forms a rough ladder, and each step down is dramatically slower than the one above it. CPU cache (L1/L3) measures in nanoseconds. Main memory () is close behind, tens to low hundreds of nanoseconds. Below that, everything gets slower by orders of magnitude at once: an answers in tens of microseconds, a spinning hard disk () takes single-digit milliseconds because a physical arm has to move, a network call within the same data center adds under a millisecond, and a network call to a different region adds tens to a hundred milliseconds — dominated by the literal speed of light over that distance, which no engineering can get around.

Diagram

The storage latency ladder — each step down is roughly 1,000x slower than the one above it

CPU L1/L3 Cache

~1–20 nanoseconds

Main Memory (RAM)

~50–100 nanoseconds

NVMe SSD

~20–100 µs — ~1,000x slower than RAM

Rotational HDD

~5–10 ms — ~100,000x slower than RAM

Same-Datacenter Network

~0.5–1 ms

Cross-Region Network

~70–100 ms — ~1,000,000x slower than RAM

Common Mistakes

Blaming "the database" when the real cost is a network hop or a missing cache

Why: A slow response is often not the database engine being slow — it's an uncached read hitting disk, or a cross-region call, both of which would be slow no matter which database you used.

Fix: Before optimizing queries, check where in the latency ladder the time is actually being spent — profile it, don't guess.

Not caching data that's read often and changes rarely

Why: Every uncached read pays the full cost of the storage layer it lives on, every single time — even when the answer was identical a second ago.

Fix: Cache read-heavy, low-change data as close to where it's used as possible, and only invalidate it when it actually changes.

Treating all "fast" storage as roughly the same speed

Why: SSDs are often described as "fast storage," which makes it easy to forget they're still about 1,000x slower than RAM — a real gap when you're doing millions of operations.

Fix: Use the actual numbers, not a fast/slow label, when deciding whether something needs to live in memory.

Interview Questions

beginner

Why is reading from RAM faster than reading from disk?

RAM is an electronic circuit the CPU can address directly in nanoseconds. A disk — even an SSD — involves a separate storage device, a controller, and a data transfer path that's inherently slower, on the order of microseconds to milliseconds depending on the disk type.

intermediate

Roughly how many times faster is RAM than an NVMe SSD, and why does that matter for system design?

Roughly 1,000 times faster. It matters because it's the entire justification for caching: if a value can be served from RAM instead of re-read from an SSD-backed database every time, you're not micro-optimizing — you're avoiding a real, measurable, three-orders-of-magnitude cost.

senior

A service's response time suddenly got 10x slower. Given the storage latency ladder, what would you check first?

Whether a change moved a hot code path down the ladder — for example, a cache that used to serve most reads started missing more often and falling through to the database, or a call that used to stay within one data center is now crossing regions. A 10x jump usually maps cleanly onto crossing one of the boundaries in the ladder, so I'd look for what changed at that boundary before assuming the database itself got slower.

Production Best Practices

Do

✓Cache data that's read often and changes rarely, as close to where it's used as possible.

✓Measure actual latency in your own system instead of assuming based on a storage type's general reputation.

✓Keep latency-sensitive, chatty calls within the same data center or region.

Don't

✗Don't treat an SSD as a substitute for an in-memory cache — the gap to RAM is still roughly 1,000x.

✗Don't ignore cross-region network calls as a hidden latency cost in a distributed system.

✗Don't over-cache data that changes constantly — a stale cache is a correctness bug, not a performance win.

Comparison

	Typical Latency	Roughly How Slow (vs RAM)
CPU L1/L3 Cache	~1–20 ns	Faster than RAM
RAM	~50–100 ns	Baseline
NVMe SSD	~20–100 µs	~1,000x slower
SATA SSD	~150–300 µs	~2,000–3,000x slower
Rotational HDD (seek)	~5–10 ms	~100,000x slower
Same-datacenter network	~0.5–1 ms	~10,000x slower
Cross-region network	~70–100 ms	~1,000,000x slower