Home

MQTT vs Redis: When Your Messages Really Matter

March 5, 2025 • MQTT, Redis, PubSub, Message Queuing, Durability, QoS, Real-Time Messaging, IoT, Broker, Retained Messages, Persistent Sessions • 1322 words • about a 6 minute read

So, you’ve got messages to send around and you’re eyeing Redis Pub/Sub and MQTT. Both can shout messages to multiple listeners, but under the hood they play by different rules. Let’s break down how each handles publish/subscribe (pub/sub) messaging, how they queue (or don’t queue) messages, and what guarantees they give (or don’t give) about delivering your data.

@@@@@@@  @@@  @@@ @@@@@@@   @@@@@@ @@@  @@@ @@@@@@@
 @@!  @@@ @@!  @@@ @@!  @@@ !@@     @@!  @@@ @@!  @@@
 @!@@!@!  @!@  !@! @!@!@!@   !@@!!  @!@  !@! @!@!@!@
 !!:      !!:  !!! !!:  !!!     !:! !!:  !!! !!:  !!!
  :        :.:: :  :: : ::  ::.: :   :.:: :  :: : ::  .... fuk yeah!!

Pub/Sub Mechanism: Direct Push vs Broker Magic

Redis Pub/Sub uses a straightforward “direct push” approach. When a publisher sends a message to a Redis channel, Redis immediately forwards it to all subscribers connected at that moment (Stack Overflow). There’s no intermediary process beyond Redis itself – the message isn’t stored or processed further; it’s just instantly pushed out to listeners. Think of Redis as a radio tower broadcasting live: if your receiver (subscriber) is tuned in right now, you get the signal; if not, the message just flies past and is gone.

MQTT, on the other hand, relies on a broker (like Mosquitto, EMQX, or HiveMQ) to manage message delivery. Publishers send messages to the broker on a named topic, and the broker is responsible for filtering and routing those messages to the right subscribers (EMQX Docs). The broker is like that overly helpful friend who says, “Don’t worry, I got this!” It can even store or queue messages under certain conditions, ensuring subscribers get their due even if they’re a bit late to the party.

In summary, Redis connects publisher and subscriber in real-time (with zero memory), while MQTT adds a middleman who not only passes messages along but may also store them if needed.

Example: Publishing & Subscribing in Redis vs MQTT

Redis Example

A diagram showing basic redis pubsub

# Redis Pub/Sub example (Python with redis-py)
import redis
redis_client = redis.Redis()
pubsub = redis_client.pubsub()
pubsub.subscribe("sensor-data")         # Subscriber listens on "sensor-data"
redis_client.publish("sensor-data", "Hello from Redis")  # Publisher sends a message
# No storage. If no one is tuned in, the message vanishes into thin air!

MQTT Example

A diagram showing basic mqtt pubsub

# MQTT Pub/Sub example (Python with Paho MQTT)
import paho.mqtt.client as mqtt
mqtt_client = mqtt.Client(client_id="device123", clean_session=False)
mqtt_client.will_set("sensor/status", "device123 gone", qos=1, retain=False) 
mqtt_client.connect("mqtt-broker.example.com", 1883)
mqtt_client.subscribe("sensor/data", qos=1)  # Subscriber registers for "sensor/data"
mqtt_client.publish("sensor/data", "Hello from MQTT", qos=1, retain=True)  # Publisher sends message
# The broker will forward the message to any subscribers.
# With retain=True, even new subscribers get the latest message.

Durability and Message Persistence

One of the biggest differences between Redis Pub/Sub and MQTT is what happens to messages after they’re published. Spoiler: Redis doesn’t hold onto your messages, while MQTT might just save them like that sticky note on your monitor.

Redis Pub/Sub is ephemeral. When you publish a message, Redis doesn’t store it; it’s like a Snapchat message – gone once viewed (or missed) (Redis Pub/Sub Docs).

MQTT can persist messages:

  • Persistent Sessions: Clients that connect with persistent sessions can receive messages that were published while they were offline (EMQX Blog).
  • Retained Messages: A publisher can flag a message as retained, so the broker stores the last message on a topic. New subscribers immediately get this “last known state” (EMQX Docs).
  • Disk Persistence: Many brokers can persist messages to disk for extra durability.

If you need to ensure a message reaches its destination no matter what, MQTT’s your pal.

       .-=========-.
       \'-=======-'/  -- sup
       _|   MQTT   |_
      (_|  Broker  |_)
        |_________|

QoS: Guaranteed Delivery vs Fire-and-Forget

Quality of Service (QoS) is MQTT’s secret sauce. It lets you choose the level of delivery assurance:

  • QoS 0: Fire-and-forget. Minimal overhead, but no guarantees (Redis is always here).
  • QoS 1: At least once. Acknowledgment handshakes ensure delivery, though duplicates may occur.
  • QoS 2: Exactly once. A full-on two-phase handshake to guarantee one-and-only-one delivery (HiveMQ Blog).

Redis Pub/Sub has no such bells or whistles – it’s always QoS 0, which is fine for non-critical notifications, but not if every message counts.

Delivery Features: Retain, Last Will, and Sessions

MQTT’s extra features add a layer of reliability that Redis lacks:

  • Retained Messages: Store the last message on a topic so new subscribers know the current state.
  • Last Will and Testament (LWT): Specify a message to be sent if a client disconnects unexpectedly.
  • Persistent Sessions: Keep subscriptions and queue messages for offline clients.

These features mean MQTT can act like a well-organized mailroom. Redis Pub/Sub? It’s more like tossing messages out of a paper airplane and hoping they land in the right hands.

Switching from Redis to MQTT – Trade-offs

Thinking of swapping Redis Pub/Sub for MQTT? Consider these:

  • Delivery vs. Simplicity: MQTT gives you reliability (guaranteed delivery, persistent sessions) at the cost of extra complexity. Redis is simple: publish, then poof.
  • Broker Overhead: Running an MQTT broker adds another component to manage, though lightweight brokers make it less of a headache.
  • Client Libraries: MQTT means learning a new API. Your devs might miss the old redis.publish() simplicity.
  • Performance: Redis is a speed demon in-memory, but MQTT’s extra handshake may slow raw throughput. If reliability is key, MQTT wins.
  • Scaling: MQTT brokers often offer built-in clustering and federation, while Redis Pub/Sub in clusters can be tricky.
  • Use Case Alignment: IoT devices, mobile apps, and flaky networks benefit from MQTT’s reliability. For high-speed, in-data center communications, Redis may still shine.

For more details on these trade-offs, check out MQTT and Redis: Creating a Real-Time Data Statistics Application for IoT and explore other tech deep dives on Hacker News.

Limitations of MQTT (Where Redis Shines)

To be fair:

  • Blazing Speed: Redis is ultra-fast for in-memory operations – think of it as the cheetah of messaging.
  • Unified Data Platform: Redis is more than pub/sub; it’s a full-fledged data store.
  • Simple Implementation: Redis’s API is clean and straightforward.
  • When Loss is Acceptable: In cases where messages lose relevance quickly, losing a few isn’t a problem.

If you’re in a scenario where losing some data is acceptable, Redis keeps it simple and fast.

Both Redis Pub/Sub and MQTT implement the pub/sub pattern, but they cater to different needs. Redis Pub/Sub is like a live wire – fast and ephemeral, great for scenarios where you can live with occasional message loss. MQTT is like a postal service with registered mail, persistent sessions, and a “last will” for emergencies. Choose the one that fits your system’s priorities, or better yet, use them side-by-side for different parts of your architecture.

Happy messaging, and may your data always find its way!

Sources for Further Reading: