{"slug": "foundationdb", "name": "FoundationDB", "category": "databases", "category_name": "Databases", "description": "", "recommenders": 11, "commenters": 17, "warners": 0, "score": 10.82, "rising": -0.95, "first": "2025-11-03", "latest": "2026-08-25", "why": "FoundationDB is awesome testing wise as they have deterministic simulation testing", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 10, "neutral": 7, "compare": 1, "warn": 0}, "spark": [0, 6, 1, 0, 0, 0, 0, 1, 0, 2, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "FoundationDB is awesome testing wise as they have deterministic simulation testing", "kind": "", "icon": false, "domain": "vercel.app", "github_repo": null, "official_url": "https://www.foundationdb.org", "pricing": "", "aliases": ["FoundationDB"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 794355425, "item_id": 49647214, "url": "https://news.ycombinator.com/item?id=49647214", "by": "ovaistariq", "date": "2026-09-10", "version": null, "stance": "recommend", "quote": "we use FDB as our metadata store which is the sort of workload it is really good at", "excerpt": "Tigris founder here. So part of the reason we do not expose other database like APIs is because we are a S3-compatible store, so anything we expose has to fit into the S3 API semantics. In our current design we use FDB as our metadata store which is the sort of workload it is really good at.", "context": "Tigris founder", "use_case": "metadata store", "switched_from": "", "story": "Object storage is all you need"}, {"id": 791052448, "item_id": 49440778, "url": "https://news.ycombinator.com/item?id=49440778", "by": "WilcoKruijer", "date": "2026-08-25", "version": null, "stance": "recommend", "quote": "should read the FoundationDB data modeling guide", "excerpt": "I really believe that every engineer writing queries (even SQL) should read the FoundationDB data modeling guide [0]. It really gives an appreciation of what smart choice of primary key can do to query efficiency. With some de-normalization, joins aren\u2019t even needed for performance. Postgres has supported query pipelining for a long time. In my opinion, most queries should be written in such a way that sequential que", "context": "", "use_case": "", "switched_from": "", "story": "Solving the 1+N Query Problem"}, {"id": 788553552, "item_id": 49284597, "url": "https://news.ycombinator.com/item?id=49284597", "by": "sorry_i_lisp", "date": "2026-08-13", "version": null, "stance": "recommend", "quote": "I think FoundationDB has that crown.", "excerpt": "I think FoundationDB has that crown. https://antithesis.com/company/about/", "context": "", "use_case": "", "switched_from": "", "story": "Tailscale Traces Database Corruption to 16y/o SQLite WAL-Reset Bug"}, {"id": 776532784, "item_id": 48533299, "url": "https://news.ycombinator.com/item?id=48533299", "by": "fidotron", "date": "2026-06-14", "version": null, "stance": "recommend", "quote": "I strongly recommend poking around with Foundation for this", "excerpt": "> And the obvious rebuttal to that is that it's equally hard to provide an upper bound for the runtime of a single insert This is precisely where you're going wrong. The insert is upper boundable in advance (you know the set of everything you might potentially have to insert), the delete isn't because you don't know what's in the db until you look. I strongly recommend poking around with Foundation for this, because ", "context": "", "use_case": "understanding delete scalability", "switched_from": "", "story": "The only scalable delete in Postgres is DROP TABLE"}, {"id": 743425680, "item_id": 46464105, "url": "https://news.ycombinator.com/item?id=46464105", "by": "jwr", "date": "2026-01-02", "version": null, "stance": "recommend", "quote": "very few can guarantee Strict Serializability in a distributed setting, like FoundationDB does.", "excerpt": "It's a nice intro! One thing I would respectfully suggest is using more precise terminology than \"ACID\". Jepsen has a great resource for looking at various consistency models (https://jepsen.io/consistency/models) and while every database these days says it is \"ACID\", very few can guarantee Strict Serializability in a distributed setting, like FoundationDB does.", "context": "", "use_case": "", "switched_from": "", "story": "Intro to Foundation DB via a Distributed Mutex"}]}], "caveats": [], "who": [{"by": "ovaistariq", "context": "Tigris founder", "url": "https://news.ycombinator.com/item?id=49647214", "date": "2026-09-10"}, {"by": "arohner", "context": "employee of Griffin Bank UK", "url": "https://news.ycombinator.com/item?id=46195084", "date": "2025-12-08"}, {"by": "ghc", "context": "Works on infrastructure that runs on it", "url": "https://news.ycombinator.com/item?id=46194344", "date": "2025-12-08"}, {"by": "dpedu", "context": "Works at Matterport", "url": "https://news.ycombinator.com/item?id=46192908", "date": "2025-12-08"}], "tags": [], "use_cases": ["metadata store", "fault-injection testing", "understanding delete scalability", "core system at a bank", "data store for critical infrastructure", "distributed database testing"], "compared": [{"slug": "amazon-dynamodb", "name": "Amazon DynamoDB", "co": 1, "switched_from": 1, "switched_to": 0}, {"slug": "tigris", "name": "Tigris", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "bazel", "name": "Bazel", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "svelte", "name": "Svelte", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [{"id": 756513441, "item_id": 47282090, "url": "https://news.ycombinator.com/item?id=47282090", "by": "ovaistariq", "date": "2026-03-06", "version": null, "stance": "neutral", "quote": "we use that for our metadata storage", "excerpt": "Well we have made small objects work well on Tigris (https://www.tigrisdata.com/). And we have several use cases of folks using it as KV store. Funny that you mention FoundationDB, we use that for our metadata storage.", "context": "", "use_case": "metadata storage", "switched_from": "", "story": "Supertoast Tables"}, {"id": 745101632, "item_id": 46568852, "url": "https://news.ycombinator.com/item?id=46568852", "by": "janderland", "date": "2026-01-10", "version": null, "stance": "neutral", "quote": "If you'd like an intro to FoundationDB, you can take a look at this blog post I wrote.", "excerpt": "Author here . If you'd like an intro to FoundationDB, you can take a look at this blog post I wrote. This CI framework was created during the writing of this post. https://jander.land/20251227_mutex.html", "context": "author of the blog/project", "use_case": "database development", "switched_from": "", "story": "Janderland/fenv: FoundationDB development environment"}], "threads": [{"url": "https://news.ycombinator.com/item?id=46191763", "title": "Flow: Actor-based language for C++, used by FoundationDB", "mentions": 9}, {"url": "https://news.ycombinator.com/item?id=49618450", "title": "Object storage is all you need", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=49272832", "title": "Tailscale Traces Database Corruption to 16y/o SQLite WAL-Reset Bug", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=46477290", "title": "Janderland/fenv: FoundationDB development environment", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=49432786", "title": "Solving the 1+N Query Problem", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48762372", "title": "FoundationDB's Flow \u2013 Bringing Actor-Based Concurrency to C++11", "mentions": 1}], "sentiment_by_month": {"2025-11": {"neutral": 1}, "2025-12": {"neutral": 3, "recommend": 6}, "2026-01": {"recommend": 1, "neutral": 1}, "2026-02": {}, "2026-03": {}, "2026-04": {"compare": 1}, "2026-05": {}, "2026-06": {"recommend": 1}, "2026-07": {"neutral": 1}, "2026-08": {"neutral": 1, "recommend": 2}, "2026-09": {}, "2026-10": {}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 794355952, "item_id": 49647247, "url": "https://news.ycombinator.com/item?id=49647247", "by": "ovaistariq", "date": "2026-09-10", "version": null, "stance": "neutral", "quote": "We wrote a bit about using FoundationDB at Tigris", "excerpt": "We wrote a bit about using FoundationDB at Tigris: https://www.tigrisdata.com/blog/fdb-krea-talk/", "context": "", "use_case": "", "switched_from": "", "story": "Object storage is all you need"}, {"id": 794355425, "item_id": 49647214, "url": "https://news.ycombinator.com/item?id=49647214", "by": "ovaistariq", "date": "2026-09-10", "version": null, "stance": "recommend", "quote": "we use FDB as our metadata store which is the sort of workload it is really good at", "excerpt": "Tigris founder here. So part of the reason we do not expose other database like APIs is because we are a S3-compatible store, so anything we expose has to fit into the S3 API semantics. In our current design we use FDB as our metadata store which is the sort of workload it is really good at.", "context": "Tigris founder", "use_case": "metadata store", "switched_from": "", "story": "Object storage is all you need"}, {"id": 791052448, "item_id": 49440778, "url": "https://news.ycombinator.com/item?id=49440778", "by": "WilcoKruijer", "date": "2026-08-25", "version": null, "stance": "recommend", "quote": "should read the FoundationDB data modeling guide", "excerpt": "I really believe that every engineer writing queries (even SQL) should read the FoundationDB data modeling guide [0]. It really gives an appreciation of what smart choice of primary key can do to query efficiency. With some de-normalization, joins aren\u2019t even needed for performance. Postgres has supported query pipelining for a long time. In my opinion, most queries should be written in such a way that sequential que", "context": "", "use_case": "", "switched_from": "", "story": "Solving the 1+N Query Problem"}, {"id": 788553552, "item_id": 49284597, "url": "https://news.ycombinator.com/item?id=49284597", "by": "sorry_i_lisp", "date": "2026-08-13", "version": null, "stance": "recommend", "quote": "I think FoundationDB has that crown.", "excerpt": "I think FoundationDB has that crown. https://antithesis.com/company/about/", "context": "", "use_case": "", "switched_from": "", "story": "Tailscale Traces Database Corruption to 16y/o SQLite WAL-Reset Bug"}, {"id": 788395136, "item_id": 49274696, "url": "https://news.ycombinator.com/item?id=49274696", "by": "jeffbee", "date": "2026-08-12", "version": null, "stance": "neutral", "quote": "to test FoundationDB", "excerpt": "Block device upfuckery layers are powerful against databases. Years ago some colleagues wrote one that provides most of the hazards described by \"Parity Lost and Parity Regained\"[1] to test FoundationDB, which immediately uncovered several flaws in a project that described itself as well-tested. It's easy to do this with all the probing features that Linux (and others) provide today. 1: https://www.usenix.org/legacy/", "context": "", "use_case": "fault-injection testing", "switched_from": "", "story": "Tailscale Traces Database Corruption to 16y/o SQLite WAL-Reset Bug"}, {"id": 780428464, "item_id": 48776779, "url": "https://news.ycombinator.com/item?id=48776779", "by": "Dave_Rosenthal", "date": "2026-07-03", "version": null, "stance": "neutral", "quote": "created a new unofficial resource for getting going with FoundationDB", "excerpt": "Great Q--it's weird that Apple, Snowflake, and the other big contributors have put essentially zero calories into documentation/website/etc. There has been some movement lately, though. I'm not sure who exactly to thank, but \"the community\" created a new unofficial resource for getting going with FoundationDB: https://foundationdb.vercel.app/7.3/", "context": "", "use_case": "", "switched_from": "", "story": "FoundationDB's Flow \u2013 Bringing Actor-Based Concurrency to C++11"}, {"id": 776532784, "item_id": 48533299, "url": "https://news.ycombinator.com/item?id=48533299", "by": "fidotron", "date": "2026-06-14", "version": null, "stance": "recommend", "quote": "I strongly recommend poking around with Foundation for this", "excerpt": "> And the obvious rebuttal to that is that it's equally hard to provide an upper bound for the runtime of a single insert This is precisely where you're going wrong. The insert is upper boundable in advance (you know the set of everything you might potentially have to insert), the delete isn't because you don't know what's in the db until you look. I strongly recommend poking around with Foundation for this, because ", "context": "", "use_case": "understanding delete scalability", "switched_from": "", "story": "The only scalable delete in Postgres is DROP TABLE"}, {"id": 764791137, "item_id": 47799446, "url": "https://news.ycombinator.com/item?id=47799446", "by": "Nican", "date": "2026-04-16", "version": null, "stance": "compare", "quote": "FoundationDB claims 300,000 reads per second on a single core.", "excerpt": "This looks like yet another basic key value store. Benchmarking is a complicated problem, but FoundationDB claims 300,000 reads per second on a single core. TigerBeetle claims 100k-500k TPS on... Some kind of hardware? https://apple.github.io/foundationdb/benchmarking.html", "context": "", "use_case": "", "switched_from": "", "story": "TigerBeetle: A Trillion Transactions [video]"}, {"id": 745107073, "item_id": 46569192, "url": "https://news.ycombinator.com/item?id=46569192", "by": "jcalabro", "date": "2026-01-10", "version": null, "stance": "neutral", "quote": "I just run it in docker compose", "excerpt": "Interesting. I just run it in docker compose: https://github.com/jcalabro/atlas/blob/fee905ba496d363188fb37bd955a186401a677f9/compose.yaml#L11-L58", "context": "", "use_case": "", "switched_from": "", "story": "Janderland/fenv: FoundationDB development environment"}, {"id": 743425680, "item_id": 46464105, "url": "https://news.ycombinator.com/item?id=46464105", "by": "jwr", "date": "2026-01-02", "version": null, "stance": "recommend", "quote": "very few can guarantee Strict Serializability in a distributed setting, like FoundationDB does.", "excerpt": "It's a nice intro! One thing I would respectfully suggest is using more precise terminology than \"ACID\". Jepsen has a great resource for looking at various consistency models (https://jepsen.io/consistency/models) and while every database these days says it is \"ACID\", very few can guarantee Strict Serializability in a distributed setting, like FoundationDB does.", "context": "", "use_case": "", "switched_from": "", "story": "Intro to Foundation DB via a Distributed Mutex"}, {"id": 739143968, "item_id": 46196498, "url": "https://news.ycombinator.com/item?id=46196498", "by": "preetamjinka", "date": "2025-12-08", "version": null, "stance": "neutral", "quote": "FoundationDB is used at Datadog [2].", "excerpt": "https://discovery.hgdata.com/product/foundationdb This \"Who is hiring\" post for Tesla mentions FoundationDB [0]. Firebolt [1] uses it. FoundationDB is used at Datadog [2]. [0] https://news.ycombinator.com/item?id=26306170 [1] https://www.firebolt.io/blog/decomposing-firebolt-transactions [2] https://news.ycombinator.com/item?id=36576775", "context": "", "use_case": "", "switched_from": "", "story": "Flow: Actor-based language for C++, used by FoundationDB"}, {"id": 739131200, "item_id": 46195700, "url": "https://news.ycombinator.com/item?id=46195700", "by": "maxmcd", "date": "2025-12-08", "version": null, "stance": "neutral", "quote": "", "excerpt": "Maybe this? https://forums.foundationdb.org/t/swift-or-c-20-coroutine-which-is-the-future-of-fdb/4592/2", "context": "", "use_case": "", "switched_from": "", "story": "Flow: Actor-based language for C++, used by FoundationDB"}, {"id": 739121344, "item_id": 46195084, "url": "https://news.ycombinator.com/item?id=46195084", "by": "arohner", "date": "2025-12-08", "version": null, "stance": "recommend", "quote": "Griffin Bank UK uses it for our entire system", "excerpt": "Griffin Bank UK uses it for our entire system (https://griffin.com)", "context": "employee of Griffin Bank UK", "use_case": "Core system at a bank", "switched_from": "", "story": "Flow: Actor-based language for C++, used by FoundationDB"}, {"id": 739109504, "item_id": 46194344, "url": "https://news.ycombinator.com/item?id=46194344", "by": "ghc", "date": "2025-12-08", "version": null, "stance": "recommend", "quote": "I've never spent less time thinking about a data store that I use daily.", "excerpt": "There might be a good reason for the lack of stories. FoundationDB runs critical infrastructure I work on, but I never actually have to think about it. I've never spent less time thinking about a data store that I use daily.", "context": "Works on infrastructure that runs on it", "use_case": "Data store for critical infrastructure", "switched_from": "", "story": "Flow: Actor-based language for C++, used by FoundationDB"}, {"id": 739102576, "item_id": 46193911, "url": "https://news.ycombinator.com/item?id=46193911", "by": "SoKamil", "date": "2025-12-08", "version": null, "stance": "recommend", "quote": "FoundationDB is awesome testing wise as they have deterministic simulation testing", "excerpt": "FoundationDB is awesome testing wise as they have deterministic simulation testing [1] that can simulate distributed and operating system failures. > We wanted FoundationDB to survive failures of machines, networks, disks, clocks, racks, data centers, file systems, etc., so we created a simulation framework closely tied to Flow. By replacing physical interfaces with shims, replacing the main epoll-based run loop with", "context": "", "use_case": "distributed database testing", "switched_from": "", "story": "Flow: Actor-based language for C++, used by FoundationDB"}, {"id": 739089632, "item_id": 46193102, "url": "https://news.ycombinator.com/item?id=46193102", "by": "CharlesW", "date": "2025-12-08", "version": null, "stance": "recommend", "quote": "Snowflake uses it: https://www.snowflake.com/en/blog/how-foundationdb-powers-snowflake-metadata-forward/", "excerpt": "Snowflake uses it: https://www.snowflake.com/en/blog/how-foundationdb-powers-snowflake-metadata-forward/ Tigris uses it: https://www.tigrisdata.com/blog/building-a-database-using-foundationdb/ A good collection of papers, blog posts, talks, etc.: https://github.com/FoundationDB/awesome-foundationdb", "context": "", "use_case": "Distributed database", "switched_from": "", "story": "Flow: Actor-based language for C++, used by FoundationDB"}, {"id": 739089344, "item_id": 46193084, "url": "https://news.ycombinator.com/item?id=46193084", "by": "quettabit", "date": "2025-12-08", "version": null, "stance": "recommend", "quote": "", "excerpt": "At s2.dev (a serverless datastore for real-time streaming data), we started with DynamoDB for our metadata store, but our access patterns kept running into per-partition throughput limits. We switched to FoundationDB, and it\u2019s been great so far.", "context": "", "use_case": "Metadata store", "switched_from": "DynamoDB", "story": "Flow: Actor-based language for C++, used by FoundationDB"}, {"id": 739086528, "item_id": 46192908, "url": "https://news.ycombinator.com/item?id=46192908", "by": "dpedu", "date": "2025-12-08", "version": null, "stance": "recommend", "quote": "has been extremely reliable and hands-off, administration-wise", "excerpt": "My company (Matterport, YC Winter '12) uses it to store metadata about 3d models. I really don't have that much to say about it because it's not my primary area of focus, and besides that, has been extremely reliable and hands-off, administration-wise. I particularly love that you can change redundancy modes on the fly, for example those listed here[1], and FDB will automatically re-arrange data to your liking, all w", "context": "Works at Matterport", "use_case": "Storing 3D model metadata", "switched_from": "", "story": "Flow: Actor-based language for C++, used by FoundationDB"}, {"id": 739082944, "item_id": 46192684, "url": "https://news.ycombinator.com/item?id=46192684", "by": "adobrawy", "date": "2025-12-08", "version": null, "stance": "recommend", "quote": "Snowflake uses it as primary database for their metadata.", "excerpt": "Snowflake uses it as primary database for their metadata. https://www.snowflake.com/en/blog/how-foundationdb-powers-snowflake-metadata-forward/", "context": "", "use_case": "metadata database", "switched_from": "", "story": "Flow: Actor-based language for C++, used by FoundationDB"}, {"id": 737771088, "item_id": 46110693, "url": "https://news.ycombinator.com/item?id=46110693", "by": "arohner", "date": "2025-12-01", "version": null, "stance": "neutral", "quote": "Tech: Clojure, FoundationDB, Bazel, CLJS, Svelte", "excerpt": "Griffin Bank | Engineering | REMOTE (UK) Company: We are Griffin Bank. We are a fully authorized, API-first bank; we bank fintechs and startups. We built our own core banking system from scratch. Experience: We are hiring across broadly across engineering. The things we work on include onboarding and KYC, payments rails, accounting, billing and reporting. We are hiring backend and frontend engineers. We are currently", "context": "", "use_case": "Database", "switched_from": "", "story": "Ask HN: Who is hiring? (December 2025)"}, {"id": 732853376, "item_id": 45803336, "url": "https://news.ycombinator.com/item?id=45803336", "by": "arohner", "date": "2025-11-03", "version": null, "stance": "neutral", "quote": "FoundationDB", "excerpt": "Griffin Bank | Engineering | REMOTE (UK) Company: We are Griffin Bank. We are a fully authorized, API-first bank; we bank fintechs and startups. We built our own core banking system from scratch. Experience: We are hiring across broadly across engineering. The things we work on include onboarding and KYC, payments rails, accounting, billing and reporting. We are hiring backend, frontend and design system engineers. W", "context": "", "use_case": "", "switched_from": "", "story": "Ask HN: Who is hiring? (November 2025)"}]}