All kidding aside, how many different variations of K/V stores do we need these days? Are they really solving that drastically different of a problem amongst each other?
[project author here] The idea here was to actually sort of extend redis. People often ask "can redis do X" and get the answer that their use case is not broad enough, or it can be done with Lua, or simply no. then they ask what about plugins, and antirez is not inclined to add them anytime, probably rightfully so.
The aim here is to allow adding commands or creating custom subsets of the redis protocol - and allow easy extending of existing clients to support them; and having replication and persistence - the "boilerplate" of the database, already taken care of. Adding custom commands to the redis python client for example is trivial to the point where the client actually has handling for unknown commands.
BTW replication is also written as a plugin here and can be replaced by a more robust way, for example using RAFT as replication and failover method.
So this project started as scratching a personal itch for me - which makes me a 1 person niche at leat - and as a learning experience for Go. I don't know if the world needs it or not, nor do I care if it doesn't.
Go's garbage collector is exclusively stop-the-world, so it seems like this is going to die in a fire pretty quickly with a non-trivial heap size (more than 1GB). HotSpot's CMS collector (which is parallel & concurrent) has a pretty rough time with heaps >16G and it's been maturing for over a decade.
It's a function of the number of keys more than heap size directly. I've benchmarked the STW at 20ms pauses for ~2G if the values are ~10k each, and 200ms if the keys are 1K each at the same amount of RAM.
