My team and I have spent most of the last 2 years working on Key-Value Stores and the surrounding ecosystem, and we are finally starting to open-source some of the pieces. One of them can be of value to the FoundationDB community. It is called UKV. It is a shared C-level representation layer for KVS.
On top of the binary strings abstraction, we have built Document collections, Graph collections, and Vector indexes (in progress), similar to RedisJSON, RedisGraph, and RediSearch, but better. Document/tabular collections, for instance, feature both JSON, BSON, and MessagePack native support, as well as JSON-Pointer, JSON-Patch, JSON-MergePatch, and other RFC standards.
Moreover, UKV comes with a client-server communication library built on top of Apache Arrow Flight RPC, a combination of gRPC and Arrow IPC. This makes the data stored in KVS accessible to the most commonly used analytical tools, such as Ray, PyTorch, and ClickHouse!
UKV is implemented in C, so adding higher-level bindings is a piece of cake. We now have bindings for C++, Python, basic Java, and GoLang, and we plan to start working on JS soon. All under one umbrella. Identical SDKs across different stores, persistent or volatile, consistent or not, sharded or singe-node. Our SDKs take some time to craft as we minimize data copies on the hot paths but provide the simplicity of famous Python libraries people love. As such, tabular collections mimic Pandas, and graph collections mimic NetworkX, yet work with orders of magnitude more data, often stored on a remote disk.
We don’t have a single distributed KVS backend at this point, and we thought FoundationDB could be the first one. If the features mentioned above sound relevant, join the discussion 