pg_durable: Microsoft lança execução durável dentro do PostgreSQL

O que é o pg_durable

Em junho de 2026, a Microsoft publicou no GitHub o pg_durable, uma extensão open-source para PostgreSQL que traz execução durável diretamente para dentro do banco de dados. O conceito de execução durável (durable execution) existe ha anos em ferramentas como Temporal é Azure Durable Functions, mas sempre exigiu um serviço externo separado do banco. O pg_durable muda isso: o próprio PostgreSQL passa a garantir que seus workflows sobrevivam a falhas, crashs é reinicios sem precisar de infraestrutura adicional.

A ideia central é simples mas poderosa: se você já confia no PostgreSQL para guardar os dados do seu sistema, por que não confiar nele também 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 já oferece por padrão: WAL (Write-Ahead Log), transações ACID é replicação.

O projeto está disponível no perfil oficial da Microsoft no GitHub como software open-source é entrou em destaque no Hacker News no dia do lançamento, com mais de 400 pontos é 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 extensão do PostgreSQL que adiciona um novo tipo de objeto ao banco: o workflow. Você define um workflow como uma sequência de etapas (steps) escritas em SQL ou em linguagens suportadas via procedimentos armazenados. Cada etapa é executada dentro de uma transação própria é o resultado é gravado no banco antes de avancar para a próxima.

O mecanismo chave é o checkpoint automático. Diferente de um script que roda de ponta a ponta é falha no meio sem registro, o pg_durable grava o estado após cada etapa concluída. Se o processo morrer no meio do caminho (crash do servidor, deploy, timeout), na próxima reinicializacao o workflow retoma exatamente de onde parou, sem reprocessar o que já foi concluído é sem perder dados.

Por baixo dos panos, o pg_durable cria tabelas de controle no schema do banco para rastrear o estado de cada execução: qual workflow está rodando, em qual step está, qual foi o resultado de cada step concluído é qual é o próximo a executar. Esse estado é persistido com as mesmas garantias de uma escrita normal no Postgres, o que significa que qualquer configuração de replicação ou backup já existente também protege os workflows automaticamente.

Principais recursos

O pg_durable vem com um conjunto de funcionalidades pensadas para workflows de produção reais:

• Steps atomicos: cada etapa do workflow executa em uma transação isolada - se falhar, apenas aquela etapa é reexecutada, sem reprocessar o que já passou
• Retries configuravel: define politica de retry por step - número 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
• Compensação (saga pattern): suporte a compensating transactions - se um step falha após outros já terem sido executados, os handlers de compensação 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 está no Postgres, você consulta o estado dos workflows com SELECT - sem dashboard externo, sem nova ferramenta de monitoramento
• Integração com pgcron: workflows podem ser agendados via pg_cron para execução periodica

Como comecar: instalacao passo a passo

O repositório fica em GitHub.com/microsoft/pg_durable. Para instalar, você precisa do PostgreSQL 15 ou superior é do utilitario pgxs para compilar extensões. Clone o repositório, entre na pasta é execute make install para compilar é instalar a extensão no servidor Postgres.

Com a extensão instalada, ative ela no banco de destino com CREATE EXTENSION pg_durable. Isso cria as tabelas de controle no schema pg_durable é registra os tipos é funções necessarios. Nenhuma configuração adicional é necessaria para comecar a usar.

Para criar seu primeiro workflow, defina-o com CREATE WORKFLOW seguido do nome é das etapas. Cada step é uma função SQL ou PL/pgSQL que recebe o contexto do workflow como parâmetro. Depois, dispare uma execução com SELECT pg_durable.run('nome_do_workflow', parâmetros::jsonb) é acompanhe o progresso com SELECT * FROM pg_durable.executions.

Exemplo prático: processamento de pedido com saga

Imagine um é-commerce onde processar um pedido envolve: debitar o estoque, cobrar o cartao, gerar a nota fiscal é acionar o sistema de logistica. Se a cobranca falhar após o debito do estoque, você precisa reverter o estoque. Esse é o padrão saga clássico que o pg_durable implementa nativamente.

Com o pg_durable, você define o workflow com os 4 steps normais é os 2 handlers de compensação (reverter estoque se cobranca falhar, estornar cobranca se nota falhar). Quando o workflow executa é a cobranca falha no step 2, o pg_durable automaticamente dispara o handler de compensação do step 1 (devolve o estoque) antes de marcar a execução como falha.

O resultado é que todo o estado fica no PostgreSQL: os pedidos, o estoque, as cobranças é os logs de execução do workflow estao no mesmo banco, na mesma transação onde faz sentido estarem. Você consulta tudo com SQL padrão, sem precisar correlacionar dados entre o banco é um orquestrador externo.

Comparacao com alternativas

O Temporal é a referência atual em execução durável. É extremamente robusto, tem SDKs para varias linguagens é é usado por empresas como Uber é Stripe. A desvantagem é que exige infraestrutura separada: servidor Temporal, banco de dados próprio (geralmente Cassandra ou PostgreSQL) é um worker service rodando em paralelo. Para equipes pequenas, a complexidade operacional pode superar o beneficio.

O AWS Step Functions é o Azure Durable Functions sao alternativas gerenciadas que eliminam a operação do orquestrador, mas prendem você ao cloud provider. Se você já tem PostgreSQL é quer evitar cloud lock-in ou serviços gerenciados adicionais, o pg_durable é uma alternativa natural.

Para workflows simples sem necessidade de orquestração complexa, muitas equipes ainda usam filas (RabbitMQ, Kafka, SQS) com processamento manual de estado. O pg_durable é uma opcao melhor quando você precisa de garantias de exactly-once, compensação automática ou workflows de longa duracao que aguardam eventos externos.

Pontos positivos é limitacoes

O maior ponto positivo é a simplicidade operacional: se você já opera PostgreSQL em produção, não precisa de nenhum novo componente de infraestrutura. Backups, replicação, monitoramento, acesso com SQL - tudo que você já tem no banco cobre os workflows também. Para times que preferem menos pecas moveis na stack, isso é um argumento forte.

As limitacoes aparecem em escala. O PostgreSQL é excelente para workloads OLTP, mas workflows com milhoes de execuções 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 atenção: por ser lancado recentemente, o ecossistema ainda está se formando. Documentação, exemplos de uso real é integração 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 compensação automática se qualquer um falhar. O estado fica no mesmo banco das transações financeiras, simplificando auditoria é reconciliacao.

Onboarding de usuarios: criar conta, enviar email de verificação, 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 ação aprovada. Workflows de longa duracao que vivem no banco sem ocupar memoria ou conexão enquanto aguardam.

Integração com sistemas externos: chamar API de terceiro, aguardar webhook de confirmacao, processar resultado, atualizar registro. Se a API estiver fora do ar, o retry automático com backoff cuida da resiliência sem código adicional.

Dicas é boas práticas

Mantenha os steps idempotentes. Como o pg_durable pode reexecutar um step em caso de falha, a função de cada step deve produzir o mesmo resultado quando chamada mais de uma vez com os mesmos parâmetros. Use ON CONFLICT DO NOTHING ou verifique se o registro já 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, não um timeout genérico 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 é podem mudar entre versões. Para monitorar execuções, use as views é funções públicas documentadas no repositório, não acesse as tabelas internas diretamente.

Vale a pena adotar?

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

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