Really appreciate that @antirez takes the time to add features in a way that doesn’t negatively impact old features where possible, for example if I don’t want to use ACL, I don’t have to jump through hoops or assign universal high level access that I have to undo later. Thanks!

Much love for the hard work of @antirez and the whole team, such an incredible and usually bulletproof part of everyone's infrastructure.

Thanks for updating Disque, @antirez. I've been watching the GitHub issues and Twitter like a hawk. :)

Can't wait for Threaded I/O as our app main bottleneck in some deployments was Redis.

Threading can help up to a given point but sharing is the way to go.

One of our bottlenecks was really big keys (>1MB) being written and read too often and effectively stealing all the CPU time. That was fixed in the app by reducing the number of operations + compression. Threaded IO will give us a little more room.

Other use case involves LUA scripts that operate on 5 different keys, so cluster/proxy is out of question.

Genuinely curious, why do you need such big keys ? Can't you hash them so you get nice short SHA-X strings for instance ?

I run a fork called KeyDB with multithreading as well as a few optimizations directly around large values (redis does unnecessary copies).

It may work well for your use case. https://github.com/JohnSully/KeyDB

Oh I saw a wonderful (private) fork about this, sending very large keys using threads.

This got me thinking about using Redis and I needed a review of what is open source and what isn't: https://redislabs.com/legal/licenses/

All Redis 6 is BSD licensed. The Disque module and the Cluster Proxy are AGPL. The link you posted is only relevant for the Redis Labs commercial modules that are not part of this release.