Hacker News Reader

Comment by nlavezzo | Hacker News Reader

The core product is a distributed, highly fault tolerant ordered Key Value store with true serializable ACID transactions. All of the layers (including document, graph) sit on top of that and inherit its ACID properties, scalability, fault tolerance, etc. It doesn't appear to me that they released any of the top level layers, but those are MUCH simpler to build, and that's where the OS community can step in.

View on HN

How is FoundationDB's graph performance/feature set compared to those of other graph and multi-model databases?

FoundationDB at its core is not a graph database. You could build a graph database on top of it, using FoundationDB as a very strong and feature rich storage engine, however you'd like. It would be much simpler to do than building a new (especially a distributed) graph database from scratch.

So FDB's role is more comparable to that of, say, RocksDB or LevelDB than an application-level database like Postgres?

I didn't really pay much attention to Foundation before Apple bought them and am unsure how it fits in the wider database ecosystem.

You can think of FDB as a distributed storage engine. It has the same low level data model as the engines you mention, but has distributed transactions, fault tolerance, automatic data partitioning, operational tooling, etc built in. So if you build an "application level database" or library on top of it, it is automatically a distributed database.

Yes, but with an important caveat: Getting ACID transactions to work correctly across multiple machines is the really hard part. FDB is providing a KV store (across multiple machines) kind of like RocksDB does (on one machine), but it's also solving that really hard problem for you. That puts it in kind of a different league.

Reply on news.ycombinator.com