# FoundationDB: an ordered key-value store with ACID transactions across commodity servers > FoundationDB is Apple's open source distributed key-value store. It exposes ordered keys and serializable ACID transactions through language bindings, and the repository points to binaries, a Docker build image and a documented upgrade ladder rather than a query language. **apple/foundationdb** — FoundationDB - the open source, distributed, transactional key-value store - Repository: https://github.com/apple/foundationdb - Website: https://apple.github.io/foundationdb/ - Stars: 16,744 · Forks: 1,582 - Language: C++ - License: Apache-2.0 - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/apple-foundationdb ## The problem FoundationDB solves, and who it is for Most teams that reach for FoundationDB have already hit the ceiling of a single-node store and do not want to take on query planning, replication and transaction coordination at the same time. The README describes the project as "a distributed database designed to handle large volumes of structured data across clusters of commodity servers" that "organizes data as an ordered key-value store and employs ACID transactions for all operations." Those two properties, ordering and serializable transactions, are the whole pitch. Everything else is an implementation detail you inherit. The audience is narrower than the tagline suggests. You are expected to interact through API language bindings, not a query console. That means the schema, the encoding of keys, the secondary indexes and the access patterns are your code. A team that wants to declare a table and issue SQL is not the target reader. A team building a metadata service, a queue, a ledger or a multi-tenant application layer on top of a transactional substrate is. The repository itself hints at this split: there is a layers/ directory for higher-level data models, and the related searches around the Record Layer point at exactly that pattern. The README also claims the store is "especially well-suited for read/write workloads, but also has excellent performance for write-intensive workloads." Treat that as the project's own framing rather than a measured result. The useful takeaway is that the design does not assume a read-heavy cache workload the way a plain replicated key-value store might. ## How the cluster is put together: fdbmonitor, fdbserver and the client bindings The architecture is visible in the repository layout, and it is worth reading before you install anything. The top level splits into fdbclient/, fdbserver/, fdbrpc/, flow/, fdbmonitor/, fdbcli/, fdbbackup/, fdbkubernetesmonitor/ and bindings/. That is a reasonably honest map of the system. flow/ is the actor-based programming model and the network layer that the rest of the code is written against. fdbrpc/ carries the remote procedure calls that servers and clients use to talk to each other. fdbserver/ is the storage and transaction process. fdbmonitor/ is the process supervisor that keeps those server processes alive and reads a local configuration. fdbclient/ is the client library that your application links against, and bindings/ holds the per-language wrappers over it. A cluster is identified by a cluster file, and the repository ships fdb.cluster.cmake, which tells you the cluster file is generated or templated as part of a deployment rather than being a fixed artifact. Clients point at that file to discover the coordination layer. You do not address individual storage nodes from application code, and the documentation does not present a sharding API for you to manage. The ordered key space is partitioned by the system, and transactions are coordinated so that all operations in a transaction either commit or do not. The practical consequence is that your data model is a sorted key space. Range reads are the natural access pattern, which is why the layers/ directory exists: a relational model, a document model or a queue is a mapping from your objects onto ordered keys plus whatever indexing discipline you maintain. The store gives you the transaction; the model is yours. ## Building FoundationDB from source and taking a first look at a cluster The README is explicit that most users should start from a binary package: "Developers interested in using FoundationDB can get started by downloading and installing a binary package," pointing at the releases page. Compiling from source is presented as the path for operating systems without a package, or for people who want to work on the code itself. If you do build, the project recommends its own container image rather than a bare host, because the dependency list is long. The README says the Docker image `foundationdb/build` "includes all necessary dependencies" and is "the recommended method of building FDB." The clang invocation in the README looks like this: ```bash mkdir /some/build_output_dir cd /some/build_output_dir CC=clang CXX=clang++ LD=lld cmake -D USE_LD=LLD -D USE_LIBCXX=1 -G Ninja /some/fdb/source_dir ninja ``` Building on a host instead requires CMake 3.24.2 or higher, Mono and ninja, and the README warns that this list "is likely to be incomplete." It also states that a build needs at least 8GB of memory, and that if the machine freezes you should fall back to `ninja -j1`. For local development the README asks you to pass `-DUSE_WERROR=ON` so that compiler warnings surface the same way they do in CI. The FreeBSD instructions in the README are the most complete local build recipe in the repository, and they show the shape of a real build plus test run: ```shell sudo pkg install -r FreeBSD \ shells/bash devel/cmake devel/ninja devel/ccache \ lang/mono lang/python3 \ devel/boost-libs devel/libeio \ security/openssl mkdir .build && cd .build cmake -G Ninja \ -DUSE_CCACHE=on \ -DUSE_DTRACE=off \ .. ninja -j 10 ctest -L fast ``` The optional steps note that a JDK is needed for Java bindings, and that FoundationDB "currently builds with Java 8." The README does not document a `fdbcli` session, so the first real interaction with a running cluster is not spelled out there; the `fdbcli/` directory in the tree is where that tool lives. ## Where FoundationDB is the wrong choice The most common mismatch is expecting a database rather than a substrate. There is no query planner, no joins and no schema enforced by the server. If your team's questions arrive as ad hoc SQL, you will spend the first months writing a layer that another product ships in the box. The layers/ directory is the acknowledgement that this work is expected, not a sign that it has been done for you. The second mismatch is operational. The README's release table divides branches into Supported, Bug fixes, Experimental and Unsupported, and the Experimental rows are the ones "used for internal feature testing" and "not recommended for production use." A team that tracks whatever branch looks newest will end up on a branch the project does not stand behind. The same table also implies a lifecycle: 6.3 is listed as Unsupported, so running an old release is not a neutral choice. Upgrades are the third constraint, and the README is unusually direct about it. The recommended path is sequential through major versions, for example 6.2.X to 6.3.25 to 7.1.57 to 7.3.69, and the README states that "skipping a major release, not marked as Experimental, for an upgrade is only tested in simulation." If your deployment process cannot walk through intermediate versions, this is a real cost. Finally, the client-side story is bindings, not a wire protocol you can speak from anything. The bindings/ directory and the SWIFT_GUIDE.md and SWIFT_IDE_SETUP.md files at the top level show that language support is an active surface. A language without a maintained binding is a language you would be writing one for. ## How FoundationDB differs from PostgreSQL, MongoDB and etcd Against PostgreSQL, the difference is where the intelligence lives. PostgreSQL gives you a single-node relational engine with a query planner and a well-known replication story. FoundationDB gives you a distributed ordered key space with transactions and no query layer. If your data fits comfortably on one machine and you want SQL, PostgreSQL is the shorter path; if you have outgrown one machine and still want SQL, you are looking at adding a layer on top of FoundationDB or choosing a distributed SQL system instead. Against MongoDB, the axis is the data model and the consistency surface. MongoDB presents documents and a query language; FoundationDB presents bytes in sorted order and expects you to encode documents yourself. The related searches comparing the two suggest people are weighing a document API against a transactional key-value core. Those are not interchangeable starting points, because the migration in either direction means rewriting the access layer. Against etcd, the difference is scope. etcd is a coordination store, and the design centers on a small, strongly consistent key space used for configuration and leader election. FoundationDB is built for large volumes of structured data across commodity servers, per the README, with a backup tool (fdbbackup/) and a Kubernetes monitor (fdbkubernetesmonitor/) in the tree. Using etcd as a general data store and using FoundationDB as a lock service both work, but each is paying for machinery it is not using. Against a purely local embedded store such as RocksDB, the difference is that FoundationDB is a cluster with replication and transaction coordination, while an embedded store is a library inside your process. The comparison is only interesting if you are considering building the cluster layer yourself, which is the work FoundationDB has already done. ## Maintenance, releases and what the licence means in practice The repository is not archived, and the last push was on 2026-09-20. Recent releases include 7.4.7 on 2026-09-01, plus 7.3.79 and 7.3.78 on 2026-07-15. The README's own table marks 7.3 as Supported, 7.1 as accepting bug fixes, and 6.3 as Unsupported, so the branch you pick determines whether you get patch releases at all. The upgrade cost is the maintenance cost. Because the README recommends stepping through each major release and notes that skipping one is only tested in simulation, an upgrade is a sequence of cluster operations rather than a single binary swap. Teams that pin a version and defer upgrades accumulate a longer chain to walk later. The release cadence visible in the repository, with 7.4.x and 7.3.x both receiving builds, suggests parallel maintenance rather than a single moving target, which reduces the pressure but does not remove the sequencing requirement. On licensing, the repository is Apache-2.0. That is a permissive licence, and it is the same identifier you will find in the LICENSE file at the top level. What it does not tell you is anything about the operational services around the project, the hosted offerings some teams use, or the terms of any binary package you download; those are separate questions and this article is not legal advice. If your organization has a policy on permissive licences, Apache-2.0 is the fact to bring to that review. ## Conclusion Adopt FoundationDB when you need ordered keys and serializable ACID transactions across a cluster of commodity servers and you are willing to write your own data model against the key-value API. Do not adopt it if you want a query language, joins or an ORM: the README describes API language bindings, not a SQL layer, and the layers/ directory is where that work has to happen. Before committing, verify three things against the repository: that your platform has a binary package on the releases page, that your target branch is marked Supported rather than Experimental or Unsupported, and whether the Record Layer or another layer already models your data. The upgrade path is the other thing to plan, because the README states that skipping a major release is only tested in simulation. ## FAQ ### What is FoundationDB used for? The README describes it as a distributed database for large volumes of structured data across clusters of commodity servers, organized as an ordered key-value store with ACID transactions for all operations. It is suited to read/write and write-intensive workloads, and applications reach it through API language bindings. ### Is FoundationDB open source? Yes. The repository is apple/foundationdb, the licence is Apache-2.0, and the README points to the source tree and the documentation built from documentation/sphinx/source. ### Is FoundationDB free? The source is available under the Apache-2.0 licence and binary packages are published on the releases page, so there is no licence fee described in the repository. Anything beyond that, such as support or hosted services, is not covered by the README. ### Is FoundationDB NoSQL? It is not a relational database with a query language. The README describes it as an ordered key-value store, which places it in the NoSQL family, with the distinguishing feature that all operations run inside ACID transactions. ## Sources - [apple/foundationdb on GitHub](https://github.com/apple/foundationdb) - [License: Apache-2.0](https://github.com/apple/foundationdb/blob/main/LICENSE) - [Project website](https://apple.github.io/foundationdb/) - [README](https://github.com/apple/foundationdb/blob/main/README.md) - [Releases](https://github.com/apple/foundationdb/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apple-foundationdb