O que é o DBOS

O DBOS é uma biblioteca open source de durable execution: ela torna funções do seu código capazes de sobreviver a crashes, reinícios e falhas de rede, retomando exatamente do ponto onde pararam. A mágica está em onde o estado é guardado: em um banco Postgres comum, sem nenhum servidor de orquestração extra.

O projeto nasceu de pesquisa académica no MIT e em Stanford e virou empresa em 2023. Os nomes por trás impressionam: Mike Stonebraker, criador do próprio Postgres, e Matei Zaharia, criador do Apache Spark, estão entre os fundadores. O nome vem de Database-Oriented Operating System, a tese de que o banco de dados pode assumir responsabilidades que hoje espalhamos em dezenas de serviços.

Em julho de 2026 o blog da equipe voltou ao topo do Hacker News com um artigo defendendo que transações do Postgres são um superpoder para sistemas distribuídos: se o estado do workflow mora no mesmo banco que os seus dados, uma única transação resolve problemas que normalmente exigem filas, retries e muita oração.

O problema que o DBOS ataca é o mais chato do backend moderno: o processo morre no meio de uma operação de vários passos, tipo cobrar o cartão e depois liberar o pedido, e você nunca sabe em que estado o mundo ficou.

Como funciona

O conceito central é o checkpointing automático. Você marca uma função como workflow e cada passo dela como step. A cada step concluído, o DBOS grava o resultado no Postgres. Se o processo cair no meio, ao reiniciar a biblioteca encontra os workflows incompletos e os retoma do último step gravado, pulando os que já terminaram.

Na prática, isso vira decorators no seu código. Em Python, uma função recebe o decorator de workflow e as operações internas recebem o decorator de step. Nada de reescrever a aplicação em uma DSL de orquestração: é o seu código Python ou TypeScript normal, rodando no seu processo normal.

Uma analogia ajuda: é como um jogo com save automático a cada fase. Se o console desliga no meio da fase 7, você não volta para a fase 1, volta para o início da fase 7. Ferramentas tradicionais de fila, sozinhas, são como um jogo sem save: a mensagem volta para a fila e o processamento inteiro recomeça, com risco de repetir efeitos colaterais.

💡
Dica

Como o estado fica no Postgres, você ganha de brinde as garantias transacionais do banco: steps que escrevem dados podem rodar na mesma transação que o checkpoint, dando semântica de "exatamente uma vez" para operações no banco.

Principais recursos

O DBOS entrega um conjunto de primitivas que normalmente exigiriam três ou quatro serviços separados:

  • Workflows duráveis: funções de múltiplos passos que retomam de onde pararam após qualquer falha.
  • Filas e concorrência: enfileiramento de tarefas com controle de paralelismo e rate limiting, sem Redis nem broker dedicado.
  • Agendamento estilo cron: workflows agendados com sintaxe de crontab, direto no código.
  • Idempotência: cada workflow tem um ID; disparar duas vezes com o mesmo ID executa uma vez só.
  • Observabilidade: como tudo está em tabelas Postgres, dá para inspecionar o estado de qualquer workflow com SQL ou pelo console visual da ferramenta.
  • Notificações e eventos: workflows podem esperar sinais externos, útil para pagamentos e aprovações humanas.

O diferencial em relação ao mercado é a arquitetura: é uma biblioteca, não um servidor. Não existe cluster de orquestração para operar, atualizar e pagar. Se você já tem Postgres, já tem toda a infraestrutura necessária.

As bibliotecas principais são para Python e TypeScript, open source sob licença MIT, com o código no GitHub da DBOS Inc.

Como começar: instalação passo a passo

Começar com o DBOS em Python leva poucos minutos:

Passo 1: tenha um Postgres acessível. Pode ser local via Docker, um Postgres gerenciado na nuvem ou o que seu projeto já usa.

Passo 2: instale a biblioteca com pip:

pip install dbos
# TypeScript: npm install @dbos-inc/dbos-sdk

Passo 3: configure a URL de conexão do Postgres na variável de ambiente:

export DATABASE_URL="postgresql://usuario:senha@localhost:5432/meu_banco"

Passo 4: marque sua função com @DBOS.workflow() e os passos internos com @DBOS.step(), inicialize a biblioteca no boot da aplicação e rode normalmente.

💡
Dica

Não há plano pago obrigatório: a biblioteca é gratuita e roda em qualquer lugar que rode seu código, de um VPS barato a Kubernetes. A empresa vende o DBOS Cloud como opção, mas é completamente opcional.

Exemplo prático

Cenário real: um endpoint de checkout que cobra o cartão, registra o pedido e envia email de confirmação. Sem durable execution, um deploy no momento errado pode cobrar o cliente sem registrar o pedido.

Com o DBOS, o checkout vira um workflow com três steps. O código continua sendo uma função Python simples:

from dbos import DBOS

dbos = DBOS(database_url=os.getenv("DATABASE_URL"))

@dbos.workflow()
def checkout(order_id: str, card_token: str):
    charge_result = cobrar_cartao(card_token, order_id)
    registrar_pedido(order_id, charge_result)
    enviar_email_confirmacao(order_id)

@dbos.step()
def cobrar_cartao(card_token: str, order_id: str):
    # chama gateway de pagamento
    return payment_gateway.charge(card_token, idempotency_key=order_id)

@dbos.step()
def registrar_pedido(order_id: str, charge: dict):
    db.orders.insert({"id": order_id, "charge_id": charge["id"]})

@dbos.step()
def enviar_email_confirmacao(order_id: str):
    email_service.send(order_id)

Suponha que o processo morra logo depois do step de cobrança. Ao reiniciar, o DBOS consulta o Postgres, vê que o workflow parou entre o step 1 e o step 2, e retoma dali: registra o pedido e envia o email. O cliente não é cobrado de novo, porque o resultado do step de cobrança já estava gravado.

Para testar isso em desenvolvimento, o exercício clássico é matar o processo no meio do workflow com kill e subir de novo. Ver a execução continuar do ponto exato onde parou é o momento em que a ideia clica.

Comparação com alternativas

As alternativas principais são o Temporal, o AWS Step Functions e soluções artesanais com filas tipo Celery ou BullMQ.

O Temporal é a referência da categoria: extremamente poderoso, usado em escala gigante, mas exige operar ou pagar um cluster de orquestração separado, e o modelo de programação tem curva de aprendizado real. O Step Functions resolve bem dentro da AWS, mas te prende ao ecossistema e define workflows em JSON, longe do seu código. Filas artesanais dão retry, mas não dão retomada de múltiplos passos nem exatamente uma vez sem muito código manual.

Quando usar cada um: Temporal para organizações grandes com times de plataforma e workflows em escala massiva. Step Functions para quem é all-in AWS e quer integração nativa com Lambda. DBOS para quem quer durabilidade com o mínimo de infraestrutura nova, aproveitando o Postgres que já existe no stack.

O ponto forte único do DBOS é esse: durable execution como biblioteca leve, com estado no seu próprio banco, sem nenhum componente novo para operar.

Pontos positivos e limitações

Do lado positivo: simplicidade operacional imbatível, código que continua sendo código normal, garantias transacionais reais por morar dentro do Postgres, licença MIT e um pedigree técnico raro, com o criador do Postgres envolvido no design.

⚠️
Atenção

O projeto é jovem comparado ao Temporal, e o ecossistema de exemplos, integrações e respostas no Stack Overflow ainda é menor. A escala tem teto prático: tudo passa pelo seu Postgres, então workflows de altíssimo volume vão exigir tuning de banco que o Temporal resolve com arquitetura dedicada.

Outra limitação é de linguagem: o suporte de primeira classe é para Python e TypeScript. Times de Java, Go ou .NET vão encontrar opções mais maduras em outras ferramentas. E steps precisam ser determinísticos ou idempotentes na retomada, uma disciplina que o time precisa aprender.

Casos de uso reais

O DBOS serve de verdade para perfis bem definidos:

  • Backend de startup com Postgres no stack: ganha pipelines de pagamento e onboarding confiáveis sem adicionar nenhuma peça de infraestrutura.
  • Quem constrói agentes de IA: agentes executam sequências longas de chamadas caras a LLMs; perder tudo por um crash no passo 8 de 10 custa dinheiro. Durable execution retoma do passo 8.
  • Integrações com APIs instáveis: sincronizações com ERPs e gateways que falham com frequência viram workflows com retry e retomada automática.
  • Jobs agendados críticos: rotinas de faturamento e fechamento que não podem rodar duas vezes nem deixar de rodar.

O padrão comum entre esses perfis: operações de múltiplos passos com efeitos colaterais reais, onde repetir ou perder um passo custa caro.

Para scripts simples, CRUDs e tarefas sem estado, o DBOS é canhão para matar mosca: uma fila simples ou um cron comum resolvem.

Dicas e boas práticas

Quem já roda durable execution em produção segue alguns padrões:

🚀
Pro tip

Steps pequenos e focados: cada chamada externa vira um step separado. Steps gigantes reduzem o benefício da retomada — se o step 1 demora 10 minutos e falha no minuto 9, você refaz tudo.

💡
Dica

Idempotência nas bordas: ao chamar APIs externas de pagamento, envie chaves de idempotência. O DBOS garante o seu lado; a chave garante o lado deles.

💡
Dica

Use o ID do workflow: derive o ID de algo do domínio, como o ID do pedido. Isso previne execuções duplicadas vindas de cliques repetidos ou retries de webhook.

💡
Dica

Monitore as tabelas do DBOS: workflows presos ou com erro ficam visíveis em SQL. Um alerta simples sobre workflows pendentes há muito tempo pega problemas cedo.

🔴
Cuidado

O erro mais comum de iniciante é colocar lógica não determinística direto no corpo do workflow, como gerar timestamps ou números aleatórios fora de um step. Na retomada, esses valores mudam e o comportamento fica inconsistente. A regra: efeito colateral e aleatoriedade vivem dentro de steps.

Outra dica: comece migrando um único job problemático — aquele que vive falhando de madrugada — antes de adotar a ferramenta no sistema inteiro.

Vale a pena?

Se o seu backend já usa Postgres e você tem operações de múltiplos passos que precisam ser confiáveis, sim, o DBOS vale muito a pena. É a forma mais barata, em infraestrutura e em complexidade, de ter durable execution de verdade hoje.

Para quem precisa de escala extrema de orquestração, suporte a Java e Go, ou já tem Temporal rodando bem, a troca não se justifica. E para aplicações simples sem workflows críticos, é peso desnecessário.

Próximo passo sugerido: pegue o quickstart de Python ou TypeScript na documentação oficial, rode o exemplo localmente e mate o processo no meio de um workflow. Ver a retomada acontecer no seu terminal explica a proposta melhor que qualquer artigo.