nebari VS bonsaidb

Or, you could also look at Nebari, which underlies BonsaiDB https://github.com/khonsulabs/nebari/

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

This looks like it could have been inspired by BonsaiDB's recent problems. I think the authors are now trying to achieve something similar to your project with a new storage layer called Sediment (which will become a part of Nebari if successful).

I ran my benchmark suite on my 2017 i7 MacBook Pro (Filevault enabled), and I was able to perform a random "get" operation out of a 1 million record dataset in an average of 18us (microseconds).

I haven't spent much time documenting the low-level structures outside of the code itself.

Nebari, the underlying storage layer, also has its own coverage report.

Quite well, but Sled doesn't support the same feature set. I've benchmarked our low-level storage layer against Sled in its own repostiory: Nebari Benchmark README. There are two links two criterion reports on that page.

I maintain several large codebases that have #![forbid(unsafe)] annotations, which prevent unsafe code from being written in those codebases directly. BonsaiDb clocks in at just shy of 30k LOC, and depends on Nebari which is another 12k LOC. Those two crates make up the bulk of a networked database implementation.

I have, and there's a set of microbenchmarks in the repository. There are two links to reports on that page -- one that's executed on GitHub Actions, which can have quite widely varying performance, and one that's executed on a "dedicated" VPS instance from Scaleway -- exact specs are on that page. I've kicked off another run on that VPS, since it hasn't been run since October. It takes a while to run, so if it still says October, try hitting refresh a little later.

I replaced Sled in BonsaiDb with a new storage layer I wrote: Nebari. I just wrote a post this morning recalling my struggles over the last month to feel comfortable sharing this project outside of a smaller group of people.

I do have ideas in the issue tracker on some of the next steps towards an actual migration system.

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.

hey, just letting you know that there already is a project called bonsai-db and some people might confuse bonsai-bt as part of that project

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!

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.

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.