SkillAgentSearch skills...

Foundationdb

FoundationDB - the open source, distributed, transactional key-value store

Install / Use

/learn @apple/Foundationdb
About this skill

Quality Score

0/100

Supported Platforms

Universal

README

<img alt="FoundationDB logo" src="documentation/FDB_logo.png?raw=true" width="400">

Build Status

FoundationDB is a distributed database designed to handle large volumes of structured data across clusters of commodity servers. It organizes data as an ordered key-value store and employs ACID transactions for all operations. It is especially well-suited for read/write workloads, but also has excellent performance for write-intensive workloads. Users interact with the database using API language binding.

To learn more about FoundationDB, visit foundationdb.org

Documentation

Documentation can be found online at https://apple.github.io/foundationdb/. The documentation covers details of API usage, background information on design philosophy, and extensive usage examples. Docs are built from the source in this repo.

Forums

The FoundationDB Forums are the home for most of the discussion and communication about the FoundationDB project. We welcome your participation! We want FoundationDB to be a great project to be a part of, and as part of that, we have established a Code of Conduct to define what constitutes permissible modes of interaction.

Contributing

Contributing to FoundationDB can be in contributions to the codebase, sharing your experience and insights in the community on the Forums, or contributing to projects that make use of FoundationDB. Please see the contributing guide for more specifics.

Getting Started

Latest Stable Releases

The latest stable releases are (were) versions that are recommended for production use, which have been extensively validated via simulation and real cluster tests and used in our production environment.

| Branch | Latest Production Release | Notes | |:--------:|:-------------:|------:| | 7.3 | 7.3.69 | Supported | | 7.2 | | Experimental | | 7.1 | 7.1.57 | Bug fixes | | 7.0 | | Experimental | | 6.3 | 6.3.25 | Unsupported |

  • Supported branches are those we actively maintain and will publish new patch releases.
  • Bug fixes are branches where we still accept bug fixes, but may not publish newer patch releases. The community can build the latest release binaries if needed and is encouraged to upgrade to the Supported branches.
  • Experimental branches are those used for internal feature testing. They are not recommended for production use.
  • Unsupported branches are those that will no longer receive any updates.

If you are running on old production releases, we recommend always upgrading to the next major release's latest version, and then continuing to the next major version, e.g., 6.2.X -> 6.3.25 -> 7.1.57 -> 7.3.69. These upgrade paths have been well tested in production (skipping a major release, not marked as Experimental, for an upgrade is only tested in simulation).

Binary Downloads

Developers interested in using FoundationDB can get started by downloading and installing a binary package. Please see the downloads page for a list of available packages.

Compiling from source

Developers on an OS for which there is no binary package, or who would like to start hacking on the code, can get started by compiling from source.

NOTE: FoundationDB has a lot of dependencies. The Docker container listed below tracks them and is what we use internally and is the recommended method of building FDB.

Build Using the Official Docker Image

The official Docker image for building is foundationdb/build, which includes all necessary dependencies. The Docker image definitions used by FoundationDB team members can be found in the dedicated repository.

To build FoundationDB with the clang toolchain,

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

To use GCC, a non-default version is necessary. The following modifies environment variables ($PATH, $LD_LIBRARY_PATH, etc) to pick up the right GCC version:

source /opt/rh/gcc-toolset-13/enable
gcc --version  # should say 13
mkdir /some/build_output_dir
cd /some/build_output_dir
cmake -G Ninja /some/fdb/source_dir
ninja

Slightly more elaborate compile commands can be found in the shell aliases defined in /root/.bashrc in the container image.

Build Locally

To build outside of the official Docker image, you'll need at least these dependencies:

  1. CMake version 3.24.2 or higher
  2. Mono
  3. ninja

This list is likely to be incomplete. Refer to the rockylinux9 Dockerfile in the fdb-build-support repo linked above for reference material on specific packages and versions that are likely to be required.

If compiling for local development, please set -DUSE_WERROR=ON in CMake. Our CI compiles with -Werror on, so this way you'll find out about compiler warnings that break the build earlier.

Once you have your dependencies, you can run cmake and then build:

  1. Check out this repository.
  2. Create a build directory (you can place it anywhere you like).
  3. cd <FDB_BUILD_DIR>
  4. cmake -G Ninja <FDB_SOURCE_DIR>
  5. ninja

Building FoundationDB requires at least 8GB of memory. More memory is needed when building in parallel. If the computer freezes or crashes, consider disabling parallelized build using ninja -j1.

FreeBSD

  1. Check out this repo on your server.

  2. Install compile-time dependencies from ports.

  3. (Optional) Use tmpfs & ccache for significantly faster repeat builds

  4. (Optional) Install a JDK for Java Bindings. FoundationDB currently builds with Java 8.

  5. Navigate to the directory where you checked out the FoundationDB repository.

  6. Build from source.

    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
    # run fast tests
    ctest -L fast
    # run all tests
    ctest --output-on-failure -v
    

macOS

The build under macOS will work the same way as on Linux. Homebrew can be used to install the boost library and the ninja build tool. Be carefull, curent main branch use boost 1.86, do install this version or just let cmake download one. Also, if swift binding is not interest, use -DBUILD_SWIFT_BINDING=OFF. One more thing, toml11project may block build process, mannualy change "cmake_minimum_required(VERSION 3.1)" to "cmake_minimum_required(VERSION 4.2)" in <BUILD_DIR>toml11Project-prefix/src/toml11Project/CMakeLists.txt and run again.

cmake -G Ninja <FDB_SOURCE_DIR> -B <BUILD_DIR>
cd <BUILD_DIR>
ninja

To generate an installable package,

<FDB_SOURCE_DIR>/packaging/osx/buildpkg.sh <BUILD_DIR> <FDB_SOURCE_DIR>

Windows

Under Windows, only Visual Studio with ClangCl is supported

  1. Install Visual Studio 2019 (IDE or Build Tools), and enable LLVM support
  2. Install CMake 3.24.2 or higher
  3. Download Boost 1.86.0
  4. Unpack boost to C:\boost, or use -DBOOST_ROOT=<PATH_TO_BOOST> with cmake if unpacked elsewhere
  5. Install Python if it is not already installed by Visual Studio
  6. (Optional) Install OpenJDK 11 to build Java bindings
  7. (Optional) Install OpenSSL 3.x to build with TLS support
  8. (Optional) Install WIX Toolset to build the Windows installer
  9. mkdir build && cd build
  10. cmake -G "Visual Studio 16 2019" -A x64 -T ClangCl <FDB_SOURCE_DIR>
  11. msbuild /p:Configuration=Release foundationdb.sln
  12. To increase build performance, use /p:UseMultiToolTask=true and /p:CL_MPCount=<NUMBER_OF_PARALLEL_JOBS>

Language Bindings

The language bindings that CMake supports will have a corresponding README.md file in the bindings/lang directory corresponding to each language.

Generally, CMake will build all language bindings for which it can find all necessary dependencies. After each successful CMake run, CMake will tell you which language bindings it is going to build.

Generating compile_commands.json

CMake can build a compilation database for you. However, the default generated one is not too useful as it operates on the generated files. When running ninja, the build system creates another compile_commands.json file in the source directory. This can then be used for tools such as CCLS and CQuery, among others. This way, you can get code completion and code navigation in flow. It is not yet perfect (it will show a few errors), but we are continually working to improve the development experience.

CMake will not produce a compile_commands.json by default; you mus

View on GitHub
GitHub Stars16.2k
CategoryData
Updated15h ago
Forks1.5k

Languages

C++

Security Score

100/100

Audited on Apr 3, 2026

No findings