Skip to content
A record-oriented store built on FoundationDB
Branch: master
Clone or download
FDB Build User
Latest commit e00f25f Apr 20, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
build Resolves #313: Update fdb-java to 6.0.15 Mar 13, 2019
docs Release notes updated for version Apr 19, 2019
examples Resolves #408: RecordCursor needs a blocking onNext() Mar 14, 2019
fdb-extensions Resolves #538: AsyncLoadingCache should cache values instead of futures Apr 17, 2019
fdb-record-layer-core Investigate #546: ProbableIntersectionCursor and UnorderedUnionCursor… Apr 19, 2019
fdb-record-layer-icu Resolves #406: Move the API stability annotations into their own package Feb 21, 2019
gradle Resolves #85: Create a validator to check if a new meta-data is a val… Feb 15, 2019
.gitignore Fixes #167: Figure out whether .idea/encodings.xml belongs in source … Nov 28, 2018
ACKNOWLEDGEMENTS initial repository commit Oct 10, 2018 added a script that is run at release time to regenerate the release … Jan 19, 2019
LICENSE Grammatical correction Jan 16, 2019
build.gradle Resolves #85: Create a validator to check if a new meta-data is a val… Feb 15, 2019 added a script that is run at release time to regenerate the release … Jan 19, 2019
gradlew initial repository commit Oct 10, 2018
gradlew.bat initial repository commit Oct 10, 2018
settings.gradle Resolves #249: Collating index (#307) Feb 11, 2019

FoundationDB Record Layer

The Record Layer is a Java API providing a record-oriented store on top of FoundationDB, (very) roughly equivalent to a simple relational database, featuring:

  • Structured types - Records are defined and stored in terms of protobuf messages.
  • Indexes - The Record Layer supports a variety of different index types including value indexes (the kind provided by most databases), rank indexes, and aggregate indexes. Indexes and primary keys can be defined either via protobuf options or programmatically.
  • Complex types - Support for complex types, such as lists and nested records, including the ability to define indexes against such nested structures.
  • Queries - The Record Layer does not provide a query language, however it provides query APIs with the ability to scan, filter, and sort across one or more record types, and a query planner capable of automatic selection of indexes.
  • Many record stores, shared schema - The Record Layer provides the the ability to support many discrete record store instances, all with a shared (and evolving) schema. For example, rather than modeling a single database in which to store all users' data, each user can be given their own record store, perhaps sharded across different FDB cluster instances.
  • Very light weight - The Record layer is designed to be used in a large, distributed, stateless environment. The time between opening a store and the first query is intended to be measured in milliseconds.
  • Extensible - New index types and custom index key expressions may be dynamically incorporated into a record store.

The Record Layer may be used directly or provides an excellent foundational layer on which more complex systems can be constructed.


You can’t perform that action at this time.