FoundationDB, the Black Knight
summary
A FoundationDB cluster on Kubernetes with 72 storage processes plus 16 stateless and 12 logs runs a Go YCSB benchmark at 50k QPS on a half terabyte dataset that expands to 1.3 TB on disk and survives repeated storage pod failures with no full rebuild when volumes return, recovers from all-storage crashes within about a minute, and stalls 5 seconds on single log loss or about 3 minutes when all logs die; the system enforces a 5 second transaction limit, supports many‑to‑many rebalancing, continuous backups to object storage with subminute lag, and a DR utility that flips replication direction in seconds.
AI-written summary · about
chapters (17)
- 0:00Introduction to FoundationDB and the Black Knight analogy
- 2:27Agenda
- 3:10Microservices architecture
- 4:57Limitations at scale
- 7:24Kubernetes and Tigris Data
- 9:09Failure handling
- 10:33Storage redundancy
- 14:27Test cluster setup
- 16:17Single pod recovery
- 16:59Multiple pod failures
- 19:06Catastrophic failure recovery
- 20:55Log process failures
- 23:23Recovery without operator
- 24:26Zones and fault domains
- 27:18Cluster size optimization
- 28:45Backups and disaster recovery
- 31:16Global replication
related talks
16mFoundationDB and Node.js: Year in Production
46mFoundationDB: The Best-Kept Secret of New Distributed Architectures!
37mTechnical Overview of FoundationDB
22mSolving Everyday Data Problems with FoundationDB
26mRunning FDB at scale at Wavefront
18mFoundationDB Record Layer: Open Source Structured Storage on FoundationDB
22mHow FoundationDB powers SnowflakeDB's metadata!
15mTime Series and FoundationDB: Millions of Writes/s and 10x Compression in 2000 Lines of Go