Redis is single-threaded for dataset-modifying commands (SET, DEL, etc.), but multi-threaded for networking and I/O. nubmq, on the other hand, is fully multi-threaded—distributing reads and writes across all cores. So yes, this is fundamentally a comparison between Go’s concurrency model and Redis’s single-threaded event loop.

For benchmarking, I used the same test script (included in the repo) for both Redis and nubmq—100 concurrent clients hammering the server with requests. The core execution models remain unchanged; only the endpoints differ. So if you're asking whether the comparison reflects actual engine throughput rather than just connection handling—yes, it does.

The real ‘secret sauce’ is how nubmq prevents bottlenecks under load. When per-shard contention spikes, it spins up a larger store in the background, shifts new writes to it, and lazily migrates keys over. No pauses, no blocking. Meanwhile, Redis has no way to redistribute the load—it just starts choking when contention builds.

Also, Redis carries Lua scripting overhead in some cases. nubmq skips all that—pure Golang, no dependencies, no interpreter overhead

Even if so, that's besides the point IMO. I for one would prefer to use software that makes full use of the system's resources. Bonus points if this is a knob that we can turn.