DBOS argues that durable execution reduces to four mechanical primitives — persistent state, exactly-once semantics, leader election, and event delivery — all of which Postgres has shipped for two decades via tables, SELECT FOR UPDATE SKIP LOCKED, advisory locks, and LISTEN/NOTIFY. Their position is that the entire durable-execution category has been overbuilt: you don't need a separate control plane and state store when the database you already run can do the job with a thin library on top.
DBOS is candid that a single Postgres primary tops out around 10,000 workflow steps per second before requiring partitioning or read replicas. They acknowledge this is genuinely lower than what a sharded Temporal cluster can sustain, framing it as an honest tradeoff rather than a universal replacement — the substrate covers the vast majority of production workloads but not the highest-scale cases.
163 points on a vendor blog post is a meaningful signal that engineers operating Temporal clusters, Cadence brokers, and hand-rolled Kafka+state-store rigs are receptive to a simpler alternative. The durable-execution category exploded on the premise that workflow state needs a dedicated system, but the inconvenient question DBOS raises is whether that premise was ever true for most teams.
DBOS — the durable-execution startup founded by Postgres co-creator Michael Stonebraker and MIT's Matei Zaharia — published a post arguing that Postgres alone is sufficient infrastructure for durable workflows. The post hit Hacker News at 163 points, which is a meaningful signal for a vendor blog: the audience that has been forced to operate Temporal clusters, Cadence brokers, or hand-rolled Kafka+state-store rigs is receptive to the claim.
The argument is mechanical, not philosophical. Durable execution needs four primitives: persistent state, exactly-once step semantics, leader election for workers, and event delivery — and Postgres has been shipping all four for two decades. Persistent state is just a `workflow_state` table. Exactly-once is `SELECT ... FOR UPDATE SKIP LOCKED` plus an idempotency key column with a unique index. Leader election is an advisory lock (`pg_try_advisory_lock`). Event delivery is `LISTEN/NOTIFY`, which has been in Postgres since 1999. The DBOS library wires these together into a workflow API that looks indistinguishable from Temporal's, but the substrate is the database you already run.
The post is candid about scale limits. DBOS claims roughly 10,000 workflow steps per second on a single Postgres primary before you start needing partitioning or read replicas — a ceiling that covers the vast majority of production workloads but is genuinely lower than what a sharded Temporal cluster can sustain. That's the actual tradeoff being proposed.
The durable-execution category exploded over the last four years on a specific premise: workflow state is too important to lose, so you need a dedicated system to hold it. Temporal raised at a $1.5B valuation on that pitch. Restate, Inngest, Hatchet, Trigger.dev, and a half-dozen others followed. Every one of them ships a control plane, a worker SDK, and operational documentation about how to run their state store in production.
The inconvenient question DBOS is forcing: if your durability guarantees ultimately bottom out in a database transaction anyway — and they do, in every one of these systems — what is the orchestrator layer actually adding besides another piece of infrastructure to page someone about at 3 AM? Temporal's own architecture is a stateless frontend talking to Cassandra or Postgres. Inngest is a queue plus Postgres. The state store is doing the real work; the orchestrator is mostly a workflow DSL with a UI bolted on.
The Hacker News thread surfaced the strongest counter-arguments, and they're worth taking seriously. The most credible objection is that workflow orchestration is not just durability — it's signaling, child workflows, cancellation propagation, scheduled retries with jitter, and a visibility layer good enough to debug a six-hour-old execution at 2 AM. Temporal has spent years building exactly this surface area. A `SELECT FOR UPDATE` loop will get you durable state, but it won't get you the Temporal Web UI showing why workflow `abc-123` is stuck on step 7 of 12, and it won't give you the per-workflow timeline view that turns post-incident forensics from "grep the logs" into "click the timeline."
The second objection is operational. Postgres is great until your workflow table hits a billion rows and your VACUUM windows start eating your write throughput. A workload of 5,000 workflows/sec sustained for a month is 13 billion rows. You will be partitioning. You will be tuning autovacuum. You will be doing the database engineering that the Temporal team has already done for you.
The third — and most interesting — objection is that the "just use Postgres" pitch assumes you have one Postgres. Many shops have a primary OLTP database that is already saturated, and adding workflow state to it means contending for the same connection pool, the same WAL, the same checkpointer. Running a separate Postgres just for workflows is a perfectly reasonable answer, but at that point you've added a database to your stack and the operational delta versus running a dedicated state store is smaller than DBOS implies.
If you're at the stage where you're evaluating Temporal versus Inngest versus rolling your own, the honest answer is: start with Postgres. The teams that have gotten burned have almost always done so by adopting a heavy orchestration platform before they had the workflow volume to justify it, not by deferring the decision and bolting on durable execution to their existing database. A few hundred lines of SQL plus a worker loop will carry most products to seven figures of ARR. When you hit the scaling wall, you will know — your VACUUM logs will tell you — and you will have a clean migration path because your workflows are already defined in code, not in a vendor DSL.
If you're already on Temporal and it's working, the post is not a migration prompt. The cost of running Temporal at small-to-medium scale is real but bounded, and the developer experience advantages (signals, child workflows, the visibility UI) are not free to rebuild. The DBOS argument is most relevant at the front edge of adoption.
The real action item is calibration. Before adding any durable-execution infrastructure, write down your actual workflow throughput, your tolerance for replay-on-failure, and your debugging requirements — and check whether `SELECT FOR UPDATE SKIP LOCKED` plus an idempotency column would handle it. For most teams the answer is yes, and the second-order benefit is that your workflow state lives in the same database as your business data, which makes joins for analytics, support tooling, and compliance audits trivial instead of cross-system.
DBOS isn't going to kill Temporal — Temporal's enterprise traction is too deep and the high-end workloads it targets are real. But the durable-execution category is going to bifurcate. The high end keeps the orchestrators. The long tail — every CRUD app that needs a retry queue and an audit log — is going to absorb back into Postgres, the same way it absorbed job queues, full-text search, vector embeddings, and time-series data. "Just use Postgres" has been the most reliable architectural bet of the last decade. Workflow durability is the next thing it eats.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.