# RabbitMQ vs SQS: broker self-run ou fila gerenciada?

> RabbitMQ vs Amazon SQS: um broker AMQP autogerenciado vs uma fila totalmente gerenciada. Recursos, roteamento, ops e adequação ao CI comparados com honestidade.

Source: https://latchkey.dev/pt/learn/tool-comparisons/rabbitmq-vs-sqs  
Updated: 2026-06-26

RabbitMQ é um broker rico em recursos que você mesmo opera; Amazon SQS é uma fila totalmente gerenciada com recursos mínimos mas operação quase zero.

RabbitMQ oferece exchanges, roteamento flexível, prioridades e suporte a protocolos (AMQP, MQTT, STOMP), mas você o roda e escala. SQS é uma fila simples, durável e totalmente gerenciada (standard ou FIFO) que escala automaticamente e integra fortemente com a AWS, trocando roteamento avançado por simplicidade operacional. RabbitMQ favorece recursos e controle; SQS favorece zero-ops dentro da AWS.

## Comparison

|  | RabbitMQ | SQS |
| --- | --- | --- |
| Ops | Autogerenciado | Totalmente gerenciado (AWS) |
| Roteamento | Rico (exchanges) | Básico (queue/FIFO) |
| Protocolos | AMQP, MQTT, STOMP | AWS API |
| Escala | Manual / cluster | Automática |
| Melhor para | Roteamento complexo, controle | AWS-native, baixa ops |

## Caso de uso e ops

RabbitMQ se adequa a times que precisam de roteamento rico, prioridades ou portabilidade fora da AWS e dispostos a rodar um broker. SQS se adequa a sistemas AWS-native que querem uma fila durável sem manutenção e semântica simples de producer/consumer, aceitando roteamento limitado e lock-in da AWS.

## Em CI

RabbitMQ roda como service container para testes de integração. SQS pode ser emulado com LocalStack ou ElasticMQ para que os testes rodem offline. Ambos se adequam a runners gerenciados, onde runners mais rápidos encurtam a inicialização do emulador/broker e a execução dos testes.

## Decide with your own numbers, not a feature table

Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.

```Terminal
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
  "<tool-a> install" "<tool-b> install"

# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"
```

> Measure the cold path. Warm local benchmarks favour whichever tool you already have cached, which is exactly the condition a CI runner never has.

## What actually changes when you switch

- Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
- Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
- CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
- Everyone on the team and every runner must move together. Pin the version so they cannot drift.

## O veredito

Roteamento complexo, prioridades ou mensageria portável entre nuvens: RabbitMQ, aceitando o ônus operacional. Enfileiramento durável AWS-native com zero manutenção: SQS. O fator decisivo costuma ser quanta flexibilidade de roteamento você precisa versus quanto você valoriza zero-ops dentro da AWS.

## FAQ

### RabbitMQ vs SQS: Self-Run Broker or Managed Queue?

RabbitMQ offers exchanges, flexible routing, priorities, and protocol support (AMQP, MQTT, STOMP), but you run and scale it. SQS is a simple, durable, fully managed queue (standard or FIFO) that scales automatically and integrates tightly with AWS, trading advanced routing for operational simplicity.

### Use case and ops?

RabbitMQ suits teams needing rich routing, priorities, or non-AWS portability and willing to run a broker. SQS suits AWS-native systems that want a durable queue with no maintenance and simple producer/consumer semantics, accepting limited routing and AWS lock-in.

### In CI?

RabbitMQ runs as a service container for integration tests. SQS can be emulated with LocalStack or ElasticMQ so tests run offline. Both fit managed runners, where faster runners shorten emulator/broker startup and test execution.

### Which should I choose?

Complex routing, priorities, or cloud-portable messaging: RabbitMQ, accepting the operational burden. AWS-native, durable queuing with zero maintenance: SQS. The deciding factor is usually how much routing flexibility you need versus how much you value zero-ops within AWS.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt