Foundationdb

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, v3.8 retains at least 582.9 seconds of conflict history after reclamation begins—2.20× FoundationDB’s calibrated 265-second window. The 5,400-second trace replays in 0.76× FoundationDB’s time on Intel and in comparable time on AMD. These timing comparisons cross sessions: v3.8 used HugeTLB pages, while the archived references used ordinary memory.

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.

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.

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.

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.