The editorial argues that pg_durable's killer feature is transactional unity: the same commit that mutates business data also marks the workflow step complete. This eliminates the eventual-consistency window between business state and workflow state that forces every Temporal shop to write an outbox pattern by month three.
The editorial frames pg_durable as the first hyperscaler endorsement of an architectural bet DBOS made commercially in 2023 and that Inngest's flow-control work has been drifting toward. Microsoft putting a free Apache-2 implementation on the table legitimizes the category and signals it is moving from startup experiment to mainstream pattern.
The editorial highlights that adopting Temporal typically means three to five containers (Cassandra/Postgres, frontend, matching, history, workers, UI) plus a fresh on-call surface. pg_durable collapses that entire shape into a Postgres extension — if you can run Postgres, you can run durable workflows, with no separate matching or history services.
The submitter surfaced the project as 'in-database durable execution,' emphasizing the architectural simplification of running workflows inside Postgres rather than as a separate service. The framing — and the 361-point reception — suggests strong community resonance with the idea that durable execution should not require a parallel distributed system.
Microsoft published pg_durable, a Postgres extension that runs durable workflows inside the database itself. The repo landed on GitHub and hit 361 on Hacker News within a day. The pitch: instead of bolting Temporal, Inngest, or Restate onto your stack to get crash-safe workflows, you express the workflow in SQL and pl/pgsql, the state lives in regular Postgres tables, and the same transaction that records *step 3 done* is the one that mutates your business data.
The extension exposes the standard durable-execution feature set — steps, retries, idempotency keys, durable timers, signals — but the execution surface is a Postgres operator, not a remote service. A worker process pulls ready tasks via `SKIP LOCKED`, executes them, and commits the result transactionally. There is no matching service, no history service, no separate UI tier. If you can run Postgres, you can run pg_durable.
This is the same architectural bet DBOS made commercially in 2023, and the direction Inngest's flow-control work has been drifting toward — but Microsoft is the first hyperscaler to put a free, Apache-2 implementation on the table.
For most teams, "we need workflows" today means standing up a Temporal cluster: Cassandra or Postgres for state, a frontend service, matching service, history service, workers, a UI. That's three to five containers, a new schema migration story, and a fresh on-call surface. Temporal is excellent technology, but it's a parallel database with its own consistency model that you must keep in sync with your application's database — which is why every Temporal shop ends up writing an outbox pattern by month three.
pg_durable collapses that entire shape. The same transaction that increments a balance can mark a workflow step complete — no two-phase commit, no outbox table, no eventual-consistency window between business state and workflow state. That property is hard to overstate. It is the single architectural feature that has driven DBOS's pitch for two years, and it is now table stakes for any Postgres shop willing to install one extension.
The HN thread split predictably along scale lines. Engineers running 10-100 workflow executions per second were thrilled ("we ripped out Temporal in a weekend for this"). Engineers running 10,000+ pushed back: Postgres `SKIP LOCKED` throughput tops out somewhere in the low thousands of tasks/sec before you start fighting autovacuum and bloat on the task queue. Temporal's matching service exists precisely to scale past that ceiling. Both camps are right about their own problem.
Microsoft's choice to ship this matters strategically. Azure Database for PostgreSQL is one of Azure's fastest-growing lines, and durable execution is one of the last remaining reasons enterprises pick a separate workflow service over their primary database. If Postgres-as-workflow-engine becomes a serious default, the moat for Temporal Cloud and DBOS Cloud shifts from "we have durable execution" to "we have observability, multi-region replication, and SDK ergonomics" — a real moat, but a much smaller one.
The Apache-2 license is the second tell. The dominant trend in infra OSS over the last 18 months has been BSL or SSPL relicensing the moment a managed-cloud competitor appears. Microsoft picking a permissive license here means AWS RDS, Supabase, Neon, and CrunchyData can each ship it in their managed Postgres tomorrow with no friction. That looks like an unforced concession; it isn't. Azure already runs the workload. Commoditizing it kneecaps any startup whose pitch is "durable execution as a service."
If you're currently running Temporal for fewer than ~500 concurrent workflows, you should evaluate pg_durable seriously. The operational savings are real: one fewer cluster, one fewer schema to keep in sync, one fewer SDK to upgrade. The break-even point is roughly when your sustained workflow throughput exceeds what a single Postgres primary can absorb — call it 1-2k tasks/sec, depending on step duration and how aggressively you tune autovacuum on the task tables.
If you're considering adding workflows for the first time — retries for outbound webhooks, multi-step user onboarding, scheduled email sequences, billing reconciliation — pg_durable is the lowest-friction path that has ever existed for this work. `CREATE EXTENSION pg_durable;` and you have crash-safe steps with retries. There is no separate service to deploy, monitor, secure, or pay for. For teams whose dominant infrastructure pain is "we have too many moving parts," this is the correct answer until proven otherwise by load.
The trap to avoid: don't put long-running CPU-heavy work *inside* a pg_durable step. The worker pulls a task and executes in-process; if the step does 30 seconds of compute, that's a Postgres connection held open and a worker slot consumed. Use the extension to *coordinate* work — issue the API call, await the webhook, mutate the row — not to *do* the work itself. Temporal requires the same discipline, but its physical distance from your DB makes accidental violations cheaper. With pg_durable, sloppy step code shows up as connection-pool exhaustion on your primary.
One pragmatic migration pattern surfaced repeatedly in the HN comments: keep Temporal for high-volume, high-fanout pipelines (payment processing, batch ingestion), and use pg_durable for per-tenant business processes (signup, billing, scheduled reports). The two coexist fine, and the boundary lines up almost exactly with where single-primary Postgres throughput becomes the limiter.
The next six months will tell us whether pg_durable becomes the default Postgres workflow primitive or just another entry in a crowded field. Three signals to watch: whether AWS RDS adds it to the supported-extensions list (which would matter more than any benchmark), whether DBOS open-sources comparable core functionality in response, and whether Temporal ships a "Temporal Embedded" that runs in-process against your existing Postgres. Microsoft has effectively forced the question of whether durable execution is a product or a feature — and once a hyperscaler commodifies something, it rarely uncommodifies. For Postgres-first shops, this is the kind of week where your architecture diagram gets meaningfully simpler.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.