Notes on how databases actually work.
This blog is organized in series. The first one is about FoundationDB: it follows a transaction from start to finish and uses that path to explain how the system fits together. More series will follow.
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 any transaction older than five seconds. 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: 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.