A layer can provide a new data model, compatibility with existing systems, or even serve as an entire framework. Multiple layers can be used at the same time, enabling a single FoundationDB database to consolidate multiple data stores. Read the Layer White Paper →
Have you built a layer on top of FoundationDB that you'd like to include on this page? Let us know!Submit a Layer
These layers are ready for you to use today. Some are examples of how to build a layer to provide a certain utility, data model, etc.
Efficiently load data from external source (e.g., csv or json files on disk) using concurrent transactions to achieve sufficient pipelining.
Protocol Buffers Layer for Ruby
Document Model and Query Layer for NodeJS
Implements the Blueprints 2.3.0 graph API. Allows FoundationDB to be used as a storage layer for the Tinkerpop stack. Supports all required and most optional Blueprints features, including transactions over the graph database.
Storage backend for Titan, a transactional, scalable graph database produced by Aurelius. Builds on our Blueprints layer and employs Titan's TinkerPop integration.
A FoundationDB broker and backend for Celery, an asynchronous task queue/job queue based on distributed message passing.
Pub-sub messaging pattern supporting messages, feeds, and inboxes. Implementation uses transactions and 'dirty' list managament for efficiency. Employs SimpleDoc ordered indexes.
Stores arbitrary-sized binary large objects (blobs). Provides an abstraction for random or sequential reads and writes of a blob, allowing it to be partially accessed or streamed. Uses an efficient, sparse representation.
A spatial index for 2D points that allows efficient queries of axis-aligned rectangular regions. Does dimensionality reduction via a Z-order fractal curve (aka geohash).
For interning (aka normalizing, aliasing) commonly-used long strings into shorter representations. Maintains the normalization state in the database, as well as a local cache for high performance.
Store and manipulate potentially sparse 1-D arrays in the database. In addition to standard array operations, arrays can be efficiently retrieved by range or resized.
Queues with a high-contention mode that minimizes conflicts while supporting multiple clients. There is also a non-high-contention mode that is optimized for single clients.
Document data model supporting a single document with no size restrictions. Data objects are represent as sub-documents of the root. Provides a multi-level plugin system to modify operations.
These layers are still being built out, so don't count on using them for anything real yet.
Store your Ruby application data in various data models, including Document and Key-Value.
A full SQL implementation on top of FoundationDB. It provides the same high performance, multi-node scalability, fault-tolerance, and true multi-key ACID transactions.
Distributed coordination service supporting locking, leader election, and service discovery. Inspired by ZooKeeper but higher level. Provides DNS and REST APIs.
This layer provides two integration points with Lucene, FDBDirectory and FDBCodec. These are full implementations of the Directory and Codec interfaces.