RabbitMQ vs Redis Compared

RabbitMQ's guarantee comes from two acknowledgements. A publisher confirm for a persistent message routed to a durable queue is sent only after the message is on disk, and for a quorum queue only after a majority of replicas accept it. Manual consumer acknowledgements keep a message queued until the consumer is done, and unacknowledged messages are requeued if the channel closes. RabbitMQ's documentation calls that combination at-least-once and describes automatic acknowledgement as fire-and-forget.

Redis has three mechanisms with three answers. Pub/Sub is at most once: a subscriber that is disconnected or fails mid-message never sees it again. Lists with BRPOP lose a job if the consumer crashes after popping it; the documented fix is BLMOVE into a processing list, cleared with LREM when the work is done. Streams with consumer groups track delivered entries in a Pending Entries List until XACK, and XAUTOCLAIM hands a dead consumer's entries to a live one. That is at-least-once, and Redis 8.6 added idempotent production so producer retries do not write duplicates.

Redis keeps the dataset in memory. RDB snapshots are point-in-time, and the Redis persistence guide says to expect to lose the latest minutes of data after an unclean stop; the append-only file with the default appendfsync everysec cuts that to about one second. Replication is asynchronous, and Redis's documentation says WAIT does not make it strongly consistent and that Redis Cluster can lose writes it acknowledged during a failover.

RabbitMQ quorum queues use Raft, so losing one node of three loses nothing that was confirmed. They never keep message bodies in memory, so a backlog is bounded by disk rather than RAM. Classic mirrored queues were removed in RabbitMQ 4.0.

In RabbitMQ a producer publishes to an exchange, and bindings decide which queues get a copy: by exact key, topic pattern, header match or to all. A new consumer that needs a subset of traffic is a new binding, not a producer change. Failure handling is configuration too: dead-letter exchanges, message and queue TTL, a delivery limit that dead-letters poison messages after 20 attempts by default on quorum queues, consumer timeouts and, as of RabbitMQ 4.3, strict priorities on quorum queues. Redis has no routing layer. Fan-out means several consumer groups on one stream, and retry limits and a dead-letter destination are code you maintain, usually driven by the delivery count XPENDING reports.

Both are append-only logs that consumers read by position and can replay. A RabbitMQ stream is always persistent and replicated, stored on disk and retained by size or age, with non-destructive reads and super streams for partitioning. A Redis Stream is a key in memory, trimmed by length or minimum ID, and its consumer groups add per-entry acknowledgement, so one stream works as both a short log and a work queue. Redis Streams suit a bounded window of recent events that fits in RAM; RabbitMQ streams suit long retention and wide fan-out. For long-lived event logs, see RabbitMQ Streams vs Apache Kafka.

Most published benchmarks compare an unacknowledged in-memory push with a durable, replicated, acknowledged delivery. To compare like for like, test Redis with the persistence and WAIT settings your loss tolerance needs against RabbitMQ quorum queues with confirms, on your own message sizes. Include two effects: an RDB fork can pause Redis for milliseconds, or up to a second on a very large dataset, and RabbitMQ blocks publishers when it crosses a memory or disk watermark.

Operationally, RabbitMQ runs as a three or five node cluster with a management UI and per-queue metrics. Redis is quicker to stand up, but as a queue it needs RAM for the peak backlog plus fork headroom, the noeviction policy so queued work is never evicted, and Sentinel or Redis Cluster for failover. Redis 8 added AGPLv3 as a license option and Valkey is the BSD-licensed fork; Valkey vs Redis covers that choice.

1. Would a lost message end up in an incident report or a contract dispute? RabbitMQ with quorum queues and confirms.
2. Do consumers need different subsets of the same traffic? RabbitMQ exchanges.
3. Could a consumer outage build a backlog bigger than the RAM you will buy? RabbitMQ.
4. Is Redis already in production, with short-lived jobs that can be re-run? Redis Streams with consumer groups, never Pub/Sub.
5. Is the job a cache, session store or real-time counter? Redis, which is what it was built for.

Many architectures run both; Redis and RabbitMQ together covers that split, and Redis as a message queue goes deeper into Lists, Pub/Sub and Streams.