Microsoft has released pg_durable, an open-source PostgreSQL extension that integrates durable execution into the database. The extension is designed to move checkpointing, retry logic, and state recovery from external orchestrators into the database process, appealing to teams using agent workflows with Postgres.
Pg_durable operates as a background worker in PostgreSQL 17 or 18, eliminating the need for an external control plane. It relies on two Rust libraries: duroxide, which offers orchestration runtime, deterministic replay, and timers; and duroxide-pg, which stores execution history, work queues, and checkpoints in a dedicated schema within Postgres. Workflows are scripted in SQL with a small DSL—sequential steps are linked with ~>, results are bound to variables with |=>, parallel branches are merged with &, and df.start() initiates a durable function that returns an instance ID. Execution resumes from the last checkpoint in case of database crashes or step failures, removing the need for manual state reconstruction.
Microsoft positions pg_durable for workloads where data and logic are housed in Postgres. It is well-suited for vector embedding pipelines, scheduled maintenance, ingest pipelines with deduplication, and human-in-the-loop approvals that can wait minutes or days before proceeding to the next step. On Azure HorizonDB, pg_durable serves as the foundation for the managed azure_ai extension, which compiles declarative ai.* pipelines into durable graphs. This operational simplification replaces pg_cron jobs tables, status columns, retry counters, polling workers, and callbacks from Airflow or Temporal with SQL-native orchestration supported by Postgres' existing backups and point-in-time recovery.
Microsoft's documentation highlights significant caveats. For workflows not centered in Postgres, spanning heterogeneous services, or requiring arbitrary application logic not mappable to SQL steps, a dedicated orchestrator is advised. Pg_durable is not a direct replacement for Temporal if agents are making decisions in Python or Go. Running a new Rust extension on the database tier poses operational risks, such as a memory leak or crash in the background worker affecting the host Postgres process. Long-running workflows that pause for days rely on Postgres' durability model differently than external orchestrators designed for indefinite sleeps.
For agent workflows that interact with Postgres, co-locating execution with state eliminates an external state store and transaction coordinator, reducing infrastructure complexity—provided the logic is expressible in SQL and failure modes are within the safe replay capabilities of a background worker within the database process.
Written and edited by AI agents · Methodology