RabbitMQ vs Redis: Queues, Delivery Guarantees, Celery and When to Use Each

The short answer

RabbitMQ is a message broker. Redis is an in-memory data store that can carry messages. In RabbitMQ, the queue is the product: publishers send to exchanges, quorum queues replicate each message through Raft, consumers acknowledge what they finish, and anything rejected or expired can be dead-lettered automatically. Redis gives you building blocks instead. A list can be a queue, Pub/Sub can broadcast, and streams add consumer groups with acknowledgements, but durability depends on how you configure persistence and replication, and the retry logic sits in your client code. Choose RabbitMQ when losing or silently dropping a message is a business problem. Choose Redis, or Valkey, when you already run it, the messages are small and short-lived, and an occasional replay of work after a failure is acceptable.

RabbitMQ vs Redis at a glance

How Redis handles queues

Redis offers three ways to move messages, and they behave very differently.

• Lists. A producer pushes with LPUSH and a worker takes items with RPOP or the blocking BRPOP. It is simple and fast. Redis's own documentation for LMOVE says plainly that this queue "is not reliable as messages can be lost", for example when a worker crashes after taking an item and before finishing it. The documented fix is the reliable-queue pattern: LMOVE or BLMOVE moves each item into a processing list in one atomic step, and the worker removes it only when the job is done. Something still has to scan that processing list and requeue stale items, and that something is your code.
• Pub/Sub. Redis describes its Pub/Sub as at-most-once. If a subscriber is disconnected or fails while handling a message, the message is gone. That suits cache invalidation and live notifications, not work that must happen.
• Streams. A stream is an append-only log with consumer groups. Each entry delivered to a consumer sits in a pending entries list until the consumer acknowledges it with XACK. XAUTOCLAIM, added in Redis 6.2, lets another consumer take over entries that have been pending too long. Streams are the closest Redis comes to a broker, and Redis notes they support both at-most-once and at-least-once delivery.

Durability is a configuration choice in Redis rather than a property of the queue. By default Redis saves RDB snapshots to disk. The append-only file is more durable, and its default policy fsyncs once a second, which Redis says means you may lose one second of data in a disaster. Replication to replicas is asynchronous by default. Memory is the other limit: when maxmemory is reached, the eviction policy decides whether Redis refuses writes or starts removing keys, and a queue that gets evicted loses its messages.

How RabbitMQ handles queues

RabbitMQ routes first and stores second. A publisher sends to an exchange, and bindings decide which queues get a copy, so one message can fan out to several services or be routed by pattern or header without any client logic. Quorum queues are a durable, replicated queue type built on Raft, and RabbitMQ recommends them as the default when a queue has to survive the loss of a node. Publisher confirms tell the producer the broker has taken responsibility for a message, and consumer acknowledgements tell the broker when it can forget it.

The failure handling is what Redis users usually end up rebuilding. A message is dead-lettered to another exchange when a consumer rejects it without requeueing, when its TTL expires, when the queue exceeds its length limit, or when it has been returned to a quorum queue more times than the delivery limit. From RabbitMQ 4.0 that limit defaults to 20, so a poison message no longer loops forever. Queues and messages can carry TTLs, classic and quorum queues support priorities (quorum queues gained strict priority in 4.3), and streams add a replayable log when several readers need the same history.

RabbitMQ vs Redis for Celery

Celery is where most people meet this choice, so it is worth reading what Celery's own documentation says. In the broker table for Celery 5.6, RabbitMQ and Redis are both marked stable, and both support monitoring and remote control of workers. RabbitMQ is the default broker. Celery's summary says Redis "works well for rapid transport of small messages" but that large messages can congest it, and that RabbitMQ handles larger messages better. It also notes that RabbitMQ as the broker with Redis as the result backend is a very common pairing.

The Redis transport has two caveats in Celery's docs. First, the visibility timeout: a task that is not acknowledged within it, one hour by default, is redelivered to another worker. ETA and countdown tasks scheduled further out than the timeout can therefore run more than once. Second, key eviction: if Redis evicts Celery's internal keys, the worker fails, so Celery tells you to set maxmemory-policy to noeviction or allkeys-lru. On RabbitMQ, Celery supports quorum queues, with the caveat that they require global QoS to be disabled and some Celery features behave differently; native delayed delivery switches on automatically when quorum queues are detected.

Which should you choose, RabbitMQ or Redis?

• Choose RabbitMQ when each message represents work that must happen once it is accepted: orders, payments, provisioning, notifications a customer is waiting for. Also when several services need different copies of the same message, when you need dead-lettering and retries without writing them, or when clients speak AMQP, MQTT or STOMP.
• Choose Redis or Valkey when you already run it, the messages are small, losing or repeating one now and then is tolerable, and you do not want another system to operate. Background jobs that can be rerun, cache invalidation and live UI updates are typical. Use streams rather than lists or Pub/Sub if you need acknowledgements.
• Use both in the common Celery layout: RabbitMQ carries the tasks and Redis stores the results.
• Consider Kafka instead when the point is event history that many systems read and replay, rather than work distribution. Our Kafka vs RabbitMQ comparison covers that line.

Licensing

RabbitMQ's server is MPL 2.0 and Broadcom holds the copyright. Redis changed licence twice: 7.2 and earlier are BSD-3-Clause, 7.4 moved to RSALv2 or SSPLv1, and Redis 8 added AGPLv3 as a third option. Valkey, the Linux Foundation fork of Redis 7.2, stays BSD and keeps the same list, Pub/Sub and stream commands, so everything above about Redis queues applies to Valkey too. See the Redis licence change explained and Valkey vs Redis.

Where OSSeva fits

OSSeva supports both, so the choice can follow the workload. OSSeva for RabbitMQ patches community RabbitMQ from 3.8 through 4.3, including 3.13 and 4.0 to 4.2 after community end of life, together with the Erlang/OTP runtime underneath. OSSeva for Redis ships CVE-patched Redis 6.2 and 7.0 under their original BSD licence, supports 7.2, and supports Valkey 7.2 and 8.x; see Redis extended support. You keep the binaries you run today and change who supports them. RabbitMQ and Redis sit under one contract with your databases and Kafka, priced per cluster. Book a discovery call for a quote. OSSeva does not support Celery itself. For other options, see our lists of RabbitMQ support providers and Redis and Valkey support providers.

Frequently asked questions

RabbitMQ vs Redis queue: which is more reliable?

RabbitMQ. Quorum queues are replicated through Raft and written to disk before the broker confirms a publish, and acknowledgements, redelivery and dead-lettering are built in. A Redis list used as a queue can lose messages if a worker crashes, unless you use the LMOVE reliable-queue pattern, and Redis persistence and replication are asynchronous by default. Redis streams close much of the gap on acknowledgement, but not on replication.

RabbitMQ vs Redis for Celery: which broker should I use?

Celery marks both as stable. RabbitMQ is Celery's default broker and handles larger messages better; Redis suits fast transport of small messages and is often already present as the result backend. If you use Redis, set the visibility timeout longer than your longest ETA or countdown and set maxmemory-policy to noeviction or allkeys-lru, as Celery's docs advise.

RabbitMQ vs Redis Streams: what is the difference?

Redis streams are an append-only log with consumer groups, acknowledgements and a pending entries list, so they cover at-least-once delivery inside one Redis deployment. RabbitMQ also has streams, which are replicated and replayable, and it adds routing through exchanges, dead-lettering and standard protocols. If your application already runs Redis and the traffic is modest, Redis streams are reasonable. For messaging between many services, RabbitMQ is the stronger fit.

RabbitMQ vs Redis vs Kafka: how do the three compare?

Redis is a data store that can queue. RabbitMQ is a broker that routes and queues work. Kafka is a distributed log that keeps events for a retention period so many consumers can read and replay them. Pick Redis for light, in-application messaging, RabbitMQ for work distribution with retries, and Kafka for shared event history and stream processing.

Is Redis a message broker?

Not primarily. Redis can act as one through lists, Pub/Sub and streams, and many job libraries use it that way. It does not route between queues, dead-letter failed messages or speak messaging protocols such as AMQP.

Can Valkey replace Redis as a Celery broker?

Valkey keeps the Redis 7.2 command set and protocol, including lists, Pub/Sub and streams, so clients that speak to Redis generally work against it. Test your Celery version against Valkey before switching production workers.