Dbos: Durable Workflow Orchestration with Go and PostgreSQL • Hacker News Board

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#51

Post by atombender » Fri, Oct 03, 2025, 3:55 PM UTC

hmaxdml wrote: post #49

atombender wrote: post #45

I've played with DBOS and like it, but I have to say the lack of a control plane and UI in the open source version means it may have a hard time competing with Temporal, which provides both. Being able to see the state of workflows and their histories is a key part of having an application in production. Without a control plane, my understanding is that DBOS can't offer the same kind of failure recovery as Temporal,…

DBOS stores all the workflow metadata in postgres, which is readily queryable for observability. We've recently seen a user setup an entire Grafana dashboard to observe their numerous workflows. A postgres server can host many databases, and multiple applications can use the same server. The same dashboard can be used to monitor them all. With respect to recovery: A new Transact process will run a round of recovery a…

Temporal has a full-fledged UI where I can drill down into individual workflow runs and see the graph of activities, detail logs, retry counts, inputs and outputs, and so on. Temporal also has an API to introspect this without reaching into a database.

You can share a database server with DBOS, but it's common to give applications dedicated database resources (one Postgres cluster per app in different regions), meaning it won't work with DBOS unless you write your own federated control layer that can speak to multiple instances. Which is also not offered out of the box. Sharing one DBOS-specific server across all apps would introduce a single point of failure.

Again, I like DBOS, but right now the value proposition isn't that great given that Temporal has already nailed this.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#52

Post by jedberg » Fri, Oct 03, 2025, 4:01 PM UTC

bjornsing wrote: post #27

KraftyOne wrote: post #13

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. Where DBOS really shines (vs. Temporal and other workflow systems) is a radically simpler operational model--it's just a library you can install in your app instead of a big heavyweight cluster you have to rearchitect your app to work with. This blog post goes into…

> 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.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#53

Post by jedberg » Fri, Oct 03, 2025, 4:03 PM UTC

bjornsing wrote: post #40

qianli_cs wrote: post #30

Earlier quoted context omitted.

I think one potential concern with "checkpoint execution state at every interaction with the outside world" is the size of the checkpoints. Allowing users to control the granularity by explicitly specifying the scope of each step seems like a more flexible model. For example, you can group multiple external interactions into a single step and only checkpoint the final result, avoiding the overhead of saving intermedi…

Sure you get more control with explicit state management. But it’s also more work, and more difficult work. You can do a lot of writes to NVMe for one developer salary.

It's not really more work to be explicit about the steps and workflows. You already have to break your code into steps to make your program run. Adding a single decorator isn't much extra work at all.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#54

Post by KraftyOne » Fri, Oct 03, 2025, 4:04 PM UTC

atombender wrote: post #51

hmaxdml wrote: post #49

Earlier quoted context omitted.

DBOS stores all the workflow metadata in postgres, which is readily queryable for observability. We've recently seen a user setup an entire Grafana dashboard to observe their numerous workflows. A postgres server can host many databases, and multiple applications can use the same server. The same dashboard can be used to monitor them all. With respect to recovery: A new Transact process will run a round of recovery a…

Temporal has a full-fledged UI where I can drill down into individual workflow runs and see the graph of activities, detail logs, retry counts, inputs and outputs, and so on. Temporal also has an API to introspect this without reaching into a database. You can share a database server with DBOS, but it's common to give applications dedicated database resources (one Postgres cluster per app in different regions), meani…

DBOS also has a full-fledged workflow visualization and management UI: https://docs.dbos.dev/golang/tutorials/workflow-management

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#55

Post by atombender » Fri, Oct 03, 2025, 4:10 PM UTC

KraftyOne wrote: post #54

atombender wrote: post #51

Earlier quoted context omitted.

Temporal has a full-fledged UI where I can drill down into individual workflow runs and see the graph of activities, detail logs, retry counts, inputs and outputs, and so on. Temporal also has an API to introspect this without reaching into a database. You can share a database server with DBOS, but it's common to give applications dedicated database resources (one Postgres cluster per app in different regions), meani…

DBOS also has a full-fledged workflow visualization and management UI: https://docs.dbos.dev/golang/tutorials/workflow-management

Not in the open source version? It requires the commercial Conductor thing.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#56

Post by tester54321 » Fri, Oct 03, 2025, 4:16 PM UTC

hmaxdml wrote: post #2

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

Is it possible for you guys to write a blog post analyzing the usage of the DB (reads, writes, what is stored for each workflow any events etc) to help users planning for scale to really understand what they are signing up.

The library seems fantastic but my team did not use this because at scale they believe that the number of DB reads and writes becomes very significant for a large number of workflows with many steps and that with PG vs Cassandra/ScyllaDB it would not be feasible for our throughput. I tried to convince them otherwise but it is difficult to quantify from the current documentation.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#57

Post by hmaxdml » Fri, Oct 03, 2025, 5:02 PM UTC

tester54321 wrote: post #56

hmaxdml wrote: post #2

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

Is it possible for you guys to write a blog post analyzing the usage of the DB (reads, writes, what is stored for each workflow any events etc) to help users planning for scale to really understand what they are signing up. The library seems fantastic but my team did not use this because at scale they believe that the number of DB reads and writes becomes very significant for a large number of workflows with many ste…

Good call. We'll see how to integrate it in our docs better.

The cost of DBOS durable execution is 1 write per step (checkpoint the outcome) and 2 additional writes per workflows (upsert the workflow status, checkpoint the outcome). The write size is the size of your workflows/steps output.

Postgres can support several thousands writes per seconds (influenced by the write size, ofc): DBOS can thus support several thousands of workflows/steps per second.

Postgres scales remarkably well. In fact, most org will never out scale a single, vertically scaled Postgres instance. There's a very good write up by Figma telling how they scaled Postgres horizontally: https://www.figma.com/blog/how-figmas-databases-team-lived-t...

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#58

Post by plmpsu » Fri, Oct 03, 2025, 5:03 PM UTC

tester54321 wrote: post #56

hmaxdml wrote: post #2

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

Is it possible for you guys to write a blog post analyzing the usage of the DB (reads, writes, what is stored for each workflow any events etc) to help users planning for scale to really understand what they are signing up. The library seems fantastic but my team did not use this because at scale they believe that the number of DB reads and writes becomes very significant for a large number of workflows with many ste…

What did your team decide to go with eventually?

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#59

Post by reillyse » Fri, Oct 03, 2025, 6:46 PM UTC

qianli_cs wrote: post #26

reillyse wrote: post #23

Earlier quoted context omitted.

"Exactly-Once Event Processing" is the headline claim - I actually missed the workflow starting bit. So what happens if the workflow fails? Does it get restarted (and so we have twice-started) or does the entire workflow just fail ? Which is probably better described as "at-most once event processing"

I think a clearer way to think about this is "at least once" message delivery plus idempotent workflow execution is effectively exactly-once event processing. The DBOS workflow execution itself is idempotent (assume each step is idempotent). When DBOS starts a workflow, the "start" (workflow inputs) is durably logged first. If the app crashes, on restart, DBOS reloads from Postgres and resumes from the last completed…

Why would u need exactly once semantics if the workflow is idempotent?

You specifically need exactly once when the action you are doing is not idempotent.

Re: Dbos: Durable Workflow Orchestration with Go and PostgreSQL

#60

Post by anbotero » Fri, Oct 03, 2025, 11:59 PM UTC

krashidov wrote: post #22

odie5533 wrote: post #9

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

Why such negativity? What have you shipped?

I think this post is riddled with bots. One is marketing another competing offer, others complaining about the UI component not being open source too...