Hashes in Redis

Analogy categoryAnalogies

What Redis Hashes Are

A Redis hash is a map of field-value pairs stored under a single key, similar to a dictionary or a single row in a table, making it a natural way to represent an object like a user profile or a product without serializing the whole thing into one JSON string. Small hashes (by default under 128 fields and 64 bytes per field, configurable via hash-max-listpack-entries and hash-max-listpack-value) are stored in a compact listpack encoding, which is both memory-efficient and fast for full reads.

🏏

Cricket analogy: A Redis hash is like a single player's stat card in a scorebook — name, runs, strike-rate, and wickets are all separate fields under one player like Virat Kohli, and you can update just the 'runs' field without touching the rest of the card.

Reading and Writing Fields

HSET sets one or more fields on a hash in a single call, HGET reads a single field, and HMGET reads several named fields at once, while HGETALL returns every field-value pair — useful for loading a full object in one round trip. HINCRBY and HINCRBYFLOAT apply the same atomic-increment guarantee that strings get with INCR, but scoped to a single field, which is ideal for things like a 'view count' field living alongside other metadata on the same object.

🏏

Cricket analogy: HSET is like a scorer updating just the 'strike rate' field on a batter's card mid-innings, while HGETALL is like pulling the entire scorecard for Rohit Sharma at once to display on the broadcast graphic.

bash

# Create/update multiple fields on a hash in one call
HSET user:1001 name "Alice" email "alice@example.com" plan "pro"

# Read a single field
HGET user:1001 email

# Read several named fields
HMGET user:1001 name plan

# Read the whole object
HGETALL user:1001

# Atomically bump a numeric field
HINCRBY user:1001 login_count 1

# Remove a field, check existence, count fields
HDEL user:1001 plan
HEXISTS user:1001 email
HLEN user:1001

When to Use a Hash vs. a JSON String

A common design decision is whether to store an object as a single JSON-encoded string or as a native Redis hash. A hash lets you read or update individual fields without transferring or re-parsing the whole object, and HINCRBY gives you atomic per-field counters that a JSON string simply cannot offer without a full read-modify-write cycle; a JSON string, on the other hand, is simpler when you always read or write the entire object together and want to preserve nested structures that hashes can't represent natively, since hash values are flat strings, not nested objects.

🏏

Cricket analogy: Choosing a hash is like keeping a live per-field scorecard you update ball by ball, while a JSON string is like waiting until the innings ends and publishing one full match report — fine if you never need the mid-innings 'runs' field alone.

Small hashes (few fields, short values) use Redis's listpack encoding internally, which is significantly more memory-efficient per field than storing thousands of separate top-level string keys like user:1001:name, user:1001:email, and so on — grouping related fields into one hash is often both faster and cheaper.

Hash field values are always flat strings — Redis hashes cannot nest another hash or array inside a field. If your object naturally has nested structure (like an address sub-object or a list of tags), either flatten it into separate top-level fields, store it as a JSON string in one field, or use RedisJSON if the module is available.

A Redis hash maps field names to string values under one key, ideal for modeling objects like user profiles.
HSET/HGET/HMGET/HGETALL let you write or read individual fields or the whole object in one round trip.
HINCRBY and HINCRBYFLOAT give atomic per-field counters that a JSON-string object cannot offer directly.
Small hashes use a compact listpack encoding, which is more memory-efficient than many separate string keys.
Choose hashes when fields update independently and frequently; choose JSON strings when the object is read/written as a whole or has nested structure.
Hash field values are flat strings only — no native nesting of hashes or arrays inside a field.