Latency Numbers Every Developer Should Know

Quick answer
The useful form of these numbers is ratios, not precisions: a cache hit is nanoseconds, RAM is tens of nanoseconds, SSD random reads are tens of microseconds, disk seeks milliseconds, and network round trips from fractions of a millisecond to hundreds depending on distance.
Every step up the ladder costs roughly an order of magnitude or more. That is why avoiding a network call or a disk read matters far more than shaving microseconds off computation.
A round trip to another machine in the same data centre is around half a millisecond; across a continent it is tens of milliseconds; across an ocean it is one to a few hundred milliseconds.
These are approximations that shift with hardware generations. Treat them as a sanity check for whether a design is plausible, not as a benchmark.
The practical use is arithmetic on your own request path: count the round trips before you count the CPU.

What are the latency numbers every developer should know?

They are a set of approximate times for the operations computers do most often, popularised as a table for engineers to carry in their heads. The exact values move every few years, but the ordering has been stable for a long time, and the ordering is what matters. A register is on the order of a nanosecond; a level-1 cache hit is about that; main memory is tens to around a hundred nanoseconds; a solid-state random read is tens of microseconds; a spinning disk seek is several milliseconds; a network round trip depends almost entirely on distance.

Group them by order of magnitude and the design lesson falls out. Below a microsecond: things you can do millions of times in a request. Microseconds: fine in moderation, dangerous in a loop. Milliseconds: a visible budget item. Tens to hundreds of milliseconds: user-perceptible delay that has to be earned. Once you know which band an operation lives in, most performance intuition follows without measuring anything.

The ladder, step by step

The table below is deliberately rounded. It does not include a source claiming precision, because the point is the ratio between rows, not the third significant figure. If you want current exact figures for your own hardware, measure them; use this to decide what is worth measuring.

Operation                          Approximate time
---------------------------------- ------------------------
CPU register / L1 cache hit        ~1 ns
Main memory (RAM) access           ~100 ns
Read 1 MB sequentially from RAM    ~tens of microseconds
SSD random read                    ~100 us
Read 1 MB sequentially from SSD    ~hundreds of microseconds
Spinning disk seek                 ~several ms
Round trip, same data centre       ~0.5 ms
Round trip, same continent         ~tens of ms
Round trip, cross-continent        ~100-300 ms
DNS lookup (uncached)              ~tens of ms
TLS handshake (extra round trips)  ~1-2x the RTT above

How to use the ladder on a real request

Count the hops before you count the cycles. A page that makes one database query is a different animal from one that makes fifty, because each query is at least a round trip if the database is remote, and often a disk read besides. The classic N+1 problem is an order-of-magnitude bug for exactly this reason: it replaces one millisecond-scale operation with a hundred of them, and no amount of CPU optimisation recovers that.

Then look for the operations at the top of the ladder being repeated. A cached value served from memory costs roughly a thousandth of a database round trip; a value computed once per request instead of once per row is often the single largest win available. The ladder turns vague advice like ‘cache things’ into a specific comparison you can make against your own code.

Where the ladder stops being enough

It tells you relative cost, not absolute performance. Two systems an order of magnitude apart in the ladder can still swap places in reality — a well-optimised SSD array beats a badly congested network path, and a warm cache beats a nominally faster remote one. It also says nothing about throughput: a slow operation done in parallel and a fast one done serially can finish in the same time. The numbers bound the possibilities; measurement decides the outcome.

Use them as a filter for which hypotheses are worth testing. If a proposed optimisation targets a microsecond-scale operation in a path dominated by a millisecond-scale one, it cannot help much, and you can skip the experiment. If it removes a round trip, it is worth measuring immediately.

Where this bites vibecoders
This is the knowledge an AI assistant reliably has and rarely volunteers. It will happily generate a loop that queries the database per item if the prompt did not say otherwise, because each call is correct in isolation. Knowing that a query costs a thousand times a memory lookup is what lets you reject the output on sight instead of discovering the shape of the problem in production. Ask for the query count of a generated endpoint — one query is fine, dozens usually are not.

Where AI coding assistants get this wrong

Generating per-item database queries instead of a single batched query.
Measuring CPU time when the request path is dominated by network round trips.
Adding a cache in front of a microsecond operation instead of the millisecond one.
Assuming a remote call is fast because the SDK is asynchronous.
Optimising serialisation of a payload that is about to cross a slow link anyway.
Treating the latency table as benchmark data for the specific hardware in front of you.

Checklist

Write down every external call the request path makes.
Estimate the band each call sits in on the ladder.
Count database queries per request and eliminate per-row queries.
Move repeated computations out of loops and into cached values.
Batch or parallelise only where the operations are independent.
Measure after the change, from the user’s side of the network.

FAQ

Are latency numbers still accurate today?

The exact values drift — memory and SSD times have improved, network times are dominated by distance and have barely moved. The ordering and the order-of-magnitude gaps have been stable for years. Use them to reason about relative cost, and measure your own hardware for figures you intend to act on.

Why is a network call so much slower than RAM?

Because a round trip involves travelling a physical distance and passing through several devices on the way. A same-data-centre round trip is roughly a thousand times a memory access, and cross-continent is a hundred times that again. Distance, not software, sets the floor, which is why colocating services helps and micro-optimising the serialiser does not.

What is the biggest win in this list for a typical web app?

Eliminating repeated database round trips, usually by fixing N+1 query patterns and adding caching for values read on every request. Those changes replace millisecond-scale operations with microsecond-scale ones. Shaving CPU work in the same path is typically an order of magnitude less effective.

Do these numbers apply to mobile or edge clients?

The local figures do, with caveats — phone storage and memory are slower than a server’s. Network figures are worse and more variable: mobile round trips include radio wake-up and carrier routing, which can add tens to hundreds of milliseconds on top. Treat client-side network latency as one band worse than the server-side table suggests.