Because the original Redis is the fastest already ?
It only really works well if the client can shard the redis command to the right process itself.
Honestly, redis makes pretty sane tradeoffs, it's not worth the added complexity to add multi-threading as it would almost certainly slow it down while it does locking, and redis isn't typically CPU bound (except potentially the LUA stuff, but that's up to the user), so being multi-threaded doesn't really help much.
If you need multi-threading, there are other solutions, but of course they are slower w.r.t latency and throughput, since that's the trade-off.
Some performance number here - https://www.dragonflydb.io/blog/scaling-performance-redis-vs...
For example, if you care most about latency, Redis is still the way to go, while DragonFly seems better at throughput. But, tradeoffs vs tradeoffs and all that yadda yadda.
DragonFly is better at latency too. The latency numbers they are showing are measured at the high throughput. If you were to reduce the throughput, the latency number would be even better. From the same post:
> This graph shows that the P99 latency of Dragonfly is only slightly higher than that of Redis, despite Dragonfly’s massive throughput increase – it's worth noting that if we were to reduce Dragonfly's throughput to match that of Redis, Dragonfly would have much lower P99 latency than Redis. This means that Dragonfly will give you significant improvements to your application performance.
It might be interesting to have, say, a readonly slave builtin as a second threat that might return outdated information, but I doubt how much use you would get out of it.
I am kinda struggling to come up with a scenario where a significant part of the computational need of you app was in Reddis.