Skip to main content
Back to the DSA atlas
Systems & storage Data structure Advanced

B+ Tree

Keep routing keys in internal nodes and all records in linked leaves so point lookups stay shallow and range scans stay fast.

b-plus-treedatabaseindexrange-scan

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.

[1, 3, 5]
->
[7, 9, 12]
->
[15, 18, 21]

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.

Systems & storage Open topic

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.

Current topic

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.

Systems & storage Open topic

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 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].

  1. descend through internal routing nodes until you reach the first leaf containing 30
  2. emit all matching entries in that leaf
  3. continue through leaf.next, leaf.next.next, and so on
  4. stop when keys exceed 60

This is exactly why B+ Trees dominate ordered indexes: range queries become natural and page-friendly.

Complexity

OperationTime
Point lookupO(log_B n) page levels
InsertO(log_B n)
DeleteO(log_B n)
Range scan after first hitsequential 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

PropertyB-TreeB+ Tree
Internal nodesMay store records or keysStore routing keys only
LeavesNot the only place records may appearHold all records
Range scansFineExcellent
Internal fanoutGoodOften 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

ProblemDifficultyKey idea
B+ Tree overviewHardLeaf-linked page-friendly ordered index
Use The Index, LukeHardWhy ordered indexes matter for query planning
CockroachDB index overviewHardPractical 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.

More from Systems & storage

Stay in the same family when you want parallel variations of the same mental model.

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.