ld VS sled

I slammed together a database based on this wire protocol feature: MikkelHJuul/ld the database serve bytes, the client can deserialize those by replacing the bytes with a message (in the proto-file)

Hell, I even built a kv-database myself that I just announced some weeks ago, based on badgerDB: ld. It's API is the api I would say qualifies as a simple actual kv database api. KeyRange { String prefix, from, to, pattern (pattern may be a bit over the top) } The database is value agnostic

[ld:0.1.3](https://github.com/MikkelHJuul/ld) is out

Just after pushing 'Post'; I thought to my self: I haven't done nearly enough testing! This is release [0.1.1](https://github.com/MikkelHJuul/ld/pull/2) focusing on testing, I fixed some bugfixes with the `Iterator` in `impl/iterator.go`, but mostly I added 50-some tests spanning 900 lines of test code.

I got my database into a release candidate: ld - a protocol buffers database

The obvious use case is the one of a key value database: I have an older personal project I wanted to do this for, ld (yes I know there is a c linker called ld) basically the client implements their proto file saving whatever they wanted at a given key and the database never touch the bytes, it servers back those bytes which should be re-serialisable to the same object. (The project is semi abandoned, I hope to use badger or boltdb to implement it some time)

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: