redb VS sled

I wrote redb (https://github.com/cberner/redb) using mmap, initially. However, I later removed it and switched to read()/write() with my own user space cache. I'm sure it's not as good as the OS page cache, but the difference was only 1.2-1.5x performance on the benchmarks I cared about, and the cache is less than 500 lines of code.

exposure of the redb builder functionalities.

redb has reached its 1.0 release. The file format is now gauranteed to be backward compatible, and the API is stable. I've run pretty extensive fuzz testing, but please report any bugs you encounter.

I'm just now updating the benchmarks in the readme with multi-threaded workloads :) https://github.com/cberner/redb/pull/576

redb, but that doesn't have a stable file format yet,

I also have to support web, so I'm considering a hybrid approach with a direct IndexedDB API there and something like sqlite, percy, sanakirja, or redb on native.

Nice list, but don’t forget persy, redb and sanakirja too!

check out https://github.com/cberner/redb! it is inspired by LMDB and has comparable performance, but is entirely built in rust!

Yup, the language is immature in some domains like data replication, compilation time, lifetime expressivity, not having a default async runtime and the incompatibility of all of them. But many of these domains are worked on and improved every day this is why I love this language so much. This is because there is space for improvement. I also hope that one day we will have a pure-Rust LMDB alternative that I can contribute to without fear of C.

they are, ya! I'm quite excited about that, and already have a PR open to use GATs. It's not enough to fix this issue though, because std needs to add support for LendingIterator too

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: