Why Redis Hashes Beat Multiple Keys for Object Caching

The Problem: Cache Bloat from String Keys

When caching user profiles, storing each attribute as a separate Redis string key creates memory fragmentation and key management overhead. For a user with 10 fields, you'd need 10 separate keys instead of one cohesive entry.

The Solution: Hashes for Structured Data

Redis Hashes let you store object representations efficiently. A single hash key can hold multiple field-value pairs, reducing key count and improving cache locality. This approach also simplifies operations like retrieving all user data at once.

Setting and Retrieving Hash Data

Use HSET to store multiple fields atomically, then HGETALL to retrieve the complete object:

# Set user profile fields in one operation
HSET user:123 name "Alice" email "[contact removed]" age 30

# Retrieve all fields at once
HGETALL user:123

# Get a specific field
HGET user:123 email

Adding Automatic Expiration

Combine Hashes with TTL to prevent stale data accumulation. Set expiration immediately after caching:

# Cache with 5-minute expiration
HSET user:123 name "Alice" email "[contact removed]"
EXPIRE user:123 300

# Or use SETEX for strings (not available for hashes)
# Instead, set TTL right after HSET
HSET user:123 name "Alice"
TTL user:123

Verifying Your Implementation

Check that your hash was stored correctly and TTL is working:

# Verify hash contents
redis-cli HGETALL user:123

# Check remaining TTL (in seconds)
redis-cli TTL user:123

# Confirm memory usage per key
redis-cli MEMORY USAGE user:123

Trade-offs and Limitations

While Hashes are efficient, they have practical limits. Redis recommends keeping hash field counts under 1 million, and individual field values should stay under 16KB. For very large objects, consider whether partial updates are needed or if the object should be serialized differently.

Memory overhead increases with field count, and retrieving all fields with HGETALL can be slow for large hashes. If you frequently access only specific fields, Hashes still work well, but if you need the entire object regularly, consider JSON serialization in a String key instead.

Actionable Next Steps

Audit your current caching strategy. If you're using multiple string keys for related data, migrate to Hashes. Test the memory savings with redis-cli --bigkeys before and after. Set appropriate TTL values based on your data's volatility—frequently changing data needs shorter expiration times.