How Fast Are CPU, Cache, RAM and SSD? (With Numbers)
How fast are the CPU, cache, RAM and SSD? Compare latency and bandwidth in nanoseconds and GB/s, scaled to human time, and learn what it means for your code.
A CPU cache hit takes about a nanosecond, RAM about 100 nanoseconds, and a random read from an SSD about 20 to 100 microseconds. Each step down the memory hierarchy is roughly 10 to 100 times slower than the one above it, but also bigger and cheaper. These are orders of magnitude, not benchmarks: exact numbers change with every hardware generation.
This guide compares the four on both latency (how long one access takes) and bandwidth (how much data per second), scales them to human time so the gaps feel real, and shows what that means for your code. For the full list including networks and continents, see our latency numbers every engineer should know.
Key takeaways
- Latency and bandwidth are different. A device can move data quickly in bulk and still be slow to start.
- Each layer is about 10x to 100x slower than the one above it. Cache, RAM, SSD, then network.
- Sequential access is far cheaper than random access on every layer.
- The CPU spends much of its time waiting for memory, so data layout often matters more than clever arithmetic.
- All numbers here are approximate. Measure on your own hardware before optimising.
The comparison
| Layer | Typical latency | Typical size | What it is |
|---|---|---|---|
| CPU registers | Under 1 ns | Bytes | Values the CPU is working on right now |
| L1 cache | About 1 ns | Tens of KB per core | Smallest, fastest cache |
| L2 cache | About 4 to 7 ns | Hundreds of KB to a few MB | Larger, slightly slower |
| L3 cache | Roughly 10 to 40 ns | Many MB, shared | Shared between cores |
| RAM | About 100 ns | Gigabytes | Main memory |
| NVMe SSD (random 4 KB read) | About 20 to 100 µs | Hundreds of GB to TB | Fast persistent storage |
| SATA SSD | Roughly 100 µs and up | Hundreds of GB to TB | Older, slower interface |
| Hard disk seek | About 5 to 10 ms | TB | Spinning platters |
L1 and L2 figures follow the common latency tables. L3, SATA and size figures vary widely by product, so treat them as ballparks.
Latency scaled to human time
If an L1 cache hit took 1 second:
- An L2 hit would take a few seconds.
- A RAM access would take about 1.5 minutes.
- An NVMe SSD random read would take several hours to a day.
- A hard disk seek would take months.
That is why moving data one layer closer to the CPU is the biggest speed-up you can find.
Clock speed in context
A 4 GHz CPU completes a cycle in 0.25 ns. An L1 hit costs a few cycles, while a RAM access costs hundreds of cycles during which the core may have nothing to do. Modern CPUs hide some of this with prefetching and out-of-order execution, but a program that jumps around memory randomly still stalls.
Bandwidth: how much data per second
Bandwidth tells you how fast bulk data moves once the transfer starts. Some figures follow directly from the interface specs:
| Interface | Theoretical maximum |
|---|---|
| DDR5-4800 memory, one channel | 38.4 GB/s (4,800 million transfers per second times 8 bytes) |
| PCIe 4.0 x4 NVMe SSD | About 7.9 GB/s |
| SATA III SSD | About 600 MB/s |
Real drives and memory systems land below these ceilings, and RAM bandwidth scales with the number of channels. The point is the ratio: RAM moves data several times faster than even a fast NVMe drive, and tens of times faster than a SATA SSD.
Why SSD "feels" fast but is still slow to the CPU
An SSD is vastly faster than a hard disk, so upgrading feels transformative. But to a CPU, a 50 µs SSD read is about 50,000 nanoseconds, which is hundreds of times longer than a RAM access. Fast storage narrows the gap with RAM. It does not close it.
What this means for your code
- Keep hot data together. Arrays laid out contiguously use cache lines well. Pointer-heavy structures scatter reads and miss the cache.
- Access memory sequentially when you can. Prefetchers favour predictable patterns.
- Cache what you re-read. Keep frequently used data in RAM instead of fetching it from disk or a database. See caching strategies.
- Size your database memory for the working set. If hot data and indexes fit in RAM, queries avoid storage reads. See how database indexes work.
- Batch small I/O. Many tiny reads cost far more than one large one.
- Measure first. Profile before you restructure anything.
Where networks fit
Once data leaves the machine, a round trip inside a data center costs roughly 0.1 to 0.5 ms and crossing an ocean costs tens of milliseconds or more. That is why one extra network call in a hot loop outweighs almost any in-memory optimisation. See load balancers explained and CDN explained.
Want a faster system?
If your app or data pipeline is slower than it should be, we profile it, find the real bottleneck and fix it. Get a scope estimate for a performance review, or try the project estimator.
FAQ
How fast is a CPU cache compared to RAM?
An L1 cache hit takes about 1 ns, while a RAM access takes about 100 ns, so cache is roughly 100 times faster for a single access. Larger caches (L2, L3) sit in between.
Is an SSD faster than RAM?
No. RAM is orders of magnitude faster. A random NVMe read takes tens of microseconds, while RAM takes about 100 nanoseconds. SSDs are far faster than hard disks, but still much slower than memory.
What is the difference between latency and bandwidth?
Latency is how long one access takes. Bandwidth is how much data moves per second. A device can have high bandwidth and still be slow to respond to a single small request.
Why is cache so small?
Fast memory is physically larger and more expensive per byte, and bigger caches are slower to search. Designers use a small fast cache plus larger, slower layers behind it.
How much faster is NVMe than SATA?
Interface limits differ widely: about 600 MB/s for SATA III against roughly 7.9 GB/s for PCIe 4.0 x4. Real drives come in below those ceilings.
Are these numbers exact?
No. They are orders of magnitude and vary by CPU, memory and drive generation. Benchmark your own hardware.
Sources
- Our latency numbers every engineer should know for the shared latency table.
- Interface bandwidth figures are derived from the published DDR5, PCIe 4.0 and SATA III signalling rates.