What Is Redis? An Introduction to In-Memory Data Stores

The Database That Lives in RAM

Most databases read from disk. Redis reads from memory. That single architectural decision makes it 100x faster than PostgreSQL or MySQL for key-value operations -- we're talking sub-millisecond latency at hundreds of thousands of operations per second on modest hardware. Redis (Remote Dictionary Server) was created by Salvatore Sanfilippo in 2009, and it's now maintained by Redis Ltd. under a dual license (RSALv2/SSPL as of Redis 7.4, released March 2024). The last truly open-source version is 7.2.

I've used Redis in production since 2014 across e-commerce platforms, real-time analytics pipelines, and SaaS products. It's one of those tools that once you understand it, you'll find excuses to use it everywhere. This guide covers what Redis actually is, what data structures it offers, how to get started, and where it makes sense in your stack.

What Is Redis?

Definition: Redis is an open-source, in-memory data structure store that functions as a database, cache, message broker, and streaming engine. Unlike traditional databases that persist data to disk first, Redis keeps the entire dataset in RAM and optionally writes snapshots or logs to disk for durability. It supports strings, hashes, lists, sets, sorted sets, streams, bitmaps, and HyperLogLogs natively.

Think of Redis as a programmable, networked dictionary that happens to be blindingly fast. You give it a key and a value, and it stores that pair in memory. But unlike a simple key-value store like Memcached, Redis supports rich data structures -- you can push to lists, intersect sets, increment hash fields, and rank items in sorted sets, all atomically. That's what makes it useful beyond basic caching.

Core Data Structures

Redis isn't just GET and SET. Its data structures are what separate it from every other caching layer. Each one maps to real-world use cases that would otherwise require multiple database queries or application-level logic.

Strings

The simplest type. A string value can hold up to 512 MB. Use strings for caching, counters, and flags.

# Store and retrieve a value
SET user:1001:name "Alice"
GET user:1001:name
# "Alice"

# Atomic counter -- perfect for rate limiting
INCR api:rate:192.168.1.1
EXPIRE api:rate:192.168.1.1 60

Hashes

A hash is a map of field-value pairs attached to a single key. It's the natural way to represent objects without serializing to JSON.

# Store a user profile as a hash
HSET user:1001 name "Alice" email "alice@example.com" plan "pro"
HGET user:1001 name
# "Alice"
HGETALL user:1001
# 1) "name" 2) "Alice" 3) "email" 4) "alice@example.com" 5) "plan" 6) "pro"

Hashes are memory-efficient for small objects. Redis internally uses a ziplist encoding for hashes with fewer than 128 fields and values under 64 bytes, consuming significantly less memory than equivalent string keys.

Lists

Doubly-linked lists. Great for queues, activity feeds, and recent-items lists.

# Push to a job queue
LPUSH jobs:email '{"to":"alice@example.com","template":"welcome"}'
LPUSH jobs:email '{"to":"bob@example.com","template":"reset"}'

# Worker pops from the other end (blocking)
BRPOP jobs:email 30

Sets

Unordered collections of unique strings. Useful for tags, permissions, and deduplication.

# Track unique visitors
SADD visitors:2026-04-12 "user:1001" "user:1002" "user:1001"
SCARD visitors:2026-04-12
# 2 (duplicates ignored)

# Set operations
SADD online:server1 "user:1001" "user:1002"
SADD online:server2 "user:1002" "user:1003"
SUNION online:server1 online:server2
# "user:1001" "user:1002" "user:1003"

Sorted Sets

Like sets, but every member has a score. Redis keeps them ordered by score, making sorted sets perfect for leaderboards, priority queues, and time-series indexes.

# Leaderboard
ZADD leaderboard 1500 "alice" 2300 "bob" 1800 "charlie"
ZREVRANGE leaderboard 0 2 WITHSCORES
# 1) "bob" 2) "2300" 3) "charlie" 4) "1800" 5) "alice" 6) "1500"

# Get rank (0-indexed)
ZREVRANK leaderboard "charlie"
# 1

Pub/Sub and Streams

Redis supports two messaging patterns. Pub/Sub is fire-and-forget: publishers send messages to channels, and all subscribed clients receive them in real time. There's no persistence -- if a subscriber is offline, the message is gone.

# Terminal 1: Subscribe
SUBSCRIBE notifications:user:1001

# Terminal 2: Publish
PUBLISH notifications:user:1001 "Your order shipped"

Redis Streams (introduced in Redis 5.0) are the durable alternative. Streams persist messages, support consumer groups, and provide at-least-once delivery semantics. Think of them as a lightweight Kafka for moderate throughput workloads (tens of thousands of messages per second).

# Add to stream
XADD events * type "purchase" amount "49.99" user "alice"

# Read with consumer group
XGROUP CREATE events mygroup $ MKSTREAM
XREADGROUP GROUP mygroup worker1 COUNT 10 BLOCK 5000 STREAMS events >

Persistence: RDB vs. AOF

Redis is an in-memory store, but that doesn't mean your data vanishes on restart. Redis offers two persistence mechanisms, and you should understand both.

Warning: Running Redis with no persistence enabled means a server restart loses all data. This is fine for pure caching, but catastrophic for session stores or anything you can't rebuild from another source. Always enable at least one persistence method for non-cache workloads.

RDB (Redis Database Snapshots) creates point-in-time snapshots of your dataset at configured intervals. It's compact, fast to load, and ideal for backups. The downside: you can lose data between snapshots. With the default config (save 3600 1 300 100 60 10000 in Redis 7.x), you could lose up to 5 minutes of writes.

AOF (Append Only File) logs every write operation. It's more durable -- with appendfsync everysec (the recommended setting), you lose at most 1 second of data. The trade-off is larger files and slightly higher write latency. Redis 7.0+ uses a multi-part AOF format that eliminates the need for AOF rewrite fragmentation.

My recommendation: enable both. Use RDB for fast restarts and disaster recovery backups. Use AOF for minimal data loss. Redis handles the combination natively and uses the AOF (more complete) file for recovery when both exist.

Getting Started with Redis

1. Install Redis -- On macOS, run brew install redis. On Ubuntu/Debian, use sudo apt install redis-server. For Redis 7.4+, use the official Redis packages from packages.redis.io. Docker works too: docker run -d --name redis -p 6379:6379 redis:7.4.
2. Start the server -- Run redis-server from the terminal. You'll see the Redis ASCII art logo and a message confirming it's listening on port 6379. For production, use the systemd service or your container orchestrator.
3. Connect with redis-cli -- Open another terminal and run redis-cli. Type PING and you should see PONG. You're connected.
4. Try basic commands -- Run SET hello "world", then GET hello. Experiment with HSET, LPUSH, and ZADD to feel the data structures.
5. Enable persistence -- Edit redis.conf to enable AOF: set appendonly yes. Restart Redis. Your data now survives restarts.
6. Set a password -- Add requirepass your-strong-password to redis.conf. In Redis 6.0+, use ACLs for granular per-user permissions with ACL SETUSER.
7. Connect from your application -- Use the official client library for your language: ioredis or redis for Node.js, redis-py for Python, Jedis or Lettuce for Java. All follow the same command pattern you learned in the CLI.

Common Use Cases

Caching

The most common use case. Cache database query results, API responses, or rendered HTML fragments. Set a TTL (time-to-live) and let Redis expire stale entries automatically. A single Redis instance can handle 100,000+ GET/SET operations per second, which means one server can absorb the caching needs of most applications.

# Cache a database query result for 5 minutes
SET cache:product:42 '{"name":"Widget","price":29.99}' EX 300

Session Storage

Store user sessions in Redis instead of your application server's memory. This lets you scale horizontally -- any server can read any session. Express.js uses connect-redis, Django uses django-redis, and Rails has built-in Redis session support. Sessions typically expire in 24 hours to 30 days, and Redis handles TTL-based expiration natively.

Rate Limiting

Redis's atomic INCR and EXPIRE commands make it ideal for rate limiting. The sliding window pattern using sorted sets is more accurate than fixed windows.

# Fixed window rate limiter (100 requests per minute)
INCR rate:api:192.168.1.1
EXPIRE rate:api:192.168.1.1 60
# Check: if value > 100, reject the request

Task Queues

Use Redis lists as lightweight job queues with LPUSH and BRPOP. Libraries like BullMQ (Node.js), Celery (Python), and Sidekiq (Ruby) use Redis as their backing store. For most applications, a Redis-backed queue is simpler and faster than deploying RabbitMQ or Kafka.

Real-Time Analytics

Use HyperLogLog for cardinality estimation (unique visitor counts) with only 12 KB of memory per counter, regardless of the number of unique elements. Use bitmaps for daily active user tracking. Use sorted sets for time-windowed aggregations.

Managed Redis Pricing Comparison (2026)

Running Redis yourself is straightforward but adds operational overhead -- patching, monitoring, failover, and backups. Managed services handle all of that. Here's what they cost for a typical production setup (2 GB RAM, high availability with a replica).

Provider	Plan	Monthly Cost	HA/Replica	Free Tier
AWS ElastiCache	cache.t4g.small (2 GB)	~$50	Multi-AZ: +$50	750 hrs/mo t3.micro (12 mo)
Redis Cloud	Essentials 2 GB	$44	Included	30 MB forever
Upstash	Pay-as-you-go	~$10-40	Included (multi-zone)	10K cmds/day forever
Google Memorystore	Basic 2 GB	~$55	Standard: +$55	None
Azure Cache for Redis	C1 Standard (2.5 GB)	~$80	Included	C0 Basic for testing
Aiven for Redis	Startup-4	~$49	Included	None

Pro tip: Upstash is the most cost-effective option for low-to-medium traffic workloads. Their serverless model charges per command ($0.2 per 100K commands), so you pay nothing when traffic is zero. For a typical web app making 5-10 million Redis commands per month, you'll spend $10-20. Compare that to $100+ for ElastiCache with HA. The trade-off is slightly higher latency (1-2ms vs. sub-millisecond) since Upstash uses a proxy layer.

For high-throughput production workloads (50K+ ops/sec), self-managed Redis on dedicated hardware still offers the best price-to-performance ratio. A $40/month VPS with 8 GB RAM handles most Redis workloads comfortably. But you're responsible for failover, patching, and backups.

When Not to Use Redis

Redis isn't a general-purpose database. Don't use it as your primary data store unless your entire dataset fits in RAM and you're comfortable with the persistence trade-offs. Specific anti-patterns:

• Datasets larger than available RAM -- Redis stores everything in memory. If your data exceeds your server's RAM, Redis starts swapping to disk, and performance collapses. Use PostgreSQL or MongoDB for large datasets.
• Complex queries -- Redis has no query language. No JOINs, no aggregations (outside of Redis modules), no ad-hoc queries. If you need SQL-like flexibility, Redis is the wrong tool.
• Strong transactional guarantees -- Redis transactions (MULTI/EXEC) provide isolation but not rollback. For ACID compliance, use a relational database.
• Long-term storage on a budget -- RAM is roughly 30x more expensive per GB than SSD. Storing terabytes in Redis is financially impractical.

Frequently Asked Questions

Is Redis free to use?

Redis versions up to 7.2 are open source under the BSD 3-clause license -- completely free for any use. Starting with Redis 7.4 (March 2024), Redis Ltd. switched to a dual RSALv2/SSPL license, which restricts offering Redis as a managed service without a commercial agreement. For self-hosted use, it's still free. Alternatives like Valkey (a Linux Foundation fork of Redis 7.2) and KeyDB remain fully open source if licensing matters to you.

How much data can Redis store?

As much as your server's RAM allows. A single Redis instance can theoretically address up to 2^32 keys (about 4 billion), and each key can hold up to 512 MB. In practice, a server with 64 GB of RAM can store roughly 40-50 GB of effective data (Redis overhead varies by data structure). For larger datasets, use Redis Cluster to shard across multiple nodes -- it scales linearly up to 1,000 nodes.

Is Redis faster than Memcached?

For simple GET/SET operations, they're comparable -- both deliver sub-millisecond latency. Redis benchmarks at roughly 100,000-200,000 ops/sec on a single core. Memcached can be marginally faster for pure caching because it's multithreaded by default, while Redis was single-threaded until version 6.0 (which added I/O threading). But Redis's data structures, persistence, and Lua scripting make it far more versatile. Most teams choose Redis because they inevitably need more than just caching.

Does Redis support clustering?

Yes. Redis Cluster (built-in since Redis 3.0) provides automatic sharding across multiple nodes with hash slots. Each key maps to one of 16,384 hash slots, distributed across master nodes. Each master can have one or more replicas for failover. Redis Cluster supports up to 1,000 nodes and handles node failures by promoting replicas automatically. The main limitation is that multi-key operations must target keys in the same hash slot (use hash tags like {user:1001} to colocate related keys).

How do I monitor Redis performance?

Start with the built-in INFO command -- it reports memory usage, connected clients, ops/sec, hit rates, and replication status. Use SLOWLOG GET to find slow commands. The LATENCY DOCTOR command (Redis 7+) provides actionable diagnostics. For production monitoring, feed Redis metrics into Prometheus with the redis_exporter and visualize in Grafana. Key metrics to watch: used_memory, instantaneous_ops_per_sec, keyspace_hits/misses (your cache hit rate), and connected_clients.

Can Redis replace my message queue?

For moderate throughput (under 50,000 messages/sec), Redis Streams or Redis-backed libraries like BullMQ are excellent message queue replacements. They're simpler to operate than Kafka or RabbitMQ and offer consumer groups, acknowledgments, and dead-letter handling. For high-throughput event streaming (millions of messages/sec) or when you need long-term message retention and replay, Kafka is still the better choice. Redis Streams aren't designed for multi-terabyte message logs.

What happened with the Redis license change?

In March 2024, Redis Ltd. changed the license from BSD to RSALv2/SSPL starting with version 7.4. This means cloud providers can't offer Redis as a managed service without a commercial license. In response, the Linux Foundation forked Redis 7.2 as Valkey, backed by AWS, Google, Oracle, and others. Valkey 8.0 was released in September 2024 with io-threading improvements. If you're self-hosting, the license change doesn't affect you. If you're choosing a managed service, check whether they run Redis or Valkey -- both are functionally equivalent for now.

Redis Is Infrastructure You'll Keep for Years

I've seen Redis outlast the applications it was originally deployed for. It's one of those foundational infrastructure pieces that, once running, just works. Start with caching -- it's the lowest-risk, highest-impact use case. As you get comfortable, layer in session storage, rate limiting, and job queues. Keep your dataset size within RAM bounds, enable AOF persistence for anything you can't afford to lose, and monitor your hit rates. Redis won't replace your primary database, but it'll make everything in front of it dramatically faster.