Choose Amazon SQS if you want a fully managed queue that passes work between parts of your app, with nothing to run and a message that's gone once a consumer deletes it. Choose Apache Kafka if you need an event streaming platform that stores events for as long as you set and lets many consumers read and replay them. The deciding question is whether you're handing off tasks or keeping a stream of events.
I read the Amazon SQS product page and FAQs, then Apache Kafka's home, introduction and uses pages. They're often compared because both move messages, but they're built on different ideas about what happens to a message after it's read.
SQS and Kafka compared
| Amazon SQS | Apache Kafka | |
|---|---|---|
| Type | Fully managed message queue on AWS | Open source distributed event streaming platform |
| How consumers read | Polling; a message stays until a consumer processes and deletes it | Subscribe to topics; events stay after they're read |
| Keeping data | Messages leave the queue once processed | Per-topic retention, for as long as you want |
| Ordering | Standard queues best effort; FIFO queues keep exact order | Guaranteed ordering, on Kafka's home page |
| Delivery | Standard at-least-once; FIFO exactly-once processing | Exactly-once processing |
| Running it | No software or servers to manage | You run brokers, or use a managed service |
| Free option (as of October 2026) | Free Tier of 1 million requests a month | Yes, open source |
What SQS does well
AWS describes SQS as message queuing for microservices, distributed systems and serverless apps. You send, store and receive messages between components at any volume without losing them, and without needing the other services to be up. Its example is a banking app where the customer gets an instant response while bill payments are processed in the background.
It comes in two shapes. Standard queues are built to scale massively, so they give at-least-once delivery and only loose ordering. FIFO queues keep the exact order and give exactly-once processing, where a message stays available until a consumer processes it and deletes it. SQS also gives you dead-letter queues for messages that keep failing, and AWS says key business processes at Amazon.com and AWS run on it.
Where Kafka is the stronger fit
Kafka's own introduction lists three jobs: publish and subscribe to streams of events, store them durably for as long as you want, and process them as they happen or later. The detail that changes everything is that events aren't deleted after they're read. You set retention per topic, and any number of consumers can read the same events as often as they need.
That's why Kafka shows up in payments, fleet tracking, sensor data and data platforms. The project says clusters scale to a thousand brokers and trillions of messages a day, with latencies as low as 2ms, and Kafka Connect plugs into hundreds of sources and sinks such as Postgres, Elasticsearch and AWS S3. It also ships Kafka Streams, a library for joins, aggregations and filters on live data.
Other brokers are listed in our message queue roundup.
The difference people miss
A queue and a log solve different problems. With SQS, once a worker finishes a task and deletes the message, it's done, which is exactly what you want for jobs like sending an email or resizing an image. With Kafka, the history stays, so a new service can start reading from the beginning, or you can replay a day of events after fixing a bug. If you'd ever want to read the same message twice, that's a strong sign you're looking at Kafka.
AWS's pub/sub service is compared with SQS in our SQS vs SNS comparison.
How to decide
- Are you spreading background jobs across workers? SQS was built for that.
- Do several systems need the same events, now and later? Kafka's retention and replay cover it.
- Do you want zero servers to run? SQS is fully managed on AWS.
- Do you need strict order? Use SQS FIFO queues, or design Kafka topics and partitions for it.
- Are you building a data platform or real-time analytics? Kafka, with Kafka Streams or Connect, is the natural base.
If you're weighing the wider toolset your developers use, see these developer productivity tools and some ChatGPT prompts that speed up coding.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
My advice on SQS or Kafka
If you're on AWS and you need to hand tasks from one part of your app to another, SQS is the simpler choice, and you won't have anything to run. If your business wants a record of events that several teams can read, replay and analyse, Kafka is the platform for it, even though it asks more of your team. You can use both, a queue for jobs and a stream for events, so don't force one to do the other's work.
Do you make messaging or streaming tools? Tool makers can ask to be considered for a featured place in comparisons like this one.
Frequently asked questions
Is SQS the same as Kafka?
No. AWS describes SQS as a managed message queue where a message stays until a consumer processes and deletes it. Kafka is an event streaming platform that keeps events after they're read, for as long as you set.
Does SQS keep message order?
FIFO queues keep the exact order and give exactly-once processing. Standard queues only attempt to keep order, because they're built to scale massively.
Can Kafka replay old messages?
Yes. Kafka's introduction says events can be read as often as needed and aren't deleted after consumption; you set how long each topic keeps them.
Is there a free tier for SQS?
Yes. AWS says the SQS Free Tier gives you 1 million requests a month.
Is Kafka free?
Apache Kafka is open source. You'll still need servers to run it, or a managed service.
