Inside DBs · Ricardo Jimenez-Peris

Deep dives into database systems: how production engines work, why they are designed that way, and what changes when their limits are pushed.

The current series explores FoundationDB from two complementary directions. It first follows a transaction from start to finish to explain how the distributed system fits together. Beyond 5s then turns that understanding into original systems work, redesigning the mechanisms behind FoundationDB’s five-second transaction window—from read-version management and conflict history to storage retention. More systems and series will follow.

The series' tree, green and flowering on one side and amber on the other, with a sundial at its foot and a small temple whose pediment reads BY5

Resolver v3: a temporal B+ tree for FoundationDB's conflict history, from routing to reclamation

FoundationDB rejects a transaction once its read version is more than five seconds old because the resolver keeps only that much write history. Resolver v3 replaces that history with a temporal B+ tree under a memory budget and processes each batch in two phases: one descent routes every read and write begin together and checks the reads, then the accepted writes are applied in key order by cooperative tasks that search and prefetch ahead of a single writer. Under the same 6 GiB budget, final v3 retains 582.9–584.7 seconds of conflict history in the measured tail—2.20× FoundationDB’s calibrated 265-second window. The 5,400-second trace replays in 0.77× FoundationDB’s time on Intel and 0.94× on AMD, each the median of two opposite-order pairs, with every decision and the same retention curve on both machines. Every published v3 performance run verifies that the complete pool is in HugeTLB pages.

The series' tree inside a hall of gilded mirrors: green and flowering on one side, amber on the other, a sundial and crates of fallen leaves at its foot, four squirrels running along glowing routes that part at each fork, and the whole scene repeated smaller and smaller in the mirrors on every side

Resolver v2: recursive partitioning, grouped reads, and prefetching in the temporal B+ tree

Resolver v2 delivers about 2.1× v1’s point-read throughput and 1.5× its range-read throughput in the Intel standalone benchmark. In a synthetic 10,000-read example with uniformly distributed begins, recursive partitioning reduces internal-node routing comparisons by 56%; including the initial leaf searches, the total comparison count falls by 44%. Grouped reads also share predecessor lookup and avoid repeating resolved begin comparisons during the leaf scan. Prefetching brings upcoming nodes and keys toward the cache while other tasks advance, creating distance between each hint and its use to hide memory latency. Writes remain sequential.

A tree shaped like a B+ tree: a short trunk, a few thick branches and a flat, dense canopy; the leaves grow green on one side, turn amber toward the other and fall into identical crates beside a sundial

Resolver v1: a temporal B+ tree for FoundationDB's conflict history

FoundationDB keeps conflict history for five seconds. Resolver v1 keeps it under a memory budget instead, in a temporal B+ tree whose nodes and key bytes share one pool. Under 6 GiB it retains 2.2× the history of the original skip list, at 2.7× the resolution time; this post explains the design and the measurement.

Beyond 5s: extending FoundationDB past its five-second window

FoundationDB rejects a transaction once its read version is more than five seconds old. Beyond 5s replaces that fixed window with budgets, component by component: the resolver’s conflict history, the storage server’s version retention, and the protocol that coordinates them. This page lists the milestones in order.

An isometric city where a transaction travels FoundationDB's commit path: GRV proxy, commit proxy, resolvers, TLogs and storage servers

FoundationDB: the architecture, seen through a transaction

FoundationDB separates transaction processing from storage. Rather than list its components, this post follows a single transaction through them, from the moment it starts to the moment its writes become readable.