SableDb

Sharing the build configuration (e.g. did you make sure to build `sabledb` in release mode?) + threads configurations etc, worth mentioning.

Absolutely, adding more commands is my goal Completing a full-sync replication is my first priority (I have currently implemented a WAL tailing from primary -> replica) but tailing from a snapshot is the ideal solution IMO here.

Once this in place, adding "hash" commands (hset, hget etc) is the next family of commands. I open sourced it hopefully to get help from people out there :)

Also, it works mentioning that kvrocks is more mature and supports many more commands than what SableDb currently supports

It is multi-threaded (configurable, you can set it to a specific number configuration file, or use the magic value 0 where SableDb decides based on the number of cores divided by 2).

Each incoming connection is assigned to a worker thread, and two tokio tasks are created for the connection (one for reading and another for writing).

Using tokio allowed me to use the `async` code without using "callback hell" so the code looks clean and readable in a single glance without the need to follow callbacks

It performs better and uses different design choices (for example: SableDb uses tokio's local task per connection, and in general it uses green threads to make the code more readable and easy to maintain).

I will release some design documents later on (hopefully this month). Remember that is a one man project (hopefully, not for long), so it takes time to organize everything :)

So does OpenSSL, Bytes crates, WinAPI and many many other crates used by many Rust applications. Does this make applications written in Rust less "Rusties"?

IMO, the networking, threading and "tasks" ("green threads") in SableDb code base are the most risky part of writing a server and by choosing Rust, the risk of memory issues is reduced to minimum without scarifying performance

See my previous comment. Sled was considered, and it was the main KV storage in early implementation.

I kept the adapter approach in the code, so switching back to sled should be pretty easy (or even converting it to full in-memory)

The storage itself uses the rust binding for RocksDb

However, I did have a branch (in another repo) that uses other different storage, some are purely written in Rust, like "dash" (which is full in-memory), "sled" and "speedb". I eventually decided to stick with RocksDb since its well mature and maintained by some giant companies like Meta.

The user code (the one I wrote) is all Rust.

Also, one could also argue that the `bytes` crate that is heavily utilized in the code base of SableDb, uses plenty of `unsafe` code, does this make it less "Rust" ?