FoundationDB rejects any transaction that tries to read or commit more than five seconds after it obtained its read version. The limit is not in the transaction model; it comes from how long two components keep the history that an older transaction needs. Resolvers keep the write-conflict history used to validate commits, and storage servers keep the old versions of the data that a read at an old version must still see. Both keep it for a fixed window, whatever the memory available.
Beyond 5s replaces the window with a budget. Each component retains history under a configured memory budget and discards the oldest entries only when space is needed; a transaction completes as long as the history it needs is still retained, and is rejected as too old otherwise. The work proceeds one component at a time, and each milestone is published with its design as implemented, its decision record, its journal and its measured result.
Milestones
Resolver v1: a temporal B+ tree for conflict history (October 2026). The resolver’s history rebuilt as a B+ tree of disjoint intervals under a memory budget, with nodes and key bytes sharing one block pool, proactive splits and generation-checked reclamation. Under 6 GiB it retains 2.2× the history of the original skip list, at 2.7× the resolution time of the sequential first version. Read the article.
Next: grouped read checks with selective prefetch in the resolver; then version retention in the storage server; then the protocol that coordinates both with the transaction’s read version.
Where things live
The design and milestone snapshots are in one repository: design/ holds the current design of each component, and each milestone is an immutable snapshot under its component. The code is published in a FoundationDB fork, tagged per milestone and linked from each snapshot’s evidence register. Articles on this site are the readable account of each milestone and cite the snapshot they describe.