Microsoft open-sources pg_durable, putting Temporal-style durable workflows inside Postgres

Microsoft open-sourced pg_durable on June 10, a Postgres extension that runs durable workflows inside the database. The extension ships with retries, fan-out, scheduling, and crash-resume baked in, the operations work most teams currently solve with a workflow engine (Temporal, Inngest, or hand-rolled cron) plus a message queue plus an external state store. pg_durable’s bet is that those primitives can live where the data already does.

What shipped

A pg_durable workflow is a SQL function. Microsoft describes it as “a graph of SQL steps that PostgreSQL executes and checkpoints as it goes,” with composable operators (~> for sequence, |=> for fan-out) and a small runtime that persists step state into a dedicated schema. If the database restarts mid-step, the worker resumes from the last checkpoint without manual intervention. The runtime is two Rust crates: duroxide for the deterministic-replay orchestration loop, and duroxide-pg for state persistence. Both run inside the Postgres server through pgrx; there is no external control plane, no separate worker tier, and no second database to operate.

Microsoft positions three target workloads up front. The first is vector-embedding pipelines, where workflows chunk source data, call an embedding API, and upsert into pgvector. The second is scheduled maintenance, where a workflow detects table bloat, notifies an on-call channel, waits for approval, and runs VACUUM. The third is human-in-the-loop sequences that gate downstream steps on external decisions. Each workload currently spans at least two services in a typical stack. pg_durable collapses them into a SQL function that returns an instance ID and a status row queryable from the same transaction.

Licensing is the PostgreSQL License, the same permissive terms the upstream project uses, which removes the friction that has slowed adoption of other vendor-launched extensions. pg_durable ships as a Debian package for Postgres 17 and 18 with source available for custom builds, and it ships preinstalled in Azure HorizonDB, Microsoft’s new managed PostgreSQL service announced alongside it. Microsoft positions the open-source release as part of a broader Build 2026 push that also took pg_duckdb and pg_ivm to general availability on Azure.

Where this lands in the market

The competitive shape is more interesting than the feature list. Temporal and the engines that followed it (Restate, Inngest, Trigger.dev) sell a programming model that assumes the application owns workflow definitions and the engine owns durability. pg_durable proposes the opposite: the database owns durability, and the workflow is just another SQL artifact. That reframing matters less for greenfield startups picking a stack from scratch than for the long tail of Postgres-first companies that already store their domain data, their billing events, and increasingly their vector embeddings in the same cluster, and that have been reluctant to introduce a second source of truth for workflow state.

It also lands in a year where Postgres extension territory has become competitive product surface. Supabase’s $500M Series F at a $10.5B valuation (June 5) tied Postgres to AI-agent provisioning. Neon’s branch-first developer loop reads as a developer-experience answer in the same category. Microsoft has been quieter than either but has shipped a steady cadence: Azure HorizonDB, pg_duckdb and pg_ivm GA at Build, and now an extension unmistakably aimed at the workflow-engine slice of the agent stack. Each move is individually small. Together they read as a Postgres that competes for workloads enterprises previously fanned out to Temporal, Redis-backed queues, and a separate cron service.

For working developers, the test is operational, not architectural. A SQL workflow that runs inside the database earns operational simplicity (one cluster, one backup story, one tail-latency budget) at the cost of mingling its retry storms with transactional traffic. The duroxide design includes deterministic replay and a dedicated schema for queue state, which is the right pattern for keeping the two workloads from colliding, but the proof will be in production traces. The first wave of adopters is likely to be teams already running pgvector for embeddings and ready to stop maintaining a parallel orchestrator for the same data path.

What’s worth watching

1. Observability tooling. pg_durable persists workflow state in a dedicated schema, which means standard Postgres monitoring (pg_stat_*, log lines) sees it. What is missing is the equivalent of Temporal’s Web UI, the per-workflow timeline view operators rely on for debugging stuck executions. A community UI or a Microsoft-hosted one would shift adoption from “credible primitive” to “credible production engine.”

2. Cross-version support. The extension targets Postgres 17 and 18 today. Supabase and Neon both still default new projects to 17 or 16, and the long tail of managed providers sits on 15. If Microsoft holds the line on a narrow version window, pg_durable becomes a HorizonDB feature in practice even though it is technically portable. Wider version support is the lever that determines whether the other managed-Postgres vendors carry it.

3. The Temporal response. Temporal, Restate, and Inngest have all been pricing their open-source tiers against the Postgres-as-state-store argument for two years. A vendor-backed in-database engine narrows the case for those products specifically in the Postgres-shop segment. Expect a clarifying post within a quarter on why an external engine still wins for multi-region, cross-language, or polyglot workflows.

Sources cited

1. Microsoft Tech Community: Introducing Durable Functions in PostgreSQL techcommunity.microsoft.com
2. GitHub: microsoft/pg_durable github.com
3. InfoQ: Microsoft Open-Sources PostgreSQL Extension for In-Database Durable Execution www.infoq.com
4. pg_durable documentation microsoft.github.io