Redis Commands Reference

A grouped, offline Redis command lookup

Redis commands map onto its data structures — strings, hashes, lists, sets and sorted sets — plus a set of generic key commands. This reference lets you search commands by name or description and filter by data structure, showing the syntax, the time complexity and the version each command appeared in. It runs entirely in your browser.

How it works

Each entry lists the command, the data structure it operates on, the syntax with placeholders, the Big-O time complexity and the Redis version it was introduced in. Because Redis executes commands one at a time on a single thread, the time complexity tells you whether a command is safe to run on a large key. A few common patterns:

SET session:42 "{...}" EX 3600      # value + 1-hour TTL atomically
INCR page:views                     # atomic counter
ZADD leaderboard 99 "alice"         # add scored member
ZRANGE leaderboard 0 9 WITHSCORES   # top 10 by score
SCAN 0 MATCH user:* COUNT 100       # iterate keys without blocking

Data structures and their commands

Understanding which structure fits a use-case is half the job. Here is a quick mapping of real-world needs to the right Redis type:

Understanding time complexity in a single-threaded server

Redis processes one command at a time. An O(1) command like GET or HGET completes in a fixed number of steps regardless of data size and is always safe. An O(N) command like LRANGE or SMEMBERS scales linearly with the number of elements in the structure: fast on a 100-item list, potentially server-blocking on a 1,000,000-item list. This is why commands like KEYS, HGETALL, and SMEMBERS should never be used in production on large keyspaces or large structures without explicit knowledge of the size.

The safer alternatives that iterate without blocking are:

SCAN   cursor MATCH pattern COUNT hint    # iterates keyspace in batches
HSCAN  key cursor MATCH pattern COUNT n   # iterates a hash's fields
SSCAN  key cursor MATCH pattern COUNT n   # iterates a set's members
ZSCAN  key cursor MATCH pattern COUNT n   # iterates a sorted set

Each returns a cursor to continue from; when the cursor returns 0 the iteration is complete.

Common patterns in production

Session caching — SET session:{id} {json} EX 3600 stores a session with an automatic 1-hour TTL in a single atomic command, eliminating the race where a key exists briefly without an expiry.

Rate limiting — A sorted set stores requests as members scored by timestamp. ZADD, ZREMRANGEBYSCORE, and ZCARD together implement a sliding-window rate limiter in three commands, which can be wrapped in a Lua script for atomicity.

Real-time leaderboard — ZADD scores {score} {userId} on every game event, then ZREVRANGE scores 0 99 WITHSCORES fetches the top 100 in O(log N + 100) time, staying fast no matter how many total players exist.

Tips and examples

• Prefer SCAN over KEYS and HSCAN/SSCAN/ZSCAN over their bulk equivalents on large keys to avoid blocking the server.
• Always set an expiry on cache keys with EXPIRE or SET ... EX so memory does not grow unbounded.
• Use BLPOP/BRPOP to build a simple blocking work queue without polling.
• Sorted sets make excellent leaderboards and rate-limiters because score-based range queries are O(log N + M).
• Use MULTI/EXEC or Lua scripts when atomicity across multiple commands matters.