History[06][07][08][09]

FoundationDB is built to handle high-load transaction processing with high-performance with strong guarantee (ACID).

FoundationDB is originally built in 2009 by three co-founders, Dave Rosenthal, Dave Scherer, Nick Lavezzo. The founders used to work for Visual Sciences; an analytics company (now is a subsidiary of Adobe). The company acquired Akiban in 2013. FoundationDB was acquired by Apple in 2015. In 2018, Apple open-sourced FoundationDB under Apache License 2.0.

Concurrency Control[10][05][11]

FoundationDB uses Optimistic Concurrency Control (OCC) for writes and Multiversion Concurrency Control (MVCC) for reads. The DBMS only maintains conflicting transaction information for a five second period. Thus, it doesn't support long-running read/write transactions. Conflicting transactions will fail at commit and the client is responsible to retry the transactions.

Data Model[12][13][14]

FoundationDB exposes a single data model, an ordered Key-Value data model. Both keys and values are byte strings. To support a richer data-model or index, a user can write his own custom layer module API to remap the Key-Value data model.

Foreign Keys

Indexes[14]

As have been stated in the Data Model sections, FoundationDB doesn’t support indexes natively. A user needs to build indexes by writing a layer module. With FoundationDB’s transaction, the same transaction can update index and data.

Isolation Levels[15]

FoundationDB uses Optimistic Concurrency Control to achieve Serializable Isolation level. This can be achieved because all modifications to key-value data store are done via transaction.

Joins[15]

Same as indexes, a user needs to write a custom layer module to perform joins.

Logging

FoundationDB only responds to commit request once the transaction has been written to log and fsync-ed to the disk.

Query Interface[16][17]

The only way to model the data and query them is by writing layer. FoundationDB only allows the user to interact with the data through their custom API in Python, Ruby, Java, Go, or C.

The DBMS used to support SQL layer in 2014 but it is not actively supported and maintained anymore.

Storage Architecture[18]

FoundationDB has two storage options, ssd and memory. All data to be read must reside in memory, and all writes will be written to disk with the number of copies based on the redundancy mode. The default DBMS configuration is memory, and the maximum size of data in memory is 1 GB.

Storage Model[19]

FoundationDB stores data in a Key-Value model.

Storage Organization[20]

On disk mode, FoundationDB stores data with B-tree structures.

Stored Procedures[13]

System Architecture[13][21]

FoundationDB handles all scalability issue automatically when scaling out. Every time the DBMS writes data, the data is distributed by pieces to different nodes.

Views