FoundationDB is absolutely incredible and I've been wondering why it doesn't get more popular over time. I suspect it's too complex to use directly in most applications, with people used to SQL-based solutions or simple KV stores.
I always wanted my app to use a fully distributed database (for redundancy). I've been using RethinkDB in production for over 8 years now. I'm slowly rebuilding my app to use FoundationDB.
What I discovered when I started using FDB surprised me a bit. To make really good use of the database you can't really use a "database layer" and fully abstract it away from your app. Your code should be fully aware of transaction boundaries, for example. To make good use of versionstamps (an incredible feature) your code needs to be somewhat aware of them.
I think FDB is a great candidate for implementing a "user-friendly" database on top of it, and in fact several databases are doing exactly that (using FDB as a "lower layer"). But that abstracts away too much, at least for me.
The superficial take on FDB is "waah, where are my features? it doesn't do indexing? waaah, just use Postgres!".
But when you actually start mapping your app's data structures onto FDB optimally, you discover a whole new world. For example, I ended up writing my indexing code myself, in my language (Clojure). FDB gives you all the tools, and a strict serializable data model to work with — your language brings your data structures and your indexing functions. The combination is incredible. Once you define your index functions in your language, you will never want to look at SQL again. Plus, you get incredible features like versionstamps — I use them to replace RethinkDB changefeeds and implement super quick polling for recent changes.
Oh, and did I mention that it is a fully distributed database that correctly implements the strict serializable consistency model? There are very few dbs that can claim that. If you understand what that means, you probably know how incredible this is and I don't have to convince you. If you think you understand, I suggest you go and explore https://jepsen.io/consistency — carefully reading and learning about the differences in various consistency models.
I really worry that FoundationDB will not become popular because of its inherent complexity, while worse solutions (ahem, MongoDB) will be more fashionable.
I would encourage everyone to at least take a look at FDB. It really is something quite different.
This is absolutely right. I built Wavefront's telemetry store and entity store directly on top of it and for all these reasons you can do magical things using it natively. These are also the reasons I recommended it for Snowflake's metadata store. Finally, it is why I invested in the company. FDB is insanely good if you take advantage of it.
FDB is fault-tolerant, auto-scaling, auto-healing, and auto-sharding. The sorted bytes-to-bytes map data format and multi-row transactions lets a skilled developer build almost anything on top of it. Atomic operations let you do things with higher performance without worrying about conflicts. Ops can be a learning curve but it is mostly because people run it at the red-line 24/7 for maximum efficiency. If you were running it at 3/4 capacity you would never worry about it at all. A single binary for all roles makes it very easy to deploy.
> The superficial take on FDB is "waah, where are my features? it doesn't do indexing? waaah, just use Postgres!".
i love fdb, but, most people _should_ just use postgres. you should have a very precise explanation for why you want fdb instead of postgres. you're trading away a lot of things when you go to fdb.
> I would encourage everyone to at least take a look at FDB.
yes, make sure you're aware of it so you can spot the situations where it _is_ the right answer.
I always wanted my app to use a fully distributed database (for redundancy). I've been using RethinkDB in production for over 8 years now. I'm slowly rebuilding my app to use FoundationDB.
What I discovered when I started using FDB surprised me a bit. To make really good use of the database you can't really use a "database layer" and fully abstract it away from your app. Your code should be fully aware of transaction boundaries, for example. To make good use of versionstamps (an incredible feature) your code needs to be somewhat aware of them.
I think FDB is a great candidate for implementing a "user-friendly" database on top of it, and in fact several databases are doing exactly that (using FDB as a "lower layer"). But that abstracts away too much, at least for me.
The superficial take on FDB is "waah, where are my features? it doesn't do indexing? waaah, just use Postgres!".
But when you actually start mapping your app's data structures onto FDB optimally, you discover a whole new world. For example, I ended up writing my indexing code myself, in my language (Clojure). FDB gives you all the tools, and a strict serializable data model to work with — your language brings your data structures and your indexing functions. The combination is incredible. Once you define your index functions in your language, you will never want to look at SQL again. Plus, you get incredible features like versionstamps — I use them to replace RethinkDB changefeeds and implement super quick polling for recent changes.
Oh, and did I mention that it is a fully distributed database that correctly implements the strict serializable consistency model? There are very few dbs that can claim that. If you understand what that means, you probably know how incredible this is and I don't have to convince you. If you think you understand, I suggest you go and explore https://jepsen.io/consistency — carefully reading and learning about the differences in various consistency models.
I really worry that FoundationDB will not become popular because of its inherent complexity, while worse solutions (ahem, MongoDB) will be more fashionable.
I would encourage everyone to at least take a look at FDB. It really is something quite different.