nebari VS sled

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.

a few times, seems interesting. The author's also built a lot of other cool concurrency primitives for Rust as well.

[0] https://github.com/spacejam/sled

- Dropbox [3] uses a similar approach but they talk about it a bit more abstractly.

Sans-IO is more documented in Python [4], but str0m [5] and quinn-proto [6] are the best examples in Rust I’m aware of. Note that sans-IO is orthogonal to deterministic test frameworks, but it composes well with them.

With the disclaimer that my opinions are mine and mine alone, and don’t reflect the company I work at —— I do work at a rust shop that has utilized these techniques on some projects.

TigerBeetle is an amazing example and I’ve looked at it before! They are really the best example of this approach outside of FoundationDB I think.

[0]: https://risingwave.com/blog/deterministic-simulation-a-new-e...

[1]: https://risingwave.com/blog/applying-deterministic-simulatio...

[2]: https://dropbox.tech/infrastructure/-testing-our-new-sync-en...

[3]: https://github.com/spacejam/sled

[4]: https://fractalideas.com/blog/sans-io-when-rubber-meets-road...

[5]: https://github.com/algesten/str0m

[6]: https://docs.rs/quinn-proto/0.10.6/quinn_proto/struct.Connec...

Sled uses bw-tree actually https://github.com/spacejam/sled/wiki/sled-architectural-outlook

There is a valid argument to be made for threads over async in a large percentage of use cases where async is considered the default. If this is what you are referring to however, I don't think they ever referred to async as completely useless: https://github.com/spacejam/sled/issues/1123.

Have you looked into other pure-Rust databases as well, such as sled or GlueSQL which has an SQL interface on top of sled? I wonder how those would compare to Persy.

I'm not sure what you need. Are these of any use? https://github.com/meilisearch/heed https://github.com/spacejam/sled

There is also Sled but as I understand it that is being reworked to use the author's new DB core Marble

There are some databases like sled/FlashDB designed to be embedded to other applications even bare metal microcontrollers. But I do doubt the potential bussiness value of a pure embedded database.

https://github.com/spacejam/sled

To add transaction support, you probably need a good understanding of how the memtable works in Log Structured Merge trees: