 <p>To understand why these kind of operations seem non-trivial in NoSQL implementations, it's good to think about why NoSQL exists (and has become very popular) at all.</p> <p>When you look at an early NoSQL implementation like memcached, the first use case was very simple, but very important: a blazingly fast cache for distributed data, to cache for example web page data. Very quickly stuff like clustering and sharding was added, so not all data has to be available everywhere at once at every single node in the cluster, but can be gathered on demand.</p> <p>NoSQL is very different from relational data storage. Don't overuse it. Consider relational databases as well, as they are sometimes far more suited for what you are trying to accomplish. In everything you design, ask yourself "Does this scale well?".</p> <p>Okay, back to your question. It is in general bad practice to do wildcard searches. You prepare your data in a way that you can retrieve your data in a scalable way.</p> <p>Redis is a very chique solution, allowing you to overcome a lot of NoSQL limitations in an elegant way.</p> <p>If getting "a list of all users" isn't something you have to do very often, or doesn't need to scale well, is always "I really always want <strong>all</strong> users" because it's for a daily scan anyway, use <code>HSCAN</code>. <code>SCAN</code> operations with a proper batch size don't get in the way of other clients, you can just retrieve your records a couple of thousand at a time, and after a few calls you've got everything.</p> <p>You can also store your users in a <code>SET</code>. There's no ordering in a set, so no pagination. It can help to keep your user names unique.</p> <p>If you want to do things like "get me all users that start with the letter 'a'", I'd use a <code>ZSET</code>. I'd wait a week or two for <code>ZRANGEBYLEX</code> which is just about to be released, in the works as we speak. Or use an ORM like Josiah Carlsons's 'rom' package.</p> <p>When you ask yourself "But now I have to do three calls instead of one when storing my data...?!": yup, that's how it works. If you need atomicity, use a Lua script, or MULTI+EXEC pipelining. Lua is generally easier.</p> <p>You can also ask yourself if using a <code>HSET</code> is needed. Do you need to retrieve the individual data members? Each key or member has some overhead. On top of that, <code>HGETALL</code> has a Big-O specification of <code>O(N)</code>, so it doesn't scale well. It might be better to serialize your row as a whole, using JSON or MsgPack, and store it in one <code>HSET</code> member, or just a simple <code>GET</code>/<code>SET</code>. Also read up on <code>SORT</code>.</p> <p>Hope this helps, TW</p>