fabruic VS bonsaidb

For today, I've chosen to use my best guess as to the best type of blocking wrapper for each type of operation, but the long-term goal is utilizing a new async executor that Daxpedda is working on. It's compatible with tokio, but it already has a concept named block_on_blocking, which is an optimized version of blocking designed to more fairly block without needing to adopt a 'static lifetime requirement due to using spawn_blocking. He's about to resume working on the executor, but he was responsible for the QUIC-based networking stack PliantDB is using and is wrapping up a few last requests before moving on.

What about https://github.com/khonsulabs/bonsaidb? Progress seems stall since last summer but very cool project

There is Nebari which is the KV part of BonsaiDB I've used both successfully (and that is currently in production)

In BonsaiDb, I define entire test suites as macros. This crate has a common trait that has multiple implementations in different crates. Each implementation needs to be tested thoroughly. For cargo test to be able to work in each crate independently, I needed to have the #[test]-annotated functions in the crate being built. By using a macro, I can define the functions in one location and invoke the macro in each crate to import the test suite into that crate.

I'm finishing up a large refactor of BonsaiDb which will add support for using BonsaiDb in non-async code.

I'm working on a major refactoring of BonsaiDb, aiming to improve the design of several interrelated features. While it started by aiming to enable a non-async interface for BonsaiDb, I realized mid-refactor that another major refactor would be better to do simultaneously rather than separately. Thank goodness that refactoring in Rust is such a wonderful experience!

For collections, we haven't addressed migrations yet. It's one of the higher priority things on my mind, however, so it probably will be in the next release.

It depends on what you mean by "support graphs". If you mean support the abillity to build a GraphQL interface in front of it, yes that is already possible in a limited fashion, although there are no first-class relationship types yet.

Replication is not implemented yet.

The README has a link to the code coverage report. There is a common test suite that is run across all mechanisms that database access is offered, and there are additional crate-specific tests as needed.

I'm trying to release the first alpha of BonsaiDb. I'm wrapping up replacing OPAQUE with Argon2, in an effort to make upgrading less likely to cause issues in the future (given that OPAQUE is still a draft protocol). I still love OPAQUE and will bring it back in the future.