What do you find strange with workflow versioning? Would love to consider improving the semantics. In fact, we started doing it: https://github.com/dbos-inc/dbos-transact-py/pull/598

With respect to context, I don't know that anyone invented "having their own context". Go interface are extendable and pretty much every major framework I know of implement their own context.

Would love to learn more about the gaps that offset you. We're constantly improving here ;)

Comments URL: https://news.ycombinator.com/item?id=47160065

Points: 56

# Comments: 19

send a() send b()

And know both will be sent at least once, without having to introduce an outbox and re-architect your code to use a message relay. We can nitpick the details, but being able to "just write normal code" and get strong guarantees is, imo, real progress.

Comments URL: https://news.ycombinator.com/item?id=46693952

Points: 2

# Comments: 0

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

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 at startup. Transact also exposes an admin server with a recovery endpoint.

For more elaborate scenarios, we have control plane options commercially available.

"since Golang doesn't have decorators in the same way Python does, we still have to have code doing the kind of "manual callback" style I mentioned"

That's exactly right, specifically for steps. We considered other ways to wrap the workflow calls (so you don't have to do dbos.RunWorkflow(yourFunction)), but they got in the way of providing compile time type checking.

As Qian said, under the hood the Golang SDK is an embedded orchestration package that just requires Postgres to automate state management.

For example, check the RunWorkflow implementation: https://github.com/dbos-inc/dbos-transact-golang/blob/0afae2...

It does all the durability logic in-line with your code and doesn't rely on an external service.

Thanks for taking the time to share your insights! This was one of the most interesting HN comment I've seen in a while :)

Comments URL: https://news.ycombinator.com/item?id=43638148

Points: 22

# Comments: 5

Your workers too can import the library and have embedded orchestration.

In process durable execution gives you freedom for a lot longer than having to hire Airflow or Temporal. You just need postgres (which you likely already have)