Microsoft's answer to Temporal is a Postgres extension that runs workflows in SQL

2026, the year of the Postgres queue

Microsoft open-sourced pg_durable, a PostgreSQL extension for durable execution — fault-tolerant, long-running workflows that survive crashes, restarts and failovers without starting over. It landed at 361 points with 83 comments, and the thread reads like a referendum on a decade-old debate: how much business logic belongs inside the database.

What it actually does

The pitch, verbatim from the docs: long-running SQL functions "for teams that already keep their state in Postgres and want to stop stitching together cron jobs, workers, queues, and status tables to make background work reliable." You define a workflow in SQL using composable operators (~> to chain steps, |=> to bind a named result), kick it off with df.start(), and Postgres checkpoints state between every step — so an interrupted workflow resumes from its last checkpoint instead of from scratch.

Under the hood it's a Rust extension built with pgrx, layered on two libraries: duroxide (a durable task orchestration engine) and duroxide-pg (the Postgres state provider). No Redis, no external orchestrator, no separate state tables — the workflow lives where the data lives, with the same backup, auth and access patterns as the database. The repo is unusually candid about its own limits: don't use it when the job is a single INSERT ... SELECT, when you need sub-millisecond synchronous requests, when the workflow spans heterogeneous systems, or when you need arbitrary application logic that doesn't map cleanly to SQL.

The stored-procedures objection, restated for 2026

The loudest reaction is that this is an old anti-pattern in new packaging.

"This smells like stored procedures. You can't unit test it. You can't version it. Business logic in the database, (hidden brain problem), harder to isolate noisy workloads, no observability… Good for local database only jobs though. Niche use cases." — a developer listing the classic objections

"Why would I want to store my control flow in the database and not in code? It feels strange." — an engineer who reaches for DAG schedulers like Airflow

The ex-app-engineer position, from someone who builds Postgres sharding tooling, is the most measured version: open to it, but instinctively wants the queue in Git.

"As an ex-app engineer though, I kind of prefer my queue logic to be in code, in Git, but maybe with the right tooling, you can change my mind." — the founder of a Postgres sharding project

Why put long jobs on the hardest thing to scale?

A second line of skepticism targets the operational cost of loading your database with long-running work.

"Isn't the database already one of the hardest piece of infras to scale? Why would you want to load it with additional long-running jobs?" — the creator of autojump, who works in medical imaging

"Feels like perhaps yet another inner-platform effect that would be unnecessary if popular programming languages/virtual machines already supported determinism… runtime state suspension, (de)serialization and resumption" — a commenter invoking the inner-platform effect

And the recurring "why not Temporal" question got asked directly — multiple readers worked through the README and still couldn't place where pg_durable beats an external orchestrator for workflows that call out to many systems, with one asking the comparison outright.

The case it quietly wins

Strip the skepticism and a real niche remains, one the README itself draws: if your state already lives entirely in Postgres, an external durable-execution service means a second system to run, back up, secure and reconcile against your database. pg_durable collapses that into one engine with one set of guarantees. The honest read from the thread is that it's not a Temporal killer — it's a way to delete the worker-plus-queue-plus-status-table scaffolding for the large class of jobs that never needed to leave the database in the first place. Whether you trust Postgres to also be your orchestrator is exactly the bet you're being asked to make.