The storage engine is and always was a fairly heavily modified asynchronous version of sqlite's btree. It's been extremely reliable, which was always our top priority, and the performance isn't bad. But honestly when there was a problem with it our development velocity improving it wasn't great.

It's super easily pluggable[1], so now that it is open source people can experiment with other engines. I think there is a lot of room for improvement. Also architecturally it's designed in anticipation of being able to run different storage engines for different key ranges and for different replicas. For example, you might keep one replica in a btree on SSD (for random reads) and two on spinning disks in a log structured engine.

[1] https://github.com/apple/foundationdb/blob/master/fdbserver/...

It looks to me like Apple has made a pretty complete release of the key/value store. What's missing is

(1) Layers! Everything from relational databases to full text search engines to message queues

(2) Monitoring stuff. Unsurprisingly it doesn't look like we have the tools for monitoring log files, etc. Wavefront (also a major user!) is a great commercial solution, but there should be something OSS

Truthfully at Wavefront we've taken the json status directly into telegraf. Plus a bunch of python tooling to massage additional telemetry on a clusters health (coordinator reachability for example).

Plus even more tooling (mostly Ansible) for managing large fleets.

I saw @spullara do pretty neat stuff with our log files in Wavefront.

Will you guys think about open sourcing tooling? Apple is realistically never going to do that stuff.

Everything is fair game, being a monitoring company, we certainly will have first-class fdb support. We already have tons of workflows and templates.

The storage engine has always been SQLite for the SSD engine.

I don't think that is correct. My understanding from using fdb for years in production was that sqlite was the storage engine.