Hatchet – Plataforma de orquestração de tarefas baseada em Postgres

• Plataforma open source de processamento de tarefas em background em grande escala baseada em Postgres
• Fila de tarefas distribuída (Distributed Task Queue) e plataforma de orquestração de workflows
• Suporta workflows de tarefas complexos, recuperação de falhas, agendamento, gatilhos baseados em eventos e monitoramento em tempo real
• SDKs para Python, Go e TypeScript
• Licença MIT, com versões self-hosted e em nuvem

Principais recursos em resumo

• Gerenciamento de filas

  • Sistema de filas durável baseado em Postgres
    • Enfileiramento baseado em chave (implementa distribuição justa de tarefas)
    • Limitação de taxa (Rate limiting)
    • Sticky Assignment e Worker Affinity
  • Distribuição de tarefas, tentativas de reexecução e alertas de falha tratados automaticamente
  • Exemplos em Python / TypeScript / Go

• Orquestração de tarefas

  • Composição de workflows baseada em DAG
    • Execução condicional (ex.: sleep, gatilhos baseados em eventos, execução condicional baseada na saída da tarefa pai etc.)
    • Capaz de lidar com lógica de ramificação complexa
  • Definição de dependências entre tarefas e execução paralela de múltiplas tarefas
  • Suporte a armazenamento e recuperação de resultados intermediários com durable tasks
    • Execução de funções durável: em caso de falha, armazena o estado intermediário em cache e restaura na reexecução
    • Suporte também a Durable Sleep e Durable Events

• Controle de fluxo (Flow Control)

  • Limite de concorrência por usuário
  • Limitação de taxa (Rate Limiting) global e dinâmica
  • Garantia de estabilidade do sistema por meio de distribuição estratégica de tarefas

• Agendamento de tarefas

  • Suporte a tarefas Cron, execução agendada e durable sleep
  • Ex.: executar todos os dias à meia-noite, agendar para um horário específico, aguardar até o horário definido etc.

• Roteamento de tarefas

  • Sticky Assignment: fixa a tarefa no mesmo worker
  • Worker Affinity: aplica lógica de seleção do worker ideal

• Gatilhos baseados em eventos

  • Permite executar tarefas após receber eventos externos
  • Possibilidade de combinar condições de evento/sleep

• Web UI em tempo real

  • Dashboard e monitoramento em tempo real
  • Visualização de logs das tarefas e configuração de alertas (Slack/e-mail)

Quando vale a pena usar o Hatchet?

• ✅ Quando você precisa de composição de workflows baseada em DAG
• ✅ Quando reexecução e preservação de estado são importantes em caso de falha das tarefas
• ✅ Processamento distribuído de tarefas em aplicações com muitos usuários
• ❌ Quando você só precisa de uma fila simples e rápida de configurar (recomendados: Celery/BullMQ etc.)
• ❌ Quando a integração com vários conectores de dados é importante (recomendados: Airflow/Prefect etc.)

Comparação: Hatchet vs outras soluções

• Hatchet vs Temporal

  • Hatchet oferece suporte a fila + DAG + Durable Execution
  • Temporal é otimizado para Durable Execution
  • O Hatchet é fácil de self-hostar (só precisa de Postgres)

• Hatchet vs BullMQ / Celery

  • O Hatchet inclui armazenamento do histórico de tarefas + visualização em UI + orquestração embutida
  • BullMQ/Celery são bibliotecas de fila leves, mas têm recursos limitados de monitoramento

• Hatchet vs Airflow / Prefect

  • O Hatchet oferece execução rápida, baixa latência e gerenciamento próprio de workers
  • Airflow/Prefect são mais focados em pipelines de dados e se destacam em conectores de integração

Resumo

• Hatchet é uma plataforma moderna de processamento distribuído de tarefas que funciona apenas com Postgres
• É possível implementar um sistema de tarefas Durable, Observable e Composable com uma única ferramenta
• Suporta tanto nuvem quanto self-hosting e pode ser integrado facilmente com Python/Go/TypeScript

[halfenif]

Testei por 2 horas e escrevi isto.

• Como estou montando um MQ, testei para ver se seria alguma novidade baseada em Postgres, mas fiquei um pouco decepcionado ao ver que precisava de RabbitMQ
• Como não era uma abordagem voltada para k8s, subi o docker-compose.yaml no podman (+Arch)
• Como eu queria usar um Postgres separado, precisei configurar mais algumas coisas, mas acabei parando ao encontrar SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER: Invalid certificate verification context
• Se algo desse errado no meio do processo, eu precisava dar drop no banco de dados do Postgres e começar de novo
• Era preciso criar uma API Key toda vez, mas como a chave completa não aparecia na interface web, tive que extraí-la usando as ferramentas de desenvolvedor.

[GN⁺]

Comentários no Hacker News

• Gostaria de entender no que isso difere de outros executores de tarefas em Python baseados em pg, como Procrastinate ou Chancy

• Muito interessante

  • quando disseram que FOR UPDATE SKIP LOCKED não escalava até 25k consultas/segundo, fiquei curioso sobre em que ponto ele começou a atingir o limite
  • fiquei curioso sobre leituras e gravações com buffering, e sobre converter todas as tabelas grandes para uma coluna de ID
  • fiquei me perguntando se esses pontos fizeram parte da solução para escalar FOR UPDATE SKIP LOCKED de acordo com as necessidades

• Gostaria de saber se as operações da fila (colocar tarefas na fila e marcá-las como concluídas) acontecem na mesma transação da minha lógica de negócio

  • considero isso uma funcionalidade central de filas baseadas em banco de dados
  • simplifica a lógica de retry
  • o mesmo problema também pode acontecer na execução da tarefa
  • nesse ponto, talvez seja melhor usar SQS

• Estou projetando uma aplicação baseada em eventos/workflows, e essa solução parece muito promissora

  • também considerei o Temporal, mas não senti que fosse o encaixe perfeito
  • a licença open source me dá confiança no design da aplicação
  • eu estava procurando condicionais como CEL

• As seis melhorias na arquitetura do Hatchet aumentaram o desempenho em todas as dimensões

  • particionamento por intervalo em tabelas de série temporal
  • particionamento por hash de eventos de tarefas
  • separação entre tabela de monitoramento e fila
  • leituras e gravações com buffering
  • conversão de todas as tabelas grandes para uma coluna de ID
  • uso agressivo de triggers do Postgres
  • dá para fazer coisas incríveis lendo o manual

• O README parece assumir que há mais usuários usando modo escuro

  • o logo é branco, então sem modo escuro ele não aparece
  • seria interessante ver as estatísticas do GitHub

• Ao usar o Postgres como fila de mensagens, enfrentei problemas para lidar com payloads grandes (mais de 50MB)

  • a solução foi usar tabelas sem WAL e VACUUM FULL periódico
  • não sou especialista em Postgres, mas fiquei curioso se eles resolveram isso

• Depois de revisar a documentação por 15 minutos, deixo este feedback

  • modo claro, open source, logging e a interface de DX são bons
  • seria melhor substituir o exemplo de Hello World por um cenário real
  • o código de workflow com tarefas em múltiplas etapas não é intuitivo
  • é preciso se familiarizar com a forma de pensar, os padrões e a terminologia do Hatchet
  • parece faltar esforço para facilitar isso para o cliente
  • os posts de engenharia fazem sentido, mas o cliente não se importa com a infraestrutura em nuvem
  • como há muitas opções no mercado de workflows, a chance de reescrever ou pivotar por último é alta
  • seria preciso focar a jornada de automação e permitir que as pessoas simplesmente peguem e configurem
  • é difícil serializar workflows em JSON
  • seria preciso facilitar a migração de workflows do Hatchet para outra empresa

• Parabéns pelo lançamento da v1

  • uso o Hatchet há quase 1 ano e coloquei em produção há 6 meses
  • o suporte open source e o início rápido são excelentes
  • o trabalho de engenharia investido no sistema é visível

• A primeira impressão é boa, parabéns pelo lançamento

  • tenho algumas perguntas
  • gostaria de saber se ele oferece suporte a tarefas persistentes
  • gostaria de saber onde ficam armazenadas as entradas e saídas das tarefas
  • gostaria de saber se é possível estimar quantas tarefas por segundo o sistema consegue processar com base no tamanho da instância PostgreSQL e nas métricas de I/O
  • estou avaliando várias ferramentas e quero entender qual é a proposta do Hatchet
  • estou procurando uma ferramenta com a qual dê para trabalhar com o mínimo possível de boilerplate