Why Clever Cloud built its PaaS on FoundationDB's transactional key-value store

Based on an extensive interview with Clever Cloud's Pierre Zemb, we analyze the architectural trade-offs and operational realities of building a commercial platform on Apple's open-source distributed database.

The Answer Up Front

For engineering teams building new stateful systems from the ground up (databases, message queues, metadata stores) who need absolute transactional integrity at scale, FoundationDB is a powerful, low-level primitive. Clever Cloud's experience validates it as a foundation for a multi-model data platform. You should skip it if you're looking for a drop-in, managed database like PostgreSQL or MySQL for a standard application. The operational burden is significant, and it requires deep systems expertise. The bottom line: FoundationDB is an infrastructure building block for creating new databases, not a ready-to-use database itself.

Methodology

This v0 review is based entirely on the published interview transcript with Pierre Zemb, co-founder of the PaaS company Clever Cloud, published June 18, 2026. The source signal is "Pierre Zemb from Clever Cloud on FoundationDB" from The Consensus, accessed on June 25, 2026. This analysis covers Clever Cloud's stated rationale for choosing FoundationDB, their architectural approach of building "layers" on its key-value primitive, and their reported experiences with its performance and operational complexity. What is not covered is any independent performance benchmarking, a hands-on evaluation of the operational difficulty, or a comparative analysis against other distributed key-value stores like TiKV or etcd. All performance characteristics and benefits described are claims made by Clever Cloud in the interview; they have not been independently verified by Founderr Pulse. Update cadence: this review will be updated to a v1 with independent benchmarks when resources permit.

What It Does

Based on Clever Cloud's implementation, FoundationDB serves as a unified, transactional backend for a diverse set of data services.

A transactional key-value core

At its heart, FoundationDB is not a document store, a relational database, or a time-series database. As Zemb describes it, FDB provides one core thing: a strictly serializable, ordered key-value store. This means all transactions appear to execute sequentially, guaranteeing ACID properties across the entire cluster. This is the fundamental primitive Clever Cloud builds upon. Instead of managing multiple stateful systems (one for Postgres, one for Redis, one for Kafka), they manage one, highly-reliable distributed system.

Enables building custom "layers"

Clever Cloud uses FDB's core to build its own higher-level data services, which they call layers. Because FDB provides transactions over a simple key-value map, they can model different data structures on top of it. Zemb's interview implies they have built document database APIs, message queues, and other services this way. This allows them to offer a multi-model database platform to their customers, all running on a single, consolidated FDB cluster. This approach gives them full control over the data services' features and performance characteristics.

Manages scale and fault tolerance

Zemb highlights FDB's architecture as a key reason for its adoption. It's designed for scalability and fault tolerance. The system automatically re-replicates data and rebalances load when nodes fail or are added. For a PaaS provider like Clever Cloud, this is critical. They rely on FDB to handle the underlying mechanics of running a reliable distributed system, freeing their engineers to focus on the logic of the data layers they build on top.

What's Interesting / What's Not

The most interesting aspect of Clever Cloud's story is the deliberate choice to build, not buy, at the core data layer. In an industry dominated by managed database services, they invested heavily in mastering a complex, low-level tool. Zemb's reasoning points to a desire for ultimate control, performance, and the architectural elegance of a single, unified stateful system. This is a high-conviction, high-effort bet that trades the convenience of off-the-shelf solutions for a deeper technical moat.

The counterpoint is the operational reality. Zemb is clear that running FoundationDB is not trivial. It requires a dedicated team with deep expertise in distributed systems. This is not a tool you adopt casually. The complexity is the explicit trade-off for the power it provides. This isn't a database for a typical startup's web application; it's infrastructure for building platforms.

What's not new is the concept of a distributed key-value store. Projects like TiKV and etcd serve similar roles in other ecosystems. The distinction with FDB, and what Clever Cloud bet on, is its specific combination of strict serializability, a minimalist API, and a design philosophy that pushes data modeling logic up into the layers built on top.

Pricing

FoundationDB is open-source software under the Apache 2.0 license. It is free to download and use.

The cost is entirely operational. This includes:

• The cost of the bare metal or virtual servers to run the cluster.
• The significant engineering cost for the team required to operate, monitor, and upgrade the FDB cluster.
• The development cost of building and maintaining the necessary application-specific "layers" on top of the key-value store.

(Pricing snapshot taken June 25, 2026)

Verdict

Clever Cloud's experience provides a clear blueprint for who should consider FoundationDB. If you are building a platform that must offer multiple, distinct data models (e.g., a PaaS or a large internal developer platform) and have the engineering talent to manage a complex distributed system, FDB is a compelling foundation. It offers a path to a unified, scalable, and transactionally-correct data layer that is difficult to achieve by composing disparate managed services. However, if your goal is to ship a product and you simply need a reliable database, a managed PostgreSQL or MySQL instance is faster, cheaper, and requires a fraction of the operational overhead. The choice depends entirely on whether you are building an application or building the infrastructure to run many applications.

What We'd Test Next

To move this review from a v0 to a v1, we would need to perform independent, hands-on testing. First on the list is a direct TPC-C benchmark comparing a well-known FDB layer (like Apple's open-source Record Layer) against a mature distributed SQL database like CockroachDB or YugabyteDB on identical hardware. Second, we would want to quantify the operational complexity by documenting the process of setting up a multi-node cluster, simulating common failure scenarios (node loss, network partitions), and measuring the difficulty and time-to-recovery. Finally, we would test the multi-model claim by building two simple but conflicting workload layers on the same cluster to observe performance isolation and potential cross-layer interference.

The investor read

FoundationDB itself is not an investment target; it's an open-source project backed by Apple. The signal for investors is the durable need for powerful, low-level infrastructure primitives. Companies like Clever Cloud demonstrate a willingness to incur high operational costs to own their core data layer, avoiding vendor lock-in and building a technical moat. This creates opportunities for two types of businesses: 1) companies building valuable, proprietary 'layers' or platforms on top of FDB, and 2) expert consultancies or managed service providers who can abstract away FDB's immense operational complexity for less-specialized teams. The market isn't in the tool itself, but in the ecosystem of products and services that it enables. A company that successfully commercializes an FDB 'layer' for a specific vertical could be highly defensible.

Pull quote: “The bottom line: FoundationDB is an infrastructure building block for creating new databases, not a ready-to-use database itself.”