Kafka é rápido — eu vou usar Postgres

• Fez benchmark do desempenho de publish/subscribe (pub-sub) e fila (queue) do Postgres, sugerindo que um único banco de dados pode substituir um sistema de mensageria
• Em um único nó com 4 vCPU, obteve 5.036 gravações/s e 25.183 leituras/s; mesmo em um ambiente replicado com 3 nós, manteve throughput semelhante, com latência ponta a ponta de 186 ms (p99)
• Em um nó grande de 96 vCPU, alcançou 238 MiB/s de gravação e 1,16 GiB/s de leitura, confirmando folga de processamento com uso de CPU abaixo de 10%
• Nos testes de fila, também foi possível processar 2.885 operações/s em nó único e 2.397 operações/s em ambiente replicado, desempenho suficiente para a maioria das empresas
• Em vez de um sistema distribuído complexo, demonstrou que uma infraestrutura única com Postgres pode lidar com workloads de alguns MB/s, reforçando a abordagem prática de “usar tecnologia simples até que seja necessário algo mais”

---

Dois campos na escolha de tecnologia

• O setor de tecnologia se divide entre o campo guiado por buzzwords e o campo guiado pelo bom senso
  • O primeiro é atraído por termos de marketing como “tempo real”, “escala infinita” e “baseado em IA”
  • O segundo prioriza simplicidade e pragmatismo, evitando complexidade desnecessária
• Recentemente, duas correntes fortaleceram esse segundo grupo: Small Data e o renascimento do Postgres
  • Os dados estão menores e o hardware está mais poderoso
  • O Postgres pode substituir várias soluções especializadas com um único sistema (jsonb, pgvector, tsvector etc.)

Visão geral do benchmark

• Objetivo: medir até que ponto o Postgres consegue escalar em mensageria pub/sub e processamento de filas
• Ambiente de teste: AWS EC2 c7i.xlarge (4 vCPU) e c7i.24xlarge (96 vCPU)
• Comparação entre três configurações
  • nó único
  • cluster replicado de 3 nós
  • nó único de grande porte

Resultados do benchmark de Pub/Sub

• Nó único de 4 vCPU
  • gravação de 4,8 MiB/s (5.036 msg/s), leitura de 24,6 MiB/s (25.183 msg/s), latência de 60 ms (p99)
  • 60% de uso de CPU, disco escrevendo a 46 MiB/s
• Replicação em 3 nós com 4 vCPU
  • gravação de 4,9 MiB/s, leitura de 24,5 MiB/s, latência de 186 ms (p99)
  • throughput mantido, custo anual de cerca de US$ 11.514
• Nó único de 96 vCPU
  • gravação de 238 MiB/s (243k msg/s), leitura de 1,16 GiB/s (1,2M msg/s), latência de 853 ms (p99)
  • CPU abaixo de 10%, com o gargalo na velocidade de gravação por partição
• Conclusão: nível competitivo com Kafka em workloads pequenas e médias, com capacidade de processar dezenas de MB/s mesmo com uma arquitetura simples

Resultados do benchmark de fila

• Implementação de fila simples baseada em SELECT FOR UPDATE SKIP LOCKED
• Nó único de 4 vCPU
  • 2,81 MiB/s (2.885 msg/s), latência de 17,7 ms (p99), CPU em 60%
• Replicação em 3 nós com 4 vCPU
  • 2,34 MiB/s (2.397 msg/s), latência de 920 ms (p99), CPU em 60%
• Nó único de 96 vCPU
  • 19,7 MiB/s (20.144 msg/s), latência de 930 ms (p99), CPU entre 40% e 60%
• Mesmo um nó único pode atender à maioria das necessidades de throughput de filas nas empresas

Quando escolher Postgres

• Na maioria dos casos, escolher Postgres por padrão é uma decisão racional
  • É possível depurar, corrigir e fazer joins nas mensagens com SQL
  • Em comparação com Kafka, a operação é mais simples e a manutenção mais fácil
• Kafka é otimizado para alto desempenho, mas é uma escolha excessiva para workloads pequenas
• É citada a advertência de Donald Knuth de que “otimização prematura é a raiz de todo mal”
  • Até alguns MB/s, o Postgres já é suficiente

Abordagem de infraestrutura mínima viável (MVI)

• Minimum Viable Infrastructure: construir o sistema mínimo com tecnologias que a organização já conhece
  • O Postgres é amplamente adotado e facilita a contratação de profissionais
  • Quanto menos componentes, menor a carga operacional e a chance de falhas
• A adoção de tecnologias desnecessárias gera sobrecarga organizacional
  • aumento de custos com aprendizado, monitoramento, deploy e operação

Discussão sobre escalabilidade

• Postgres realmente pode escalar
  • A OpenAI ainda usa Postgres baseado em instância única de escrita
  • Operação estável mesmo em escala de centenas de milhões de usuários
• A maioria das empresas cresce em ritmo moderado, então há anos de margem antes de precisar trocar de tecnologia
• Projetar “para o caso de viralizar” é um overdesign exagerado
  • O texto compara isso a “comprar um amplificador Marshall para abrir um show do Coldplay”

Conclusão

• “Use Postgres até ele quebrar”
  • Mesmo tecnologias simples podem entregar desempenho suficientemente alto
  • Introduzir sistemas distribuídos complexos além do necessário é ineficiente
  • Com o hardware moderno, o Postgres é uma opção prática capaz de suportar a maioria dos workloads

[GN⁺]

Comentário do Hacker News

• Aplicar o princípio de Pareto a toda situação é uma interpretação equivocada
  Dizer que o Postgres cobre 80% dos casos de uso do Kafka com 20% do esforço é uma afirmação sem fundamento
  O princípio de Pareto só faz sentido em situações em que aparece uma distribuição de lei de potência
  Basta dizer que o Postgres cobre casos de uso suficientes, é estável e é uma ferramenta comprovada

  • Mas também há a opinião de que o próprio mapeamento entre casos de uso e funcionalidades pode seguir uma distribuição de lei de potência

• Pela experiência de lidar desde pequena escala (centenas de eventos por hora) até grande escala (trilhões de eventos por hora), primeiro é preciso avaliar se uma fila é realmente necessária

  1. Talvez apenas fazer polling no banco já seja suficiente
  2. Se um único nó der conta, dá para processar com serverless ou um processo único
  3. Se não for realmente um caso que exija fila distribuída, balanceamento de carga + API REST + retentativas assíncronas também podem ser suficientes
  4. Se uma fila distribuída for realmente necessária, acho melhor usar uma solução dedicada como o Kafka
  • É preciso deixar claro que o Kafka na verdade não é uma fila, e sim um sistema de log distribuído. Muita gente o confunde como substituto de MQ
  • Em startups, com frequência engenheiros tendem a escolher tecnologias complexas pensando mais na próxima etapa da carreira do que no projeto atual
  • Se a estrutura do código for projetada para suportar tanto fila baseada em PostgreSQL quanto fila baseada em Kafka, depois fica fácil migrar
  • O PostgreSQL tende a virar gargalo quando a carga de escrita aumenta. Fluxos de UPDATE são especialmente dolorosos
  • Como desenvolvedor Java, eu sempre precisei de fila. Polling em banco era uma dor de cabeça em ambientes com vários consumidores/produtores. Os consumer groups e partitions do Kafka ajudavam muito no gerenciamento de estado

• A abordagem de usar Postgres para tudo é arriscada
  Locks e níveis de serialização não são intuitivos e podem gerar gargalos de desempenho
  Uso Postgres há décadas, mas não se deve projetar sistemas com fé cega

  • Quando o tráfego dispara, o problema é o limite do escalonamento vertical. O Kafka absorve picos de tráfego, mas o Postgres sobrecarrega facilmente
  • Seria bom se o Postgres tivesse uma estrutura de fila sustentável adicionada, mas é difícil escalar além do nível do Redis, e o LISTEN/NOTIFY não escala (link relacionado)
  • Na verdade, todo armazenamento de dados exige entender seu modelo de concorrência. Há grandes diferenças até entre bancos relacionais
  • O Postgres tem dificuldade para escalar indefinidamente, mas consegue processar bastante dado com processamento em lote e operações por linha única
  • Pessoalmente, eu começo com Postgres e, se surgir gargalo, aí migro para outro sistema

• Acho eficaz a abordagem de uma tabela de log de eventos baseada em SQL
  Mas a desvantagem é a falta de ferramentas no lado do cliente. Nesse ponto, o Kafka tem a vantagem de um ecossistema rico de bibliotecas
  Nossa empresa padronizou o envio de eventos entre serviços com base em SQL (feedapi-spec)
  Ainda não é tão maduro quanto o Kafka, mas pode evoluir para uma stack comum de bibliotecas com suporte a vários motores de storage

  • Com o avanço das ferramentas de geração de código baseadas em LLM, ficou mais fácil preencher esse gap de clientes
  • Como alguém que não gosta de Kafka, essa abordagem parece muito mais atraente

• Hoje em dia as pessoas tendem a se deixar atrair demais por tecnologias novas
  O Postgres é excelente, mas é preciso usar a ferramenta certa para o problema
  O Postgres não foi projetado para pub-sub, o Kafka foi feito para isso
  É melhor evitar a tendência de todo produto querer “fazer tudo”. Acho melhor ferramentas em que cada uma faz bem uma coisa

• Implementar números de offset monotonicamente crescentes é um problema complicado
  Uma sequência simples causa problemas porque a ordem da transação e o momento do commit podem se desencontrar

  • Um método é ter uma tabela dedicada de contador e garantir a ordem com locks dentro da mesma transação (link de referência)
  • Também é possível garantir a ordem em ambiente distribuído usando Lamport Clock ou Vector Clock (Lamport timestamp, Vector clock)
  • Em vez de forçar uma ordem absoluta, é mais realista atribuir números por lote ou deixar um processo separado ordenar após o commit
  • Também há a forma de evitar processamento duplicado usando SELECT FOR UPDATE SKIP LOCKED

• Fico em dúvida se realmente fizeram benchmark de Kafka
  O resultado obtido em um ambiente com 96 vCPU também é possível com a configuração de 4 vCPU do Kafka
  O desempenho do Postgres está anormalmente lento
  Se não precisa de Kafka, não use, mas se gabar de 5k msg/s com Postgres não significa muita coisa

  • O Redpanda (implementação compatível com Kafka) processa 250 mil mensagens por segundo até em um notebook (link do vídeo)
  • Em um ambiente com 288 vCPU, desempenho inferior a isso é desperdício
  • Se o motivo para usar Postgres é apenas “porque já existe”, dá para entender, mas ainda assim é preciso validar antes de adicionar nova infraestrutura
  • O Kafka atinge o limite de largura de banda da rede mesmo com pouco hardware
  • Operar na AWS com uma única instância 24xlarge é ineficiente, e com esse custo daria para operar um grande cluster Kafka

• Existem dois extremos: “pessoas obcecadas por tecnologia nova” e “pessoas que só insistem no que aprenderam”
  O engenheiro realista faz uma escolha prática em algum ponto entre esses extremos

  • Eu sou do terceiro grupo: o tipo que pensa “o que existe agora é ruim, e o novo no fim também vai ser ruim”
  • No fim, o importante é olhar o problema de forma racional e buscar a melhor solução
  • Por exemplo, tentar substituir o Elasticsearch por Postgres é possível, mas a qualidade dos recursos de busca do ES é muito superior

• A principal funcionalidade do Kafka é o controle de offset por consumidor
  Em ambientes em que várias equipes leem o mesmo tópico, isso é indispensável
  A possibilidade de avançar e retroceder offsets já foi uma verdadeira salvação várias vezes
  Fico curioso se filas em Postgres oferecem esse recurso

  • Também há quem diga que cada consumidor poderia gerenciar seu próprio offset
  • Mas, na maioria dos casos, se não for necessário alto throughput, não é preciso toda a gestão complexa de offsets do Kafka
  • No fim, é uma questão de equilíbrio entre a velocidade exigida pelo negócio e a complexidade operacional

• A própria divisão entre “o lado que corre atrás de buzzwords” e “o lado do bom senso” está errada
  Reimplementar o Kafka em Postgres não é bom senso
  Se você realmente precisa de funcionalidades no nível do Kafka, então basta usar Kafka

  • Na prática, não foi uma implementação completa do Kafka, e sim apenas um caso de duas queries pub-sub simples