The middle path for durable workflows

A recent DBOS post — "Postgres is all you need for durable execution" — and its long Hacker News thread are a good map of the durable-workflow landscape right now. The thread is worth reading in full, because the most useful comments aren't cheering for one tool — they're describing the shape of the problem, and the shape is a spectrum.

The clearest framing of the trap came from one commenter:

"This feels like the sort of architecture that starts clean and then gradually grows most of the things a workflow-native system already has… Once you need retries, backoff, timeouts, cancellation, versioning, visibility, task routing, rate limits, leases, heartbeats, stuck-worker detection, replay/debugging semantics, workflow migration, fan-out/fan-in, long timers, audit trails, and operator tooling, the 'just use a database' story becomes 'build a poor copy of a workflow engine plus a bunch of workers' pretty quick."

That's exactly right, and it cuts both ways. "Just use a database" quietly regrows a workflow engine. But the heavyweight engines on the other end of the spectrum bring their own bill. The interesting question isn't database vs. orchestrator — it's which complexity do you want to own?

The two ends of the spectrum

One end: everything in the database. DBOS (and lighter cousins like Armin Ronacher's absurd, pgflow, River, Oban) keeps durable state in Postgres and leans on it for everything. It's genuinely appealing: if Postgres is already your core dependency, durable execution becomes "one more table" rather than a new system to run. The cost is that you inherit Postgres's ceiling. The thread is candid about it — SELECT … FOR UPDATE SKIP LOCKED is fine until the worker count climbs and vacuum can't keep up, dead tuples pile up, and the planner stops using your index. LISTEN/NOTIFY takes a global lock and doesn't scale on a busy instance. And as one experienced commenter warned, the tidy checkout example "heavily undermines the importance of correctness" — getting exactly-once and consistent state right under crashes is the hard part, and the database doesn't hand it to you for free. The model is elegant precisely because it's self-restricting: you can only express what Postgres can express, efficiently.

The other end: the heavyweight orchestrator. Temporal and Conductor OSS are fully featured, battle-tested, and built to scale — and the thread is just as candid about what that costs to run. One operator running Temporal on-prem for over a year called it "poorly designed, slow and ridiculously heavy infra-wise," describing a 12-node, 64-CPU Cassandra cluster and "millions" in infra to run hundreds of thousands of concurrent workflows, plus a sales team you bring legal to meet. Others echoed it: the SDK is genuinely nice, but you're standing up a cluster, a control plane, and an operations practice before you run your first workflow. Conductor is modern and has a strong AI/agent story, but it sits on the same heavyweight side of the line. These tools earn their keep at real scale and across many teams — but most workloads never reach the scale that justifies the footprint.

Where flowwork sits

flowwork is deliberately the middle path. It's a real durable engine — a compiled workflow graph with retries, exponential backoff, leases, versioning, fan-out/fan-in, long timers, replay, human-in-the-loop, and a full audit trail — none of which you have to regrow yourself. But it ships as a single binary plus a CLI that runs against your own Postgres on a laptop, a VPS, or a sandbox. No Cassandra, no control-plane cluster, no per-action cloud bill.

The distinction from the database-only camp is that the engine isn't bound to what the database can express. Postgres is where durable state lives, but the orchestration semantics — the retries, the replay, the correctness guarantees the HN thread keeps warning are easy to get wrong — are the engine's job, not yours to hand-roll in SQL and hope. absurd takes a similar lightweight stance and is a lovely option when you want the client side to stay tiny; flowwork's architecture is different in that it gives you the full workflow-native feature set as a first-class engine, while keeping the operational footprint close to "just Postgres."

So the honest pitch isn't "flowwork beats Temporal" or "flowwork replaces your database." It's that between the self-restricting database approach and the cluster-sized orchestrators there's a wide gap — lightweight to run, fully featured to build on — and that gap is where most teams actually live.