Redis Stream vs Pub/Sub: Key Differences and Usage Guide

In Redis, Pub/Sub is a simple messaging system for real-time message delivery without persistence, while Streams provide durable, ordered, and replayable message storage with consumer groups for advanced processing. Use Pub/Sub for transient, low-latency messaging and Streams when you need message history and reliable consumption.

Quick Comparison

Here is a quick side-by-side comparison of Redis Streams and Pub/Sub features.

Feature	Redis Pub/Sub	Redis Streams
Message Persistence	No, messages are not stored	Yes, messages are stored in a log
Message Delivery	Real-time only, no replay	Supports replay and history
Consumer Management	No built-in consumer groups	Supports consumer groups with tracking
Message Ordering	No guaranteed order	Ordered by insertion time
Use Case	Live notifications, chat	Event sourcing, reliable queues
Acknowledgment	No ack, fire-and-forget	Supports message acknowledgment

Key Differences

Pub/Sub in Redis is a fire-and-forget messaging system where publishers send messages to channels and subscribers receive them instantly if connected. There is no message storage, so if a subscriber is offline, it misses messages. This makes Pub/Sub ideal for real-time notifications where message loss is acceptable.

In contrast, Streams store messages in an append-only log, allowing consumers to read messages at their own pace. Streams support consumer groups, enabling multiple consumers to share the workload and track which messages have been processed. This makes Streams suitable for reliable message processing and event sourcing.

Additionally, Streams guarantee message ordering and allow replaying past messages, while Pub/Sub does not. Streams also support message acknowledgment, so consumers can confirm processing, which is not possible with Pub/Sub.

Code Comparison

Here is how you publish and consume a message using Redis Pub/Sub.

redis

127.0.0.1:6379> PUBLISH news "Hello subscribers!"
(integer) 1

# Subscriber terminal:
127.0.0.1:6379> SUBSCRIBE news
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "news"
3) (integer) 1

1) "message"
2) "news"
3) "Hello subscribers!"

Output

Message "Hello subscribers!" received instantly by subscribers connected to channel 'news'.

Streams Equivalent

Here is how you add and read messages using Redis Streams with a consumer group.

redis

127.0.0.1:6379> XGROUP CREATE mystream mygroup $ MKSTREAM
OK

127.0.0.1:6379> XADD mystream * message "Hello stream consumers!"
"1609459200000-0"

# Consumer reads messages:
127.0.0.1:6379> XREADGROUP GROUP mygroup consumer1 COUNT 1 STREAMS mystream >
1) 1) "mystream"
   2) 1) 1) "1609459200000-0"
         2) 1) "message"
            2) "Hello stream consumers!"

Output

Consumer receives stored message "Hello stream consumers!" with message ID.

When to Use Which

Choose Pub/Sub when you need simple, low-latency, real-time messaging without the need to store or replay messages, such as live chat or notifications where missing messages is acceptable.

Choose Streams when you require reliable message delivery, message persistence, ordering, and the ability to replay or track message processing, such as in event sourcing, task queues, or complex consumer workflows.

Key Takeaways

Use Redis Pub/Sub for simple, real-time messaging without persistence or replay.

Use Redis Streams for durable, ordered message storage with consumer groups and acknowledgments.

Streams support message replay and tracking, unlike Pub/Sub.

Pub/Sub is best for transient notifications; Streams fit reliable processing needs.

Choosing depends on whether you need message durability and consumer management.