Skip to content

B-Tree

Maintain a balanced, ordered, multiway search tree whose high-fanout nodes align with storage blocks, keeping lookup and dynamic updates logarithmic with few block accesses.

Version
v2 · 2026-09-06 · History
Domain-specific #
1332
Origin domain
computer science
Subdomain
external memory data structures
Aliases
B-tree

Core Idea

A B-tree is a balanced multiway search tree designed to keep an ordered dynamic index shallow. Each node stores several sorted separator keys and several child references, so one visited node eliminates a large region of the search space. Except for a specially treated root, nodes satisfy lower and upper occupancy bounds, and all leaves occur at the same depth. Search follows separators downward; insertion and deletion split, redistribute, or merge nodes to restore those invariants.

The abstraction arose from the cost structure of external storage. When a node is sized to a disk page or another transfer block, one node access retrieves many keys and child pointers. High fanout dramatically reduces height and therefore the number of expensive block transfers. Bayer and McCreight's original paper analyzes retrieval, insertion, deletion, storage utilization, and page-size-dependent performance for dynamic large ordered indexes.[1]

The B-tree is not merely any balanced tree. Its identity couples sorted multiway branching, occupancy constraints, equal leaf depth, and local rebalancing with a block-oriented performance objective. Variants alter where records live, how siblings are linked, or how underfull nodes are tolerated, but this invariant package remains the reference point.

Structural Signature

  • ordered key domain — keys admit a total search order or a comparator with equivalent behavior;
  • multi-key nodes — each node stores an ordered set of separator keys;
  • child intervals — children correspond to key ranges partitioned by the separators;
  • capacity parameter — an order, minimum degree, or lower/upper fanout convention fixes legal occupancy;
  • root exception — the root may contain fewer keys or children than other internal nodes;
  • uniform leaf depth — every search path reaches a leaf at the same level;
  • search descent — in-node search selects either a matching key or one range child;
  • split and promotion — overflowing nodes divide and promote a separator toward the root;
  • redistribution, borrowing, or merge — deletion repairs underflow while preserving order and balance;
  • block alignment — node capacity is chosen to amortize each external-memory or cache transfer across many comparisons.

Under a common minimum-degree convention (t), nonroot nodes contain between (t-1) and (2t-1) keys, internal nodes have one more child than key, and the height is logarithmic in the number of keys. Other textbooks use “order” differently, so a sound specification states its convention rather than relying on the word alone.

What It Is Not

  • Not the generic Tree (Data Structure). The catalog parent includes arbitrary rooted hierarchical structures; a B-tree imposes ordered keys, multiway search, occupancy, uniform depth, and dynamic repair.
  • Not a binary search tree. B-tree nodes can have many children and are optimized around blocks, not one key per binary branching point.
  • Not a B+ tree. In a B+ tree, records or record pointers are ordinarily concentrated in linked leaves and internal nodes function as routing indexes.
  • Not a B-tree in graph-theoretic notation. The name is a historical data-structure term, not a generic tree named by a variable.
  • Not a hash index. Hashing targets direct key lookup and does not normally preserve sorted traversal or range search.
  • Not automatically the best in-memory index. Cache behavior, concurrency, workload, and hardware may favor another structure.

Scope of Application

B-trees and close variants are foundational in database indexes, file-system metadata, key-value stores, and storage engines. They support exact lookup, ordered iteration, predecessor/successor queries, range scans, insertion, and deletion while data exceed fast memory. Their design applies whenever transfer latency dominates comparison cost and a large node can be fetched as one unit.

The abstraction also remains useful in memory because cache lines and pages create hierarchy even without rotating disks. Production implementations may add prefix compression, fence keys, sibling links, latches, copy-on-write, write-ahead logging, or optimistic concurrency. Those are engineering extensions around the ordered, balanced, high-fanout core.

Workloads dominated by append-only access, pure point queries, immutable data, or specialized hardware may use log-structured merge trees, hashing, learned indexes, tries, or cache-oblivious structures instead. Scope is determined by the required operations and cost model, not by the fact that an application stores records.

Clarity

Terminology is a recurring trap. Some sources define order as maximum children; others use it for minimum keys or a related branching parameter. “Leaf” may mean the lowest key-bearing node or an external data object below it. A B-tree specification should therefore state capacities as explicit inequalities and state whether values reside in all nodes or only at leaves.

The easiest membership test has four parts. Are keys ordered within nodes? Do separators partition ordered child ranges? Do all leaves share one depth? Do insertions and deletions restore occupancy through local structural changes? If any answer is no, the structure may be another multiway tree but not the canonical B-tree abstraction.

Balance here is strong: path length is uniform by level, not merely bounded on average. Occupancy is also structural, not a tuning suggestion. Root exceptions allow the tree to grow and shrink without violating the lower bound everywhere else.

Manages Complexity

A naive ordered file makes insertion expensive; a binary tree stored externally can require many random block reads. The B-tree packages many branching decisions into one node. If a node has hundreds of children, a very large index can have only a few levels. Search then becomes a small number of block transfers plus in-node comparisons.

Dynamic updates are localized. Overflow triggers a split that may propagate upward; underflow triggers borrowing or merging that may propagate toward the root. Global sort order and uniform depth survive without rebuilding the entire index. Minimum occupancy also prevents the tree from degenerating into mostly empty pages under ordinary invariants.

The abstraction separates correctness from policy. Correctness requires ordering, range partition, occupancy, and balance. Implementations can choose page size, in-node search, fill factor, split bias, concurrency control, logging, and record placement according to workload.

Abstract Reasoning

Search-path proof. At each internal node, separators identify exactly one child interval that can contain the key. Induction on height proves correctness.

Height bound. Use minimum occupancy to bound the smallest number of keys representable at height (h). Invert that exponential growth to obtain logarithmic height.

Insertion invariant. Split a full child before descending or repair after insertion, promote a median separator, and show that sorted ranges and occupancy remain valid.

Deletion invariant. Before descending into a minimally occupied child, borrow from a sibling or merge when appropriate, ensuring that later removal does not leave an illegal nonroot node.

I/O analysis. Count node transfers rather than only comparisons. Height dominates external-memory cost, while in-node search and caching determine secondary costs.

Variant comparison. Compare B-tree, B+ tree, B* tree, and copy-on-write versions by record placement, occupancy target, scan support, update amplification, and concurrency—not name similarity alone.

Knowledge Transfer

The design transfers across storage substrates because “block” can mean a disk page, flash page, virtual-memory page, cache-friendly slab, or network/storage transaction. The particular optimum changes, but high fanout plus maintained balance remains useful.

The more abstract lessons—align data structures with transfer granularity, preserve invariants through local repair, and trade in-node work for fewer hierarchy levels—travel beyond B-trees. Those lessons belong to broader primes such as index and hierarchical_decomposability. The literal B-tree remains domain-specific because keys, child pointers, occupancy, search order, and update algorithms are indispensable.

Examples

Database primary index. Pages contain separator keys and child page identifiers. A lookup visits the root, perhaps one cached internal page, and a leaf holding or locating the row.

Range scan. Search first locates the low endpoint. In a B+ variant, linked leaves then yield successive records without returning to upper levels.

Insertion split. Adding a key fills a leaf beyond capacity. The leaf divides, a separator rises into its parent, and a root split increases tree height by one while all leaves remain level.

Deletion merge. Removing a key leaves a node below minimum occupancy. A sibling cannot lend, so two nodes merge with a parent separator; repair may propagate upward and can shrink the root.

Structural Tensions

T1: High fanout versus in-node work. Large nodes reduce height but require more searching and movement inside a node. Diagnostic: optimize against actual transfer and CPU costs.

T2: Dense occupancy versus update headroom. Full pages save space and depth but split more readily. Diagnostic: choose fill policy from workload and write cost.

T3: Read locality versus write amplification. Rebalancing preserves search shape while rewriting pages. Diagnostic: measure update path and persistence mechanism.

T4: Simple invariants versus concurrency. Splits and merges touch multiple nodes. Diagnostic: specify latch, version, or copy-on-write protocol separately from sequential correctness.

T5: General form versus variant semantics. Calling every related index a B-tree hides important record-placement and scan differences. Diagnostic: state the exact variant.

T6: Logical balance versus physical fragmentation. A perfectly balanced logical tree can still be scattered on storage. Diagnostic: evaluate allocation and locality in addition to height.

Structural–Framed Character

B-Tree is structural. Membership and correctness are determined by formal ordering, range, occupancy, and balance invariants. Workload assumptions frame parameter choice and whether the structure is advantageous, but they do not alter whether a given tree satisfies its definition.

Structural Core vs. Domain Accent

The structural core is a bounded-capacity, balanced, ordered hierarchy repaired locally under updates. The domain accent is data indexing: keys, records, pages, child pointers, comparison search, and block-transfer cost. The catalog already contains the generic Tree (Data Structure); B-Tree is a strict, important specialization rather than a new prime.

  • tree_data_structure: B-Tree strictly specializes the generic rooted data hierarchy.
  • index: the structure maps ordered keys to records or child ranges for efficient access.
  • hierarchical_address: separator paths progressively narrow the addressed key interval.
  • abstract_data_type: search, insertion, deletion, and traversal can be specified independently of representation.
  • hierarchical_decomposability: ordered space is recursively partitioned into manageable ranges.

Relationships to Other Abstractions

Local relationship map for B-TreeParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.B-TreeDOMAINDomain-specific abstraction: Tree (Data Structure) — is a kind ofTree (DataStructure)DOMAIN

Current abstraction B-Tree Domain-specific

Parents (1) — more general patterns this builds on

  • B-Tree is a kind of Tree (Data Structure) Domain-specific

    tree_data_structure: B-Tree strictly specializes the generic rooted data hierarchy.

Neighborhood in Abstraction Space

B-Tree sits in a sparse region of the domain-specific corpus (90th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With

  • binary search tree, AVL tree, or red-black tree;
  • B+ tree or B* tree without stating the variant;
  • R-tree for spatial bounding regions;
  • hash table or hash index;
  • generic multiway tree lacking search and occupancy invariants;
  • the catalog's Tree (Graph Theory) or Tree (Set Theory) nodes.

References

[1] Bayer, Rudolf, and Edward M. McCreight. “Organization and Maintenance of Large Ordered Indexes.” Acta Informatica 1 (1972): 173–189. registry