Dbos: Durable Workflow Orchestration with Go and PostgreSQL

This sounds...impossible? If you have some step in your workflow, either you 1) record it as completed when you start, but then you can crash halfway through and when you restore the workflow it now isn't processed 2) record it as completed after you're done, but then you can crash in-between completing and recording and when you restore you run the step twice.

#2 sounds like the obvious right thing to do, and what I assume is happening, but is not exactly once and you'd need to still be careful that all of your steps are idempotent.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#5

Post by drakenot » Fri, Oct 03, 2025, 3:29 AM UTC

hmaxdml wrote: post #2

Thanks for posting! I am one of the author, happy to answer any question!

I read the Dbos vs Temporal thing, but can you speak more about if there is a different in durability guarantees?

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#6

Post by jiggunjer » Fri, Oct 03, 2025, 3:33 AM UTC

Sounds exactly like how Temporal markets itself. I find that the burden of creating idempotent sub-steps in the workflow falls on the developer, regardless of checkpoints and state management at the workflow level.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#7

Post by saintarian » Fri, Oct 03, 2025, 3:35 AM UTC

hmaxdml wrote: post #2

Thanks for posting! I am one of the author, happy to answer any question!

Great project! Love the library+db approach. Some questions:

1. How much work is it to add bindings for new languages? 2. I know you provide conductor as a service. What are my options for workflow recovery if I don't have outbound network access? 3. Considering this came out of https://dbos-project.github.io/, do you guys have plans beyond durable workflows?

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#8

Post by KraftyOne » Fri, Oct 03, 2025, 3:35 AM UTC

chc4 wrote: post #4

> Exactly-Once Event Processing This sounds...impossible? If you have some step in your workflow, either you 1) record it as completed when you start, but then you can crash halfway through and when you restore the workflow it now isn't processed 2) record it as completed after you're done, but then you can crash in-between completing and recording and when you restore you run the step twice. #2 sounds like the obvio…

The specific claim is that workflows are started exactly-once in response to an event. This is possible because starting a workflow is a database transaction, so we can guarantee that exactly one workflow is started per (for example) Kafka message.

For step processing, what you say is true--steps are restarted if they crash mid-execution, so they should be idempotent.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#9

Post by odie5533 » Fri, Oct 03, 2025, 3:36 AM UTC

For a project with minimal users, we get a lot of DBOS posts.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#10

Post by jiggunjer » Fri, Oct 03, 2025, 3:36 AM UTC

hmaxdml wrote: post #2

Thanks for posting! I am one of the author, happy to answer any question!

Does it natively support job priorities? E.g. if there's 10 workflows submitted and I start up a worker, how does it pick the first job.