B+ Tree
Keep routing keys in internal nodes and all records in linked leaves so point lookups stay shallow and range scans stay fast.
Interactive visualization
Use the controls to connect the idea to concrete operations before diving into the full write-up.
internal node [7 | 15]
Internal nodes route searches. Actual records live in the leaves.
leaf [1, 3, 5]
Leaf links allow sequential range scanning.
leaf [7, 9, 12]
Leaf links allow sequential range scanning.
leaf [15, 18, 21]
Leaf links allow sequential range scanning.
Leaves hold the real ordered data
For range queries, linked leaves are the superpower: once the first leaf is found, the scan can stream forward without climbing back up the tree.
Family
Systems & storage
Database indexes, cache policies, query operators, sharding, and external-memory algorithms.
Builds on
1 topic
Read these first if you want the surrounding context.
Unlocks
0 next topics
Use these follow-ups when you want to apply the current idea in a richer setting.
Learning paths
2
This topic appears in curated progressions so you can keep moving without guessing the next step.
Choose this over that
Range-scan workloads are where B+ Trees separate themselves
Once the problem becomes "route quickly, then scan in order," the linked-leaf design pays for itself.
B-Tree
Choose this when: You want the underlying page-aware tree mechanics without specializing the leaf layout yet.
Choose something else when: Ordered scans are a first-class workload.
B+ Tree
Choose this when: Database-style point lookups and range scans both matter, and sequential leaf traversal is valuable.
Choose something else when: The workload is overwhelmingly write-heavy.
LSM Tree
Choose this when: Write buffering, SSTables, and compaction are a better fit than eagerly updating a page index.
Choose something else when: Predictable scan behavior and point reads matter more.
Problem
Database indexes usually need both:
- fast point lookups
- fast ordered range scans
A plain B-Tree already reduces page depth, but a B+ Tree sharpens the layout for the exact access pattern databases care about most.
Intuition
A B+ Tree separates routing from storage.
- internal nodes store only separator keys
- all actual records live in the leaves
- leaves are linked in sorted order
That last property is the game changer. After finding the first matching key, a range scan can continue by following leaf pointers instead of repeatedly climbing back through the tree.
Search
Search looks almost identical to a B-Tree search, except internal nodes never hold the final records.
search(node, key):
while node is not a leaf:
choose the child interval containing key
node <- chosen child
binary search inside the leaf
return matching record if present
The internal nodes are just a page-efficient routing index.
Insertion
Insert into a leaf
insert(tree, key, record):
leaf <- find_leaf(tree.root, key)
insert (key, record) into leaf in sorted order
if leaf overflowed:
split_leaf(leaf)
Split a leaf
split_leaf(leaf):
newLeaf <- new leaf
move upper half of entries from leaf into newLeaf
newLeaf.next <- leaf.next
leaf.next <- newLeaf
separator <- first key in newLeaf
insert separator into parent routing node
The promoted separator is just a routing key. The records stay in the leaves.
Split an internal node
If a parent overflows after receiving the separator, split that internal node as well and continue upward just like in a B-Tree.
Range scan
Range scans are where B+ Trees really justify themselves.
range_scan(L, R):
leaf <- find first leaf that could contain L
while leaf exists:
for entry in leaf in sorted order:
if entry.key < L:
continue
if entry.key > R:
return
emit entry
leaf <- leaf.next
Once the first leaf is found, the scan becomes mostly sequential leaf traversal.
Worked example
Suppose you want all keys in [30, 60].
- descend through internal routing nodes until you reach the first leaf containing
30 - emit all matching entries in that leaf
- continue through
leaf.next,leaf.next.next, and so on - stop when keys exceed
60
This is exactly why B+ Trees dominate ordered indexes: range queries become natural and page-friendly.
Complexity
| Operation | Time |
|---|---|
| Point lookup | O(log_B n) page levels |
| Insert | O(log_B n) |
| Delete | O(log_B n) |
| Range scan after first hit | sequential over touched leaves |
The first lookup is logarithmic. The scan that follows is efficient because the leaves are already linked in key order.
B-Tree vs. B+ Tree
| Property | B-Tree | B+ Tree |
|---|---|---|
| Internal nodes | May store records or keys | Store routing keys only |
| Leaves | Not the only place records may appear | Hold all records |
| Range scans | Fine | Excellent |
| Internal fanout | Good | Often even better because nodes hold only separators |
By pushing records to the leaves, a B+ Tree often fits more separators per internal page and therefore stays even shallower.
Key takeaways
- A B+ Tree is a B-Tree optimized for point lookup plus ordered scan workloads.
- Internal nodes route; leaves store the real data.
- Leaf links are what turn the structure into a first-class range-scan index.
- Splitting a leaf promotes a separator upward but keeps the records in the leaves.
- If you hear “database index,” this is usually the mental model to reach for first.
Practice problems
| Problem | Difficulty | Key idea |
|---|---|---|
| B+ Tree overview | Hard | Leaf-linked page-friendly ordered index |
| Use The Index, Luke | Hard | Why ordered indexes matter for query planning |
| CockroachDB index overview | Hard | Practical B-tree and B+ tree trade-offs |
Relation to other topics
- B-Tree provides the page-aware balanced-search foundation.
- External Merge Sort complements B+ Trees because both optimize ordered sequential access.
- LSM Tree is the major storage-engine alternative when writes dominate strongly enough to justify compaction-heavy design.
Build on these first
These topics supply the mental model or underlying structure that this page assumes.
Related directions
These topics live nearby conceptually, even if they are not direct prerequisites.
Tree Fundamentals
Understand roots, parents, children, depth, height, and traversal orders. A tree is a graph with enough structure to make many problems much simpler.
Binary Search Tree (BST)
A sorted tree structure enabling O(log n) search, insert, and delete. Foundation for balanced trees, sets, and maps.
Binary Search
Halve the search space at every step. Binary search is not just for sorted arrays — it's a general technique for any monotonic predicate.
External Merge Sort
Sort data larger than RAM by generating sorted runs and merging them with mostly sequential disk I/O.
More from Systems & storage
Stay in the same family when you want parallel variations of the same mental model.
B-Tree
Store many keys per node so ordered search stays shallow and expensive page reads stay low.
Cache Eviction Strategies (LRU, LFU, ARC, TinyLFU)
Treat cache eviction as an algorithm choice: recency, frequency, adaptation, and admission all optimize different workloads.
Consistent Hashing
Map keys onto a ring so cluster membership changes move only nearby keys instead of reshuffling the whole keyspace.
External Merge Sort
Sort data larger than RAM by generating sorted runs and merging them with mostly sequential disk I/O.
Paths that include this topic
Follow one of these sequences if you want a guided next step instead of open-ended browsing.
Ordered structures
See how order can come from sorted arrays, search trees, skip lists, disk-friendly indexes, heaps, and prefix trees.
Storage engines
Compare fanout-heavy indexes, write-optimized trees, and external-memory sorting in one storage-oriented path.
From the blog
Pair the atlas with recent writing from the rest of the site when you want a broader engineering perspective alongside the topic graph.