DBOS vs Temporal: Quando o Postgres É Suficiente para Execução Durável de Workflows

Execução durável deixou de ser um nicho em 2025. Pipelines de IA agêntica que encadeiam dez chamadas de LLM, sagas de longa duração que atravessam pagamentos e inventário, e jobs orientados a eventos que precisam sobreviver a um restart de pod convergiram todos na mesma primitiva: uma função que retoma exatamente de onde parou após um crash. Temporal definiu a categoria. Restate, Inngest, Hatchet e DBOS lotaram nela. Em abril de 2026, com o DBOS lançando seu SDK em Go e anunciando a parceria com a Databricks, o argumento "o Postgres basta" ficou mais difícil de ignorar.

A pergunta que está na minha mesa, e provavelmente na sua, não é qual sistema é teoricamente melhor. É qual vale o custo operacional dado o time e o workload que você tem à frente. Essa resposta muda mais vezes do que o marketing sugere.

Como os dois sistemas de fato armazenam estado

DBOS é uma biblioteca. Você a importa no seu serviço, dá a ela uma connection string do Postgres e decora funções como workflows ou steps. O resultado de cada step é comitado em uma tabela do Postgres na mesma transação de qualquer escrita de banco que o step tenha feito. Ao restart, a biblioteca faz replay do workflow a partir do último step comitado. Não há processo separado para fazer deploy, não há cluster de history, não há daemon de task queue. A durabilidade do seu workflow é a durabilidade do seu banco de dados.

Temporal roda como um cluster. O serviço Frontend aceita RPCs, o serviço History persiste histórias de eventos e dispara timers, e o serviço Matching despacha tarefas para workers com long-polling. Seu código de aplicação se torna um worker que puxa tarefas, executa-as e reporta de volta. A história do workflow — cada input, decisão e resultado — é armazenada em Cassandra, MySQL ou Postgres por trás dos serviços Temporal, não no banco de dados da sua aplicação. Essa separação é a fonte da maioria dos benefícios do Temporal e da maior parte de sua dor.

Falando claramente: DBOS empurra o estado do workflow para dentro da mesma fronteira transacional dos seus dados de negócio. Temporal o mantém à distância atrás de uma fronteira de serviço.

Onde cada um quebra primeiro

DBOS quebra primeiro em contenção no Postgres. Cada step faz pelo menos uma escrita, e um workflow quente que se ramifica em milhares de filhos vai martelar um único cluster. Você vai ver isso como contenção de locks na tabela de status de workflows, como pressão no WAL se os steps fazem muitas escritas, e como o autovacuum lutando para acompanhar na tabela de history. A história de recuperação exige conhecer seu Postgres — dimensionamento do pool de conexões, particionamento das tabelas de workflow, e manter transações longas fora dos steps. Times que já rodam Postgres bem têm boa parte desse músculo. Times que não rodam vão aprender do jeito difícil.

Temporal quebra primeiro em superfície operacional. Um deployment Temporal em produção é três serviços, uma store de persistência, um pipeline de métricas e uma frota de workers que precisa ter deploy separado da sua aplicação. Compatibilidade de versão entre servidor e SDK, tuning de retenção de history, particionamento de task queue e rebalanceamento de shards são todos knobs que você eventualmente gira. Temporal Cloud remove a maior parte disso — por um preço por ação que fica real acima de algumas centenas de milhões de transições de estado por mês. Temporal self-hosted em Kubernetes é perfeitamente tratável, mas não é projeto de fim de semana para um time de três pessoas.

Uma forma útil de colocar o trade-off é: com DBOS, seu teto de throughput é seu Postgres. Com Temporal, seu teto de throughput é o tamanho do cluster que você está disposto a rodar. Ambos escalam bem além do que a maioria dos produtos precisa, mas a curva de esforço operacional fica muito diferente.

O que exactly-once realmente significa em cada modelo

Ambos os sistemas te dão execução exactly-once de steps no mesmo sentido: os efeitos colaterais de um step sobre um recurso registrado rodam uma vez, mesmo através de crashes. Nenhum te dá exactly-once contra APIs externas arbitrárias — isso ainda exige chaves de idempotência do seu lado. A diferença é onde mora a fronteira de deduplicação.

DBOS te dá exactly-once transacional quando seu step escreve no mesmo Postgres que armazena o estado do workflow. As escritas do step no banco e o registro de durabilidade do step comitam juntos ou nada comita. Essa é a semântica mais limpa da categoria. No momento em que seu step chama um serviço externo, você volta para at-least-once mais idempotência.

Temporal te dá exactly-once de replay nas decisões do workflow, mas activities (as unidades que fazem o trabalho real) são at-least-once por default. Activities que mutam estado externo precisam de chaves de idempotência. Isso tudo bem — é o modelo em que a maioria dos engenheiros de sistemas distribuídos já é fluente — mas não é tão apertado quanto o que DBOS oferece dentro de um único banco.

Se a maioria dos efeitos colaterais do seu workflow pousa no seu próprio Postgres, DBOS te dá uma garantia estritamente mais forte com menos código. Se seu workflow se ramifica para Stripe, SendGrid, S3 e um banco de vetores, a lacuna de garantia se fecha rápido.

Multi-tenant, multi-região, e outros lugares onde Temporal sai na frente

As primitivas multi-tenant do Temporal — namespaces, search attributes, rate limiting por namespace, replicação cross-region — são forjadas em batalha. Se você está construindo uma plataforma que roda workflows de outras pessoas, ou um único produto que precisa de isolamento estrito por tenant em armazenamento de history e throughput, Temporal está simplesmente mais adiante. Só a Web UI, com visibilidade por namespace em cada história de eventos de workflow, vale o custo operacional para times de suporte e on-call.

A história de tenancy do DBOS hoje é "use schemas de Postgres ou clusters separados". Isso funciona para muitos formatos de SaaS, mas se seu modelo de tenancy exige políticas independentes de throughput e retenção por tenant, você vai acabar construindo boa parte do que Temporal te dá de graça. Multi-região para DBOS significa Postgres multi-região, que é sua própria disciplina; a replicação cross-cluster do Temporal, embora não trivial, é um caminho bem batido.

O mesmo vale para signals, timers em escala, child workflows com padrões de fan-out nas centenas de milhares, e workflows de longa duração medidos em meses. Temporal tem referências de produção para todos esses. DBOS está chegando lá, mas a lacuna de maturidade é real e relevante se seu workload vive nesse território.

Observabilidade, debug e o imposto de on-call

Debugar DBOS significa escrever SQL. A história do workflow é uma tabela. Você pode consultá-la, fazer join com seus dados de negócio e ver tudo em um único contexto transacional. Para times pequenos que já vivem no psql, isso é uma feature, não um bug. Para times maiores, a falta de uma UI de event-history de primeira classe vai doer durante incidentes. Você vai acabar construindo uma.

Debugar Temporal significa abrir a Web UI. Todo workflow tem uma view de timeline com inputs, outputs, retries, heartbeats e stack traces de crashes do lado do worker. Replay a partir de uma history que falhou é um workflow suportado. O custo é que essa visibilidade é uma superfície separada dos logs e métricas da sua aplicação, e correlacionar as duas exige trabalho.

O imposto de on-call é o melhor resumo. DBOS quase não adiciona nada à sua rotação de on-call pelo qual você já não fosse responsável — se o Postgres está saudável, os workflows estão saudáveis. Temporal adiciona um cluster que você precisa monitorar e, ocasionalmente, operar. Temporal Cloud remove o cluster a um custo; self-hosted, não.

Um critério de decisão que sobrevive ao contato com a realidade

Escolha DBOS quando a maioria destes for verdade:

• Seu time tem cinco engenheiros ou menos, ou seu time de plataforma já tem forte especialidade em Postgres.
• Os efeitos colaterais do seu workflow pousam predominantemente no seu próprio Postgres.
• Você está rodando no máximo alguns milhares de transições de estado de workflow por segundo.
• Você não precisa de isolamento duro por tenant na camada de armazenamento.
• Você prefere escalar um único banco a operar um segundo sistema distribuído.

Escolha Temporal quando a maioria destes for verdade:

• Você está rodando mais de um serviço workflow-heavy, ou espera rodar.
• Seus workflows se ramificam para muitas APIs externas e você precisa de ferramentas maduras de retry, timeout e visibilidade.
• Você tem requisitos duros de isolamento multi-tenant ou multi-região.
• Você já passou de algumas dezenas de milhares de transições de estado por segundo, ou espera passar.
• Você pode bancar ou a conta por ação do Temporal Cloud ou um time de plataforma que seja dono do cluster.

Tudo no meio é situacional. A resposta honesta é que a maioria dos serviços de backend em 2026 pode entregar execução durável com DBOS e voltar ao Temporal se e quando de fato baterem no muro. A migração reversa — Temporal para DBOS — é rara o suficiente para que eu não planejaria por ela.

Quando eu começaria com DBOS

Se eu estivesse construindo um novo serviço Spring Boot ou Ktor hoje com workflows duráveis, e os efeitos colaterais do workflow fossem majoritariamente escritas no Postgres do próprio serviço, eu começaria com DBOS. A economia por unidade é imbatível: um banco, um deploy, um conjunto de métricas. Eu fatoraria o código de workflow atrás de uma interface para que, se eu precisar migrar depois — provavelmente quando tenancy ou orquestração cross-service me empurrar para fora — o raio de impacto seja um módulo, não o serviço inteiro.

Se eu estivesse construindo uma plataforma de workflows, ou um produto onde workflows coordenam entre três ou mais serviços com fan-out significativo, eu pularia o DBOS e começaria com Temporal mesmo que o time seja pequeno. O custo do dia um é maior; o custo do dia trezentos é menor.

O movimento errado, em qualquer dos lados, é escolher a ferramenta porque uma palestra de conferência disse para escolher. Olhe para onde o estado do seu workflow de fato vive, como é seu on-call, e quanto do seu headcount do próximo ano você quer amarrado operando infraestrutura.

Conclusões

• Execução durável agora é um bloco de construção default, não um padrão exótico.
• DBOS colapsa o estado de workflow no seu Postgres; Temporal o mantém atrás de um cluster dedicado.
• Exactly-once é mais apertado no DBOS quando os efeitos colaterais ficam dentro do mesmo banco.
• Temporal vence em multi-tenant, multi-região e fan-out muito alto. Custa mais para operar.
• Para um time pequeno com um único serviço centrado em Postgres, DBOS é o ponto de partida de menor fricção.
• Para uma plataforma ou um produto workflow-heavy com fan-out externo, Temporal paga seu custo.

Use DBOS quando seu workflow cabe dentro da fronteira do seu banco e seu time é pequeno. Recorra ao Temporal quando o workflow escapa dessa fronteira, quando tenants precisam de isolamento, ou quando o cluster se paga em visibilidade e maturidade.