pg_durable: Microsoft lanca execucao duravel dentro do PostgreSQL

O que e o pg_durable

Em junho de 2026, a Microsoft publicou no GitHub o pg_durable, uma extensao open-source para PostgreSQL que traz execucao duravel diretamente para dentro do banco de dados. O conceito de execucao duravel (durable execution) existe ha anos em ferramentas como Temporal e Azure Durable Functions, mas sempre exigiu um servico externo separado do banco. O pg_durable muda isso: o proprio PostgreSQL passa a garantir que seus workflows sobrevivam a falhas, crashs e reinicios sem precisar de infraestrutura adicional.

A ideia central e simples mas poderosa: se voce ja confia no PostgreSQL para guardar os dados do seu sistema, por que nao confiar nele tambem para orquestrar os processos que manipulam esses dados? O pg_durable armazena o estado de cada workflow diretamente nas tabelas do Postgres, usando as mesmas garantias de durabilidade que o banco ja oferece por padrao: WAL (Write-Ahead Log), transacoes ACID e replicacao.

O projeto esta disponivel no perfil oficial da Microsoft no GitHub como software open-source e entrou em destaque no Hacker News no dia do lancamento, com mais de 400 pontos e dezenas de comentarios de desenvolvedores backend animados com a proposta de simplificar stacks que hoje dependem de Temporal, Conductor ou AWS Step Functions.

Como funciona

O pg_durable funciona como uma extensao do PostgreSQL que adiciona um novo tipo de objeto ao banco: o workflow. Voce define um workflow como uma sequencia de etapas (steps) escritas em SQL ou em linguagens suportadas via procedimentos armazenados. Cada etapa e executada dentro de uma transacao propria e o resultado e gravado no banco antes de avancar para a proxima.

O mecanismo chave e o checkpoint automatico. Diferente de um script que roda de ponta a ponta e falha no meio sem registro, o pg_durable grava o estado apos cada etapa concluida. Se o processo morrer no meio do caminho (crash do servidor, deploy, timeout), na proxima reinicializacao o workflow retoma exatamente de onde parou, sem reprocessar o que ja foi concluido e sem perder dados.

Por baixo dos panos, o pg_durable cria tabelas de controle no schema do banco para rastrear o estado de cada execucao: qual workflow esta rodando, em qual step esta, qual foi o resultado de cada step concluido e qual e o proximo a executar. Esse estado e persistido com as mesmas garantias de uma escrita normal no Postgres, o que significa que qualquer configuracao de replicacao ou backup ja existente tambem protege os workflows automaticamente.

Principais recursos

O pg_durable vem com um conjunto de funcionalidades pensadas para workflows de producao reais:

• Steps atomicos: cada etapa do workflow executa em uma transacao isolada - se falhar, apenas aquela etapa e reexecutada, sem reprocessar o que ja passou
• Retries configuravel: define politica de retry por step - numero de tentativas, backoff exponencial, delay entre tentativas - tudo configurado direto no DDL do workflow
• Timeouts por step: cada etapa pode ter um timeout independente, evitando que um step lento trave o workflow inteiro indefinidamente
• Compensacao (saga pattern): suporte a compensating transactions - se um step falha apos outros ja terem sido executados, os handlers de compensacao desfazem os efeitos dos steps anteriores
• Eventos externos: workflows podem aguardar sinais externos (como confirmacao de pagamento ou aprovacao humana) antes de continuar, sem polling ativo
• Observabilidade nativa: como tudo esta no Postgres, voce consulta o estado dos workflows com SELECT - sem dashboard externo, sem nova ferramenta de monitoramento
• Integracao com pgcron: workflows podem ser agendados via pg_cron para execucao periodica

Como comecar: instalacao passo a passo

O repositorio fica em github.com/microsoft/pg_durable. Para instalar, voce precisa do PostgreSQL 15 ou superior e do utilitario pgxs para compilar extensoes. Clone o repositorio, entre na pasta e execute make install para compilar e instalar a extensao no servidor Postgres.

Com a extensao instalada, ative ela no banco de destino com CREATE EXTENSION pg_durable. Isso cria as tabelas de controle no schema pg_durable e registra os tipos e funcoes necessarios. Nenhuma configuracao adicional e necessaria para comecar a usar.

Para criar seu primeiro workflow, defina-o com CREATE WORKFLOW seguido do nome e das etapas. Cada step e uma funcao SQL ou PL/pgSQL que recebe o contexto do workflow como parametro. Depois, dispare uma execucao com SELECT pg_durable.run('nome_do_workflow', parametros::jsonb) e acompanhe o progresso com SELECT * FROM pg_durable.executions.

Exemplo pratico: processamento de pedido com saga

Imagine um e-commerce onde processar um pedido envolve: debitar o estoque, cobrar o cartao, gerar a nota fiscal e acionar o sistema de logistica. Se a cobranca falhar apos o debito do estoque, voce precisa reverter o estoque. Esse e o padrao saga classico que o pg_durable implementa nativamente.

Com o pg_durable, voce define o workflow com os 4 steps normais e os 2 handlers de compensacao (reverter estoque se cobranca falhar, estornar cobranca se nota falhar). Quando o workflow executa e a cobranca falha no step 2, o pg_durable automaticamente dispara o handler de compensacao do step 1 (devolve o estoque) antes de marcar a execucao como falha.

O resultado e que todo o estado fica no PostgreSQL: os pedidos, o estoque, as cobranças e os logs de execucao do workflow estao no mesmo banco, na mesma transacao onde faz sentido estarem. Voce consulta tudo com SQL padrao, sem precisar correlacionar dados entre o banco e um orquestrador externo.

Comparacao com alternativas

O Temporal e a referencia atual em execucao duravel. E extremamente robusto, tem SDKs para varias linguagens e e usado por empresas como Uber e Stripe. A desvantagem e que exige infraestrutura separada: servidor Temporal, banco de dados proprio (geralmente Cassandra ou PostgreSQL) e um worker service rodando em paralelo. Para equipes pequenas, a complexidade operacional pode superar o beneficio.

O AWS Step Functions e o Azure Durable Functions sao alternativas gerenciadas que eliminam a operacao do orquestrador, mas prendem voce ao cloud provider. Se voce ja tem PostgreSQL e quer evitar cloud lock-in ou servicos gerenciados adicionais, o pg_durable e uma alternativa natural.

Para workflows simples sem necessidade de orquestracao complexa, muitas equipes ainda usam filas (RabbitMQ, Kafka, SQS) com processamento manual de estado. O pg_durable e uma opcao melhor quando voce precisa de garantias de exactly-once, compensacao automatica ou workflows de longa duracao que aguardam eventos externos.

Pontos positivos e limitacoes

O maior ponto positivo e a simplicidade operacional: se voce ja opera PostgreSQL em producao, nao precisa de nenhum novo componente de infraestrutura. Backups, replicacao, monitoramento, acesso com SQL - tudo que voce ja tem no banco cobre os workflows tambem. Para times que preferem menos pecas moveis na stack, isso e um argumento forte.

As limitacoes aparecem em escala. O PostgreSQL e excelente para workloads OLTP, mas workflows com milhoes de execucoes concorrentes podem gerar contencao nas tabelas de controle do pg_durable. O Temporal, com Cassandra por baixo, foi projetado especificamente para essa escala. Para a maioria dos sistemas, o pg_durable vai ser mais do que suficiente, mas workloads de altissima escala precisam de benchmark antes de adotar.

Outro ponto de atencao: por ser lancado recentemente, o ecossistema ainda esta se formando. Documentacao, exemplos de uso real e integracao com ORMs populares (como Prisma ou SQLAlchemy) podem estar incompletos. Projetos que adotarem agora vao estar na curva inicial de maturidade do projeto.

Casos de uso reais

Processamento financeiro: debitar conta, cobrar cartao, gerar comprovante, notificar usuario - cada step com compensacao automatica se qualquer um falhar. O estado fica no mesmo banco das transacoes financeiras, simplificando auditoria e reconciliacao.

Onboarding de usuarios: criar conta, enviar email de verificacao, aguardar confirmacao, liberar acesso, enviar email de boas-vindas. O workflow aguarda o evento de confirmacao de email sem polling ativo, sem fila externa, apenas uma linha na tabela de events do pg_durable.

Processos de aprovacao: submeter pedido, notificar aprovador, aguardar aprovacao humana (pode levar dias), executar acao aprovada. Workflows de longa duracao que vivem no banco sem ocupar memoria ou conexao enquanto aguardam.

Integracao com sistemas externos: chamar API de terceiro, aguardar webhook de confirmacao, processar resultado, atualizar registro. Se a API estiver fora do ar, o retry automatico com backoff cuida da resiliencia sem codigo adicional.

Dicas e boas praticas

Mantenha os steps idempotentes. Como o pg_durable pode reexecutar um step em caso de falha, a funcao de cada step deve produzir o mesmo resultado quando chamada mais de uma vez com os mesmos parametros. Use ON CONFLICT DO NOTHING ou verifique se o registro ja existe antes de inserir.

Defina timeouts realistas para cada step. Um step que chama uma API externa deve ter timeout compativel com o SLA dessa API, nao um timeout generico de 30 segundos. Steps sem timeout podem travar workflows por tempo indefinido se o recurso externo ficar indisponivel.

Use o schema pg_durable apenas para leitura direta. As tabelas de controle sao internas ao pg_durable e podem mudar entre versoes. Para monitorar execucoes, use as views e funcoes publicas documentadas no repositorio, nao acesse as tabelas internas diretamente.

Vale a pena adotar?

Para times que ja usam PostgreSQL e precisam de workflows resilientes sem adicionar Temporal ou fila ao stack, o pg_durable e uma das melhores noticias do ano para o ecossistema Postgres. A proposta de manter tudo no banco ja existente e convincente e a Microsoft tem historico de manter projetos open-source de qualidade no espaco de banco de dados.

O momento certo para adotar e agora para novos projetos que vao comecar do zero, onde o risco de maturidade do projeto nao pesa tanto. Para sistemas existentes com Temporal ou filas funcionando bem, a migracao precisa ser avaliada com cuidado - beneficio operacional real vs risco de migracao. Mas como ferramenta a conhecer e testar em ambiente de desenvolvimento, o pg_durable merece atencao de todo desenvolvedor backend que trabalha com PostgreSQL.