We are working on our `all-in-one docs` which will explain everything.
I want to address that we are not meant to "get rid of" RocksDB (which lots of KV engine claimed). What we want to do is provide another solution for storage engine users with different road path (focusing on new hardware and heavy-write workloads).
For simple use cases, there will be no difference no matter what engine you use.
And for most cases, upgrade your hardware (e.g. SATA SSD to NVMe SSD) or tuning your RocksDB parameters would save you lots time, just make sure you understand what you are doing.
There's no cue for every workloads, try TerarkDB if RocksDB happens not fit your scenario.
The reasons we did a better job(from our own perspective) than RocksDB are:
1. We moved lots of code out side db_mutex (db mutex is convenient but costs too much)
2. We introduced a new KV separation implementation that we believe is better than RocksDB’s implementation (we didn't hear any production user are using RocksDB's KV separation yet)
3. We introduced a lazy compaction strategy that can delay compaction task while online services are dealing with short-time heavy writing.
4. Other optimizations like time histogram based TTL, pipelined WAL sync.
