It's not that simple. It's never that simple.
These are incredibly complex pieces of software designed as generic solutions to a thousand different problems on dozens of platforms. For some combinations of platform+problem these KV stores will do great. But it would be terribly naive to assume it will work in every situation. I can guarantee there are workloads that RocksDB will do better with.
When badger was first released I was pretty skeptical of it... it seemed to be quite buggy, and I tinkered with swapping out our metrics database MDBM-based implementation (yeah that ancient yahoo KV store no one talks about), but it didn't turn out to be a good fit for the use case. It wasn't even in the same ballpark performance-wise. But I hoped that maybe in a few years it would mature.
This puff piece isn't changing my opinion of it...
The RocksDB folks seem to be a lot more honest about the realities of tuning KV stores: https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guid...
> Unfortunately, configuring RocksDB optimally is not trivial. Even we as RocksDB developers don't fully understand the effect of each configuration change. If you want to fully optimize RocksDB for your workload, we recommend experiments and benchmarking, while keeping an eye on the three amplification factors. Also, please don't hesitate to ask us for help on the RocksDB Developer's Discussion Group.
> It's not that simple. It's never that simple.
Yeah. The post that is linked[0] within that quote has a "Benchmarks" section, but it looks like they're either 100% reads or 100% writes. Most real workloads aren't like that.
> Badger is different from other LSM tree based DBs in that it colocates only small values or pointers along with these keys, storing the values separately in a value log.
> we decided to cut out RocksDB and Cgo entirely from our code base and write a fast key-value database purely in Go
