RabbitMQ vs Kafka: Which One Do You Actually Need? (2026)

The DM That Made Me Write This

It was late 2024. A founder friend — smart guy, building a B2B scheduling tool, maybe forty users — dropped a message in our group chat at 11 PM: “bro should I use RabbitMQ or Kafka for my background jobs?” Attached was an architecture diagram with more boxes than his product had customers.

I stared at it for a while. Not because the question was hard, but because it was the exact wrong question — the same one I’d asked myself at 1 AM building Clickly, my little URL shortener, the night I almost put Apache Kafka in front of a redirect service that had zero users. He wanted to send welcome emails and generate PDFs in the background. He needed neither tool. He needed a database table.

But “which one” is the internet’s favorite argument, so let me actually answer it — what RabbitMQ is, what Kafka is, when each genuinely earns its place — and then, like the broken engineer I am, talk you out of both.

---

RabbitMQ: The Smart Post Office

RabbitMQ is a message broker. The mental model that finally stuck for me: it’s a post office with an unusually clever sorting room.

A producer drops a message in. RabbitMQ looks at it, decides which queue (or queues) it belongs in based on rules you set up — this is called an exchange doing routing — and pushes it to whichever worker is free to handle it. The worker does the job, sends back an acknowledgment, and RabbitMQ crosses the message off its list. One task, done once, gone. That’s the whole loop.

Two things define its personality:

• The broker is smart, the consumer is dumb. RabbitMQ tracks who got what, retries on failure, handles priorities, and routes messages down whatever topology you configure — fan-out, topic matching, dead-letter queues for the jobs that keep failing. Your worker code stays simple; the broker carries the brains. It speaks a protocol called AMQP and it’s written in Erlang, a language literally built for reliable telecom switches, which is why it’s so unbothered by thousands of concurrent connections.
• It’s push-based. RabbitMQ shoves work at your workers the moment it arrives. Great for “do this thing right now, in the background.”

One bit of 2026 housekeeping: RabbitMQ’s commercial home is now Broadcom, which swallowed VMware (and its Pivotal-era RabbitMQ team) at the end of 2023. The open-source project is alive and well — version 4.x is current, and they’ve even bolted on a Streams feature that apes some of Kafka’s log behavior — but it’s worth knowing the corporate parent if you’re betting a business on it.

Where it shines: a task queue with real routing needs. Many workers, complex delivery rules, “this job goes to the priority lane, that one retries three times then lands in the dead-letter pile.” That’s RabbitMQ’s home turf, and it’s genuinely excellent at it.

---

Kafka: The Log That Never Forgets

Kafka is a different animal, and I wrote a whole plain-English breakdown of it in what a Kafka topic actually is, so I’ll keep this tight.

Kafka is not a queue. It’s a distributed, append-only log. Producers write events to the bottom of a named log (a topic); consumers read from wherever they left off. The crucial difference from RabbitMQ: reading a message doesn’t delete it. The event just sits there for days or weeks, and any number of independent services can read the same log at their own pace, each keeping its own bookmark.

Its personality is the mirror image of RabbitMQ:

• The broker is dumb, the consumer is smart. Kafka barely does anything except store the log fast and hand out chunks of it. No per-message routing, no tracking who processed what. Each consumer decides what it’s read and where to resume. All the intelligence lives in your code.
• It’s pull-based. Consumers ask “give me everything from offset 4,102 onward.” Which means they can rewind — reprocess yesterday, replay the last month into a brand-new service you just wrote. That replay ability is Kafka’s superpower and the reason it exists. It was built at LinkedIn to move firehoses of activity data across a whole company before Confluent spun out to sell it.

Kafka’s other trick is raw throughput. It splits each topic into partitions across many machines, so it can push toward a million messages a second when it’s tuned — a different order of magnitude from a traditional broker sitting in the thousands-to-tens-of-thousands range. In 2026 it also finally dropped its old ZooKeeper dependency (version 4.0, released March 2025, runs on its own KRaft metadata system), and it’s even experimenting with queue-like “share groups” — Kafka slowly wandering onto RabbitMQ’s lawn. The convergence is real, but the core identities still hold.

---

The Head-to-Head

Here’s the whole argument in one table, minus the vibes:

	RabbitMQ	Kafka
What it is	Message broker	Distributed event log
Model	Smart broker, dumb consumer	Dumb broker, smart consumer
Delivery	Push (broker sends to workers)	Pull (consumers fetch)
After reading	Message is gone	Message stays; replay anytime
Best at	Task queues, complex routing	High-throughput streams, replay
Throughput	Thousands–tens of thousands/sec	Up to ~1 million/sec, tuned
The gut feel	”Run this job in the background"	"Broadcast what happened, forever”

The one-sentence version I give people now: RabbitMQ moves tasks, Kafka records events. If you’re describing work that needs to happen (“send the email”), that’s a broker. If you’re describing facts that need to be remembered and re-read (“a user clicked, and three services care”), that’s a log.

Most founders reaching for either one actually want the first thing. They’ve just heard “Kafka” more often because it shows up in every FAANG engineering blog. Picking Kafka for a job-queue problem is like renting a freight train to deliver a pizza.

---

When RabbitMQ Actually Wins

Reach for RabbitMQ when all of these are true and a database table has genuinely stopped coping:

• You have a fleet of workers — not two, a fleet — chewing through jobs, and you need the broker to distribute work fairly and push it instantly.
• Your routing is genuinely complex: priorities, topic-based fan-out, dead-letter handling, retry policies you don’t want to hand-roll.
• You want work consumed once and forgotten — no replay, no history, just “do it and move on.”

Think order processing in an e-commerce backend, or a video pipeline where each upload triggers transcode, thumbnail, and notify jobs across dozens of workers. That’s a real RabbitMQ shape. It’s the boring, correct, grown-up choice — and still an order of magnitude simpler to reason about than Kafka.

When Kafka Actually Wins

Reach for Kafka when you can honestly say:

• Multiple independent services need to react to the same stream of events, each at its own pace — analytics, fraud detection, notifications, a data warehouse, all reading one orders firehose.
• You genuinely need to replay history — rebuild a service’s entire state by re-reading the last month of events.
• You’re moving real volume, the continuous hundreds-of-thousands-to-millions-of-events kind where “just use a table” starts groaning.

That’s a company with traffic and revenue, not a founder chasing their first ten users. And if you get there and want Kafka’s model without babysitting a JVM cluster, look at Redpanda — it speaks the Kafka protocol but ships as a single binary. That’s the version of “adding Kafka” I’d actually respect from a small team.

---

What This Actually Costs You

Here’s the part the architecture-diagram crowd skips. Both of these are systems with a personality, and they want attention (and money).

Kafka is not a $5 box you forget about. A self-hosted production cluster on cloud VMs runs somewhere around $850–$1,500 a month just for infrastructure, before the human hours to keep it alive. Managed softens the ops pain, not the concept: Confluent Cloud’s serverless tier bills roughly $0.11 per GB in, $0.11 per GB out, and about $0.10 per GB-month stored, and a moderate workload lands near $200/month. Amazon MSK is in the same neighborhood.

RabbitMQ is cheaper but not free once it’s real. You can self-host it on a small box, but the moment you want it managed so you’re not the one paged at 3 AM, CloudAMQP (the go-to managed host) starts its free “Little Lemur” shared tier, then jumps to about $50/month for the first genuinely dedicated instance.

Now remember who you are. You’re the person from the survival guide who felt physically ill paying $90/month with $0 MRR. Neither of these numbers belongs on your bill yet.

---

The Broken Engineer Verdict: You Need Neither

I know, I know — you came for a winner and I’m telling you not to play. But this is the same hard truth from the Kafka post and the database rabbit hole: the tool is real and powerful, and almost never what a bootstrapper needs on day one.

You don’t have a message-broker problem. You have a “nobody uses my product yet” problem. Neither Rabbit nor Kafka fixes that.

Almost every “I need a queue” instinct maps onto something you’re already running:

Just use Postgres. If you’re running PostgreSQL — and you should be — you have a queue hiding in it. A plain table plus SELECT ... FOR UPDATE SKIP LOCKED gives you an atomic, race-free job queue where every worker grabs a different row, in the same transaction as your data. Libraries like pg-boss (Node) or Celery (Python, backed by your DB or Redis) wrap it up so you don’t hand-roll it. Real teams have ripped out RabbitMQ and replaced it with exactly this, and their stack got simpler.

Reach for Redis when Postgres feels heavy. Redis with a library like BullMQ is the classic dedicated-queue move — a couple of dollars a month, or serverless via Upstash so you pay for what you touch. “Send the welcome email,” “resize the image,” “generate the PDF” — the actual jobs you have — all live here comfortably.

Nine times out of ten you stop at the first rung. My friend from the group chat? He’s on a Postgres table to this day. His scheduling tool works fine. The Kafka cluster he sketched never wrote a single message.

---

The Bottom Line

RabbitMQ and Kafka are not rivals so much as different machines for different jobs. RabbitMQ is a smart broker that hands tasks to workers and forgets them — brilliant when you have a fleet of workers and gnarly routing. Kafka is a durable log many services replay at will — brilliant when you’re drowning in a firehose of events that several systems all need. Knowing the difference is genuinely worth it, because understanding what a tool is means you can decide, deliberately, not to use it.

And right now you almost certainly shouldn’t use either. Not because they’re bad — because they’re heavy machinery for a battle you haven’t reached. Your Postgres table is enough. Your $5 Redis is enough. The energy you’d pour into brokers, exchanges, partitions, and consumer groups is energy stolen from the only thing that decides whether you make it: getting someone to actually use the thing you built.

So learn the difference. Win the argument at the next meetup if you want. Then close the tabs and ship with the boring stack that costs you a dollar.

This is the Broken Engineer Guide. I over-engineer everything, fail at business, and share the scars so you don’t have to earn them at 1 AM. Go build something — with a Postgres table.