Dbos: Durable Workflow Orchestration with Go and PostgreSQL

Post by bjornsing » Sat, Oct 04, 2025, 3:16 AM UTC

jedberg wrote: post #52

bjornsing wrote: post #27

Earlier quoted context omitted.

> Yes, in any durability framework there's still the possibility that a process crashes mid-step, in which case you have no choice but to restart the step. Golem [1] is an interesting counterexample to this. They run your code in a WASM runtime and essentially checkpoint execution state at every interaction with the outside world. But it seems they are having trouble selling into the workflow orchestration market. Pe…

The biggest downsides to their methodology are that the snapshots can get really big really quickly, and that they are hard to introspect since they are binary blobs of memory dumps.

Yeah the whole methodology depends on forgetting about state and treating it as a long-running program. If you need to look at the state then you connect a debugger, etc.

Post by odie5533 » Sat, Oct 04, 2025, 11:42 AM UTC

qianli_cs wrote: post #36

plmpsu wrote: post #32

Earlier quoted context omitted.

Thanks for the reply. So applications continuously poll the database for work? Have you done any benchmarking to evaluate the throughput of DBOS when running many workflows, activities, etc.?

In DBOS, workflows can be invoked directly as normal function calls or enqueued. Direct calls don't require any polling. For queued workflows, each process runs a lightweight polling thread that checks for new work using `SELECT ... FOR UPDATE SKIP LOCKED` with exponential backoffs to prevent contentions, so many concurrent workers can poll efficiently. We recently wrote a blog post on durable workflows, queues, and…

Even though I don't use DBOS, that blog post is gold.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL