FoundationDB

What it is

FoundationDB is a distributed key-value store that provides ACID transactions across the entire cluster, including multi-key and multi-shard operations. It's built as a layered architecture: the core is an ordered key-value store, and everything else (document stores, SQL, record layers) gets built on top via client-side "layers." No native query language, no built-in indexing beyond key ordering — you build what you need.

It scales horizontally, tolerates machine and datacenter failures without losing consistency, and is written in C++. Apple's CloudKit runs on it, which tells you something about its production track record even though the vendor description here is "not publicly available."

Who builds it and why

Originally developed by a startup of the same name, acquired by Apple in 2015. Apple open-sourced it in 2018 (Apache-2.0) and has continued driving development since — most of the core team and commit volume trace back to Apple engineers, though the contributor base (357 on GitHub) has broadened over time. The motivation isn't community-first the way some CNCF projects are: it exists because Apple needed a database that could back CloudKit at planet scale without sacrificing correctness, and open-sourcing it means external users get the benefit of that investment (and Apple gets external testing and contributions in return).

CNCF maturity level is not publicly available in the data provided — check the CNCF landscape directly if you need this for a compliance or vendor-selection checklist.

Production readiness signal

The GitHub numbers are solid: 16,461 stars, 357 contributors, and a commit as recent as 2026-06-30 — this is an actively maintained project, not something coasting on past reputation. Latest release is 7.3.69, indicating a mature, incrementally-versioned release line rather than a project still finding its API.

The bigger signal, though, is architectural: FoundationDB is built and tested using deterministic simulation — the entire distributed system runs in a single-threaded simulator that can inject failures (network partitions, disk corruption, process kills) at every possible interleaving. This is unusual rigor for a database and is a major reason it's trusted for CloudKit-scale workloads. Founding date is not publicly available, but the project has been in production at Apple since well before its 2018 open-sourcing.

Who should use this

• Teams building infrastructure that needs strong consistency and multi-key transactions at scale — metadata stores, control planes, distributed locking/coordination systems.
• Teams comfortable building or adopting a layer (document, relational-ish, queue) on top rather than getting a ready-made database experience out of the box.
• Organizations that need proven correctness under partition and failure scenarios more than they need convenience features.
• Teams with C++/systems engineering capacity to operate and potentially patch a lower-level distributed system.

Who should NOT use this

• Teams wanting a drop-in SQL or document database with minimal setup — FoundationDB is a substrate, not an app-ready database. Use Postgres, MongoDB, or a managed layer instead.
• Small teams without dedicated ops/infra expertise — cluster tuning, layer selection, and failure recovery require real distributed-systems know-how.
• Anyone needing rich native querying, secondary indexing, or full-text search out of the box — you'll be building that yourself.
• Projects wanting an active, large-scale open community roadmap — direction is still heavily Apple-influenced, which is fine but worth knowing going in.

Alternatives

• CockroachDB — SQL-native distributed database with similar consistency guarantees but a much friendlier out-of-box query experience.
• TiKV — CNCF-graduated distributed key-value store, closer in spirit to FoundationDB's core layer, backed by a broader community (PingCAP/community-driven).
• Cassandra — if you can tolerate eventual consistency instead of strict ACID, gets you horizontal scale with far less operational complexity for certain workloads.

Pricing

Fully open source under Apache-2.0. No paid tier, no vendor lock-in for the core software. You pay in engineering time to operate it and build layers — there's no managed FoundationDB-as-a-service from Apple or the core team; any hosting is third-party or self-managed.