pg_durable: Durable Workflows in PostgreSQL vs Temporal and Cron+Queue

Background jobs that need to survive a crash are one of those problems every backend team eventually reinvents from scratch. You build a jobs table, add status columns, write a polling worker, bolt on retry counters, and six months later you are debugging why a job got stuck in "processing" forever because the worker died mid-update.

Microsoft open-sourced pg_durable in early June 2026 to attack this problem from a different angle: define the workflow in SQL, and let PostgreSQL itself handle checkpointing, retries, and crash recovery. No separate orchestrator service. No queue infrastructure. The state lives in the same database as everything else you already trust with your data.

Here is what it actually does, and an honest comparison against the patterns you are probably already using.

The pattern everyone reinvents: background work that must survive a crash, restart, or failed step, with retries, checkpointing, and progress tracking. Currently solved with cron jobs plus status tables, external orchestrators like Temporal or AWS Step Functions, or hand-rolled plpgsql procedures with manual retry counters.

pg_durable replaces all of that with a SQL-native DSL. You define workflows as composable SQL expressions using three operators, and PostgreSQL handles the rest: checkpoint after every step, resume from the last completed step on crash, and expose the workflow state through ordinary SQL tables.

A minimal example, straight from the project's own quick start:

Three operators do the work. ~> sequences one step after another. |=> gives a step's result a name you can reference later. & runs two branches in parallel:

You query the workflow's progress and result with ordinary SQL:

Each step checkpoints automatically. If the process crashes mid-workflow (server restart, OOM kill, whatever), resuming picks up from the last completed step, not from the beginning. You are not writing that retry logic by hand.

Operational visibility comes from regular tables: df.instances, df.instance_nodes, df.instance_executions. No separate monitoring dashboard to stand up. The same SQL client and backup tooling you already use for your application data works here too.

Security and access control inherit from PostgreSQL directly. The workflow state is just data in your database, covered by your existing RBAC roles, backup schedules, and encryption-at-rest configuration.

Temporal is mature, proven at scale, and built for the general case: arbitrary application logic, calling out to multiple heterogeneous systems, complex branching and loops in whatever language your services are written in. If your workflow needs to call five different microservices with substantial conditional logic between steps, Temporal's general-purpose execution model is the better fit. pg_durable is specifically a SQL-native tool, and forcing complex non-SQL logic into it works against the grain.

pg_durable's case is narrower and specific: when the workflow steps are already SQL statements (or close to it), and you would rather not run, monitor, and keep available a second piece of infrastructure just to get durability for jobs that mostly touch your own database anyway.

This is the comparison that matters for most teams, because the cron+queue pattern is what almost everyone already has: a jobs table, status columns (pending, processing, failed, done), retry counters, and a worker process polling for work.

pg_durable's pitch is that this entire layer (the worker, the queue consumer, the scheduler glue) can disappear. Retry state and checkpointing move into Postgres tables the project maintains for you, instead of bespoke application code your team owns and debugs.

The job that used to be a single INSERT ... SELECT or one ordinary SQL statement might not need pg_durable at all. The project's own documentation explicitly lists "the problem is a single SQL statement" as a case where you do not need it.

Worth being direct about this, straight from the project's own scoping:

Docker quick start using the official image:

Run the hello-world example:

Query the result with SELECT df.result('your-instance-id'); and inspect the checkpoint structure with df.instance_nodes().

If you use GitHub Actions for CI, you can add the pg_durable Docker image as a service container in your workflow to test durable workflows alongside your integration tests.

This is genuinely new, open-sourced in early June, with Microsoft already running it inside Azure HorizonDB as a signal of internal confidence, but without years of broad production track record yet.

If you are a Postgres-heavy shop dealing with the specific pain of "background jobs that need to survive crashes reliably," it is worth experimenting with now. It is not yet an obvious default replacement for Temporal in complex, multi-system workflow scenarios, and teams with critical infrastructure should weigh the relative newness against the appeal of removing a layer of infrastructure.

For teams currently managing a cron+queue pattern that handles a handful of multi-step SQL workflows, pg_durable solves exactly the pain they are carrying. For teams running Temporal for complex cross-service orchestration, this is not a replacement. It is a complement for the subset of workflows that happen to be SQL-native. Like any caching strategy, the right answer depends on your specific workload shape.