FASTER VS skiplistrs

You would be surprised by performance of modern .NET :)

Writing no-alloc is oftentimes done by reducing complexity and not doing "stupid" tricks that actually work against JIT and CoreLib features.

For databases specifically, .NET is actually positioned very well with its low-level features (intrisics incl. SIMD, FFI, struct generics though not entirely low-level) and high-throughput GC.

Interesting example of this applied in practice is Garnet[0]/FASTER[1]. Keep in mind that its codebase still consist of un-idiomatic C# and you can do way better by further simplification, but it already does the job well enough.

[0] https://github.com/microsoft/garnet

[1] https://github.com/microsoft/FASTER

A vaguely similar project that might be of interest is: https://github.com/microsoft/FASTER

It's also an "unbundled" low-level component that one could use as the foundation for a database engine or whatever. According to Microsoft, FASTER is not just "fast", but significantly faster than even some basic in-memory data structures that ship in the .NET standard library!

The downside is that it doesn't (yet) support some more advanced features like multi-server distributed mode.

However, that relative simplicity may be preferred in some scenarios...

Last time i looked into it there weren't that many i could find. There is https://github.com/tikv/tikv which uses rocksdb with raft. and there is faster https://github.com/microsoft/FASTER/ .

you could use fasterkv https://github.com/microsoft/FASTER

FTA, https://github.com/Microsoft/FASTER/wiki/Performance-of-FAST...

Sure - here's a simple fuzzer from a rope (fancy string) library I wrote a few years ago back when I was still learning rust. (Don't judge me!):

https://github.com/josephg/skiplistrs/blob/master/tests/test...

In a loop it simply randomly decides whether to insert, delete or replace some text, and after any action checks that the state is valid (In this case via a call to check2()).

You can go way deeper with this sort of thing if you want, with more complex models, random item generation and simplifiers to help pare down problems to simple test cases. And you can have more complex state - for example, where you also track interaction between multiple items. For example, if your state is a few users, and you also track one user paying another user and verify the total balance across all users is unchanged.

But you don't need to go deep for fuzz testing to be worthwhile. Even something as simple as this little loop is a remarkably effective bug finder.