It didn't, but we identified something that could be done without throwing away our vision. Basically Redis remains completely single threaded, but once is about to re-enter the event loop, when we have to write replies to all the clients, we use threads just for a moment in that code path, and return single threaded immediately after. It is not as performant as full threading, but we believe the right thing to do is sharding and share-nothing. Yet this 2x improvement for the single instance was almost for free so... btw it's disabled by default.
KeyDB multithreads the entire event loop from end to end. This provides better performance [1], and combined with MVCC will put us in a place to support more expensive commands like searches without blocking other clients.
Woah, I missed that redis changed their mind about this. Clearly haven't been paying attention.