CEVIU Logo
Voltar

Microsoft libera pg_durable: orquestração de workflows diretamente no PostgreSQL

Aprofundamento CEVIU

Aprofundamento

O pg_durable não é só mais uma extensão: é uma mudança de arquitetura para quem já opera PostgreSQL em produção. Ele transforma o banco em um runtime de workflows duráveis, com estado persistido no mesmo esquema dos dados, checkpoints automáticos e retentativas nativas, tudo via SQL com operadores como ~> (sequência) e & (paralelismo). Isso elimina a camada intermediária de orquestração que equipes normalmente constroem com Temporal, Airflow ou filas externas, reduzindo latência média em 120–350 ms por workflow, segundo testes preliminares da Microsoft com cargas de ETL e pipelines de incorporação de vetores no Azure HorizonDB.

A extensão roda como worker interno do PostgreSQL, usando Rust via pgrx e as bibliotecas duroxide, com estado armazenado em tabelas duroxide.*, integradas à mesma política de backup, PITR e replicação do cluster. Para equipes que já usam PostgreSQL como camada central de dados (como nas estratégias de marketing orientadas por IA descritas em 28/05), isso significa que governança, compliance e observabilidade passam a ser unificados: não há mais estado 'escondido' em filas ou serviços externos. A instalação exige reinicialização do servidor e depende do PostgreSQL 17+, mas não requer mudanças na aplicação, apenas novas consultas SQL.

O que mudou

Em 28/05, o CEVIU mostrou como usar ENUMs e JSONB no PostgreSQL para gerenciar estado de workflow de forma confiável, mas ainda exigindo workers externos e lógica de controle fora do banco. Agora, com o pg_durable, essa lógica entra diretamente no motor: não é mais sobre *modelar* estado em SQL, mas *executar* workflows com garantia de durabilidade dentro dele. Também contrasta com a abordagem SQLite + Litestream (01/06): lá, a simplicidade vem da troca de escala por inspecionabilidade; aqui, a escala é mantida sem sacrificar controle operacional, porque backup, recuperação e segurança seguem os mesmos padrões do PostgreSQL corporativo já validados em ambientes como o Azure HorizonDB.

Por que isso importa

Para arquitetos de TI e líderes de infraestrutura, o pg_durable reduz a superfície de ataque e o custo total de propriedade de workflows: menos componentes, menos licenças, menos pontos de falha e menos ferramentas a auditar. Em ambientes regulados (financeiro, saúde), ter estado de workflow e dados transacionais sob o mesmo mecanismo de backup atômico e recuperação de ponto no tempo simplifica auditorias de conformidade com LGPD e ISO 27001. E para equipes que já investiram em plataformas SQL no Kubernetes com Crossplane (03/06), o pg_durable se torna um bloco nativo de automação resiliente, sem precisar provisionar ou manter clusters adicionais de orquestração.

Linha do tempo

  1. Lançamento de recursos de prioridade e equidade em filas de tarefas para Temporal

  2. Microsoft integra Grok 4.3 ao Foundry para workflows de IA corporativa

  3. Lançamento do pg_infer 1.0.0 para inferência de modelos transformer em SQL

  4. Uso do PostgreSQL como camada central para gerenciamento de estado de workflow em marketing orientado por IA

  5. Proposta de uso de SQLite + Litestream para workflows duráveis simples e inspecionáveis

  6. Construção de plataforma SQL corporativa no Kubernetes com Crossplane e Azure PostgreSQL

  7. Lançamento do pg_durable pela Microsoft como extensão open source para orquestração de workflows diretamente no PostgreSQL

Perguntas frequentes

O pg_durable substitui o Temporal ou o Airflow?

Não substitui em todos os casos. Funciona bem para workflows centrados em dados e operações SQL, como ETL ou chamadas de API a partir de triggers. Mas não é indicado para fluxos que exigem SDKs em Python/TypeScript, UIs avançadas de monitoramento ou coordenação entre múltiplos bancos heterogêneos, onde Temporal ou Airflow ainda são mais adequados.

Posso usar pg_durable em ambiente on-premises ou só no Azure?

É open source e compatível com qualquer PostgreSQL 17+ ou 18, desde que instalado com pgrx e Rust. Já está sendo testado em clusters on-prem com Patroni e em provedores como AWS RDS (com suporte a extensões customizadas) e Google Cloud SQL. Não depende de serviços Azure.

Como fica a observabilidade de workflows executados com pg_durable?

O estado é visível diretamente via SQL: há tabelas como duroxide.workflow_instances e duroxide.workflow_steps, que podem ser consultadas, unidas a tabelas de negócios e expostas em dashboards com Grafana ou Power BI. Não há UI própria, mas integra nativamente com ferramentas de logging já usadas no stack PostgreSQL.

Há risco de sobrecarregar o PostgreSQL com execução de workflows?

O pg_durable usa um worker de background dedicado, com configuração de concorrência ajustável via parâmetros como pg_durable.max_workers. Testes da Microsoft mostram impacto controlado até 200 workflows simultâneos em instâncias de 16 vCPUs, desde que as etapas sejam majoritariamente I/O-bound e não CPU-bound.

Avalie este artigo:
Compartilhar:
Categoria
CEVIU TI
Publicado
09 de junho de 2026
Fonte
CEVIU TI

Quer receber mais sobre CEVIU TI?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser