HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
apple
foundationdb
C++2018–2026
apple / foundationdb

foundationdb

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

45Distinct people
49Mentions
1Explicit recommenders
16.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

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

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I think my favorite part of the build process was when we frobnicated libstdc++: https://github.com/apple/foundationdb/blob/master/Makefile#L... And then there were the hijinks…

wwilson used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year49 dated mentions

Observed mentions: 2018-04-19 16:58:30 UTC to 2026-07-03 01:48:34 UTC.

0369122018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 11 mentions; 2 submissions, 9 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC12012
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC707
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC1129
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC514
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC615
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
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 bindings. 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 Contributions to FoundationDB can include contributions to the codebase, sharing your experience and insights with 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 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.77 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: CMake version 3.24.2 or higher Mono 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: Check out this repository. Create a build directory (you can place it anywhere you like). cd <FDB_BUILD_DIR> cmake -G Ninja <FDB_SOURCE_DIR> 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 Check out this repo on your server. Install compile-time dependencies from ports. (Optional) Use tmpfs & ccache for significantly faster repeat builds (Optional) Install a JDK for Java Bindings. FoundationDB currently builds with Java 8. Navigate to the directory where you checked out the FoundationDB repository. 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 careful: the current main branch uses Boost 1.89; install this version or let CMake download it. Also, if the Swift binding is not of interest, use -DBUILD_SWIFT_BINDING=OFF. cmake -G Ninja <
Read the full README on GitHub

What Hacker News says

49 sources
> A more interesting question would be how well the C++ interoperability works They’re using it in their work on FoundationDB. Looks good, but has limitations. Swift can call C++ and vice versa, Swift classes can inherit from C++ and vice versa, but not for all code, and may need work adding annotations on the C++ side. See https://github.com/apple/foundationdb/blob/main/SWIFT_GUIDE..... There’s a good video on that work from a few years ago that was discussed on HN in https://news.ycombinator.com/item?id=38444876.
In Testing the Swift C compatibility with Raylib (+WASM)
The five second timeout remains and trickles through to apply to Postgres transactions instead. This project would very much be for OLTP, so not really fit for using Postgres for OLAP or hybrid workloads. The N+1 issue is a really interesting one which I have a plan for but haven't implemented yet. FoundationDB has what they call mapped ranges [0] to help with this, which works in some cases. More generally, one should make sure to issue read request as soon as possible and not on-demand, given that FoundationDB clients have a futures-based design. This is slightly tricky in Postgres because internally it has a pull-based model where one tuple is pulled from the execution plan at a time, so one needs to implement pre-fetching and not make a read against FDB each time a new tuple is pulled. [0] https://github.com/apple/foundationdb/wiki/Ev
Read the rest
In Foundation DB Record Layer SQL API
I'm honestly not at all familiar with browsers but I really do wonder if a custom language wouldn't be a reasonable tradeoff. It's not all that insane as that is a path that has been walked before. For instance FoundationDB has their own syntax to manage their actor system which just transpiles to C++: https://github.com/apple/foundationdb/blob/main/flow/README.... V8 also has torque which I think to some degree also fits into that type of mindset.
In Pwning the Ladybird Browser
> I wondered if perhaps this WASM use case for a cross-language library was already just as possible and ergonomic using language bindings and maybe thats why this use case doesnt seem like a big deal to people. Yeah that’s the reason. You don’t notice it a lot of the time, but FFIs are everywhere already. The most common foreign function interface is basically the ability to call C code, or have functions made available to C code. C is used because everyone knows it and it’s simple. And most languages either compile to native code (eg rust) - which makes linking to C code easy. Or the runtime is implemented in C or C++ (eg V8, Ruby). In languages like that, the standard library is already basically implemented via a FFI to C/C++ code. I’ve got an iOS app I’m working on that’s half rust and half swift, with a touch of C in the middle. The
Read the rest
bindings work great - the whole thing links together into one binary, even with link time optimizations. But the glue code is gross, and when I want to fiddle with the rust to Swift API I need to change my code in about 4 different places. Most FFIs are a one to many relationship in that if you write a clean C API, you can probably write bindings in every language. But you don’t actually want to call naked C code from Ruby or Javascript. Good bindings will make you forget everything is done via ffi. Eg numpy. I haven’t looked at the wasm component model proposal - I assume it’s trying to make this process cleaner, which sounds lovely. I maintain the nodejs bindings for foundationdb. Foundationdb bindings are all done via ffi linking to their C code. And the API is complex, using promises and things. I find it really interesting browsing their official bindings to go, Java, Python and Ruby. Same bindings. Same wrapped api. Same team of authors. Just different languages. And that’s enough to make the wrapper wildly different in every language. From memory the Java ffi wrapper is 4x as much code as it is in Ruby. https://github.com/apple/foundationdb/tree/main/bindings
In WASM by example

Showing the 15 most recent of 49 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.