What data types does Redis support?

Question

Accepted Answer

Redis supports several **data structures** as values — strings, lists, hashes, sets, sorted sets, plus specialized types (streams, bitmaps, HyperLogLog, geospatial). Choosing the right type for each use case is key to using Redis effectively.

## Core data types

```bash
# STRING — the simplest (text, numbers, even binary up to 512MB)
SET key "value"
INCR counter            # atomic increment (strings can be counters)

# LIST — ordered list of strings (a linked list — fast push/pop at ends)
LPUSH mylist "a"        # push left
RPUSH mylist "b"        # push right
LRANGE mylist 0 -1      # get all → useful for queues, recent-items

# HASH — a map of field→value (like an object/record)
HSET user:1 name "Ann" age 30
HGET user:1 name        # => "Ann"  → great for storing objects

# SET — unordered unique strings
SADD tags "redis" "cache"
SISMEMBER tags "redis"  # membership test; SINTER/SUNION for set operations

# SORTED SET (ZSET) — unique members each with a SCORE, kept ordered by score
ZADD leaderboard 100 "Ann" 90 "Bob"
ZRANGE leaderboard 0 -1 WITHSCORES   # ranked → leaderboards, priority queues
```

## Specialized types

```text
STREAM      → an append-only log (like a message queue/event log with consumer groups)
BITMAP      → bit operations on strings (compact flags, e.g. daily active users)
HYPERLOGLOG → approximate unique counts using tiny memory (cardinality estimation)
GEOSPATIAL  → store/query locations (geo radius queries)
```

## Choosing the right type

```text
String      → simple values, counters, cached serialized data
List        → queues, stacks, recent-items, activity feeds
Hash        → objects/records (store fields of an entity together)
Set         → unique collections, membership tests, tags, relationships
Sorted Set  → leaderboards, rankings, priority queues, time-ordered data
→ Picking the right structure makes operations efficient and natural.
```

## Why it matters

Understanding Redis's data types is fundamental to using Redis effectively, because Redis's power comes precisely from its **rich data structures** (not just simple key-value storage), so knowing them and when to use each is essential practical knowledge.

The **core types** each suit different needs: **strings** (simple values and atomic counters), **lists** (ordered collections for queues, stacks, and recent-items feeds), **hashes** (storing objects/records with multiple fields together — efficient for entities), **sets** (unique collections for membership tests, tags, and relationships, with set operations like intersection), and **sorted sets** (members ranked by score — the natural fit for leaderboards, rankings, and priority queues).

Understanding the **specialized types** — streams (append-only logs with consumer groups, for message queues and event sourcing), bitmaps (compact flags), HyperLogLog (approximate unique counts in tiny memory), and geospatial (location queries) — broadens what Redis can do efficiently.

Most importantly, **choosing the right type** for each use case (a sorted set for a leaderboard, a hash for an object, a list for a queue) is what makes Redis operations efficient and natural — using the wrong structure leads to awkward, slow solutions.

Since Redis's value comes from its data structures and using them appropriately is the core skill of working with Redis, and since the choice of structure directly determines whether operations are efficient and code is clean, understanding Redis data types — the core and specialized types and when to use each — is essential, frequently-applied knowledge for anyone using Redis, the foundation for leveraging Redis effectively beyond trivial key-value storage.