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