Most of us first learn B-Trees as "balanced search trees." That description isn’t wrong, but it misses the core idea: B-Trees were built to reduce costly disk I/O, not to save CPU cycles. Once you see them through that lens, their structure and design choices make immediate sense.
Why the usual "tree" framing is misleading
When you profile real databases, you quickly learn that CPUs are fast, RAM is fast enough, and the real wall is the storage subsystem. A single random disk/SSD read costs orders of magnitude more than a couple dozen CPU comparisons.
And here’s the crucial detail: every disk I/O pulls a whole page (e.g., 4 KB) into memory, not just one key. If that page holds only a single key and a couple of pointers, most of that bandwidth is wasted. So the relevant metric is not "how many comparisons" but how much useful work you get per disk read.
Binary search trees give you one comparison per node fetched. On disk, that commonly means you read a whole page (e.g., 4 KB) to get one key and a couple of pointers. That’s bandwidth waste.
B-Trees flip that assumption: design the node so one page fetch yields many comparisons’ worth of information. The result is dramatically shallower trees and far fewer disk trips.
A concrete derivation: numbers that matter
Let’s do the small arithmetic that every systems engineer should keep in their head.
Typical disk/SSD page: 4 KB = 4096 bytes.
Common key + pointer sizing (example): key = 8 bytes, pointer = 8 bytes → entry = 16 bytes.
Entries per page ≈
4096 / 16 = 256entries per node.
For N = 1,000,000 keys:
Balanced binary tree height ≈
log₂(N) ≈ 19.93→ ~20 levels → ~20 disk reads per lookup (worst case).B-Tree branching factor
b ≈ 256, so height ≈log₍₂₅₆₎(N) ≈ 2.49→ ~3 levels → ~3 disk reads per lookup.
So: ≈20 I/Os vs ≈3 I/Os. That’s roughly 6–7× fewer disk trips, which translates to dramatic latency and throughput improvements for storage-bound workloads.
Why those numbers matter:
Each disk trip often costs micro- to milliseconds depending on device; shave off a dozen trips and you massively shrink tail latency and increase throughput.
The mental model you should internalize
Think in pages, not nodes. Design each node to be (close to) a page so one read returns a full decision block.
Trade CPU for bandwidth. A B-Tree does more CPU work per node (binary search among 256 keys), but CPU is cheap compared to a disk read.
Shallow trees = fewer I/Os. Bigger fan-out collapses height; collapsing height collapses disk trips.
This mindset - optimize for the scarce resource - is exactly why DB engines default to B-Trees for indexes and why the choice survives decades of hardware evolution.
Short, practical checklist for engineers
If your workload is storage-bound (random reads on large datasets): prefer B-Tree style indexes tuned to page size.
If your keys are variable and large, expect lower fan-out; consider compression or indirection to recover packing density.
If writes dominate (append-heavy), evaluate LSMs (RocksDB, Cassandra) — they trade read cost for write throughput.
Always measure page reads and cache hit rates. The math is a guide; real workloads decide the tune points.
Closing (and a tiny experiment)
If you want to see this in action: pack a simulated "page" with many keys (256 entries) and compare simulated reads against a one-key-per-page model. You'll see the I/O count collapse exactly as the math predicts.
If this idea landed for you — that B-Trees are essentially bandwidth optimizers — I'll unpack node layout, fill-factor, buffer-pool behaviour and concurrency in the next issue. If you want the quick repo and the Python simulator I used while drafting this series, I'll share it next issue.
But if you can’t weight, here’s the detailed blog post on my website with diagrams, code, and mathematics.
If you liked this, subscribe to this newsletter for deeper, pragmatic breakdowns of database internals and systems design.