[monstrado]

Have nothing but praise for FoundationDB. It has been by far the most rock solid distributed database I have ever had the pleasure of using. I used to manage HBase clusters, and the fact that I have never once had to worry about manually splitting "regions" is such a boon for administration...let alone JVM GC tuning.

We run several FDB clusters using 3-DC replication and have never once lost data. I remember when we wanted to replace all of the FDB hardware (one cluster) in AWS, and so we just doubled the cluster size, waited for data shuffling to calm down, and just started axing the original hardware. We did this all while performing over 100K production TPS.

One thing that makes the above seamless for all existing connections is that clients automatically update their "cluster file" in the event that new coordinators join or are reassigned. That alone is amazing...as you don't have to track down every single client and change / re-roll with new connection parameters.

Anyway, I talk this database up every chance I get. Keep up the awesome work.

- A very happy user.

[maxpert]

How would it compare to say something like hosted Redis, or if you wanna be more fancy ElasticSearch. I have been looking into FDB for pretty long time and have been looking for a perfect opportunity to use it. Would be helpful if you can describe your usage scenario (kind of data you are storing).

[monstrado]

The key takeaways of FoundationDB is that it is a strongly consistent KeyValue store that preserves ordering (lexicographical). Although you might consider FDB's APIs to be quite primitive (get/set/scan), the payoff is how it seamlessly handles multi-key transactions without requiring you to write or manage some client side two-phase-commit process.

Given these primitives, you or other engineers can write higher level APIs on top (e.g. sql, search, etc). In fact, we make extensive use of their RecordLayer [1] library which provides a strongly consistent schema based write process using Protobuf. This includes on-write-consistent indexes. Apple has also open-sourced a MongoDB API [2] compliant interface that allows you to get all the consistency guarantees from FDB, but with an API interaction of MongoDB.

The beauty of FDB is that the primitives are done in such a rock solid fashion, you can write higher level APIs without having to worry about the really hard stuff (transactions, failures, config errors, testing, simulation, etc). Another example is that CouchDB is switching their back-end to use FDB for their 4.0 release.

Given that the database sorts data lexicographical...to us, it became a natural fit for an online (always-mutable) time-series database.

If you want more insight in how we use it, I go over it in some detail towards the end of my keynote [3] from last August.

[1] https://www.foundationdb.org/blog/announcing-record-layer/

[2] https://github.com/FoundationDB/fdb-document-layer

[3] https://www.youtube.com/watch?v=93b--lTq2ng