explaingit

apple/foundationdb

16,317C++Audience · developerComplexity · 5/5Setup · hard

TLDR

An open-source distributed database from Apple that delivers full ACID transactions across a cluster of servers, the same reliability guarantees as a single-server database but at distributed scale.

Mindmap

mindmap
  root((repo))
    What it does
      Distributed database
      ACID transactions
      Key-value store
    Design
      Ordered key-value
      Multi-server cluster
      Read and write heavy
    Tech
      Written in C++
      Simulation testing
      Language bindings
    Use cases
      Distributed app data
      High reliability
      Custom data models
Click or tap to explore — scroll the page freely

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

Things people build with this

USE CASE 1

Use as the reliable data layer for a distributed app that needs ACID transactions at scale.

USE CASE 2

Store large volumes of structured data across multiple servers with no single point of failure.

USE CASE 3

Build higher-level data models like a document or graph store on top of FoundationDB key-value primitives.

USE CASE 4

Test distributed systems correctness using FoundationDB's simulation-based fault injection approach.

Tech stack

C++PythonJavaGoRuby

Getting it running

Difficulty · hard Time to first run · 1day+

Requires compiling from C++ source and setting up a multi-server cluster, not a quick local-dev install.

In plain English

FoundationDB is an open-source distributed database released by Apple. It stores data as an ordered key-value store (imagine a giant sorted dictionary where each entry has a key and a value) and is designed to run across clusters of multiple servers, handling large volumes of structured data reliably. Its defining characteristic is full ACID transactions across the entire distributed cluster. ACID (Atomicity, Consistency, Isolation, Durability) is a set of guarantees that ensure database operations either complete fully or not at all, data stays valid, concurrent operations don't interfere with each other, and committed data persists through crashes. Most distributed databases compromise on some of these guarantees for speed, FoundationDB does not. It is particularly well-suited for read-heavy and write-intensive workloads. Applications talk to it through official API bindings in various programming languages rather than a query language like SQL. This architecture lets you build higher-level data models on top of the key-value primitives while retaining strong consistency guarantees. FoundationDB is written primarily in C++ and uses a simulation-based testing approach, meaning it runs simulated versions of hardware failures, network partitions, and other failure scenarios to validate correctness before any code ships. You would use FoundationDB as the reliable data layer underneath a larger system when you need both distributed scalability and strict transactional consistency. The full README is longer than what was provided.

Copy-paste prompts

Prompt 1
How do I set up a FoundationDB cluster on three servers and write my first ACID transaction using the Python client?
Prompt 2
Show me how to build a simple document store on top of FoundationDB using key-value primitives in Python.
Prompt 3
Walk me through FoundationDB's simulation-based testing approach and how to write a test for a distributed failure scenario.
Prompt 4
How does FoundationDB handle concurrent writes from multiple clients without causing conflicts or data loss?
Prompt 5
I want to build a graph data model on top of FoundationDB, what key encoding strategy should I use for edges and adjacency lists?
Open on GitHub → Explain another repo

← apple on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.