Loved the Supabase coverage from a month ago, showing under the hood what DBOS is storing & how the data flow works on it. It made real what DBOS was for me, clicked; before DBOS felt very abstract to me.

https://supabase.com/blog/durable-workflows-in-postgres-dbos https://news.ycombinator.com/item?id=42379974

Could you genericise the requirement in postgresql and provide a storage interface we could plug into? I think I have a use for this in Polykey (https://GitHub.com/MatrixAI/Polykey) but we use rocksdb (transactional key value embedded db).

Hello! I'm a co-founder at DBOS here and I'm happy to answer any questions :)

> What’s unique about DBOS’s take on durable execution (compared to, say, Temporal) is that it’s implemented in a lightweight library that’s totally backed by Postgres. All you have to do to use DBOS is “npm install” it and annotate your program with decorators. The decorators store your program’s execution state in Postgres as it runs and recover it if it crashes. There are no other dependencies you have to manage, no separate workflow server–just your program and Postgres.

this is good until you the postgres server fills up with load and need to scale up/fan out work to a bunch of workers? how do you handle that?

(disclosure, former temporal employee, but also no hate meant, i'm all for making more good orcehstration choices)

Do you consider ”durability” to include idempotency? How can you guarantee that without requiring the developer to specify a (verifiable) rollback procedure for each “step?” If Step 1 inserts a new purchase into my local DB, and Step 2 calls the Stripe API to “create a new purchase,” what if Step 2 fails (even after retries, eg maybe my code is using the wrong URL or Stripe banned me)? Maybe you haven’t “committed” the transaction yet, but I’ve got a row in my database saying a purchase exists. Should something clean this up? Is it my responsibility to make sure that row includes something like a “transaction ID” provided by DBOS?

It just seems that the “durability” guarantees get less reliable as you add more dependencies on external systems. Or at least, the reliability is subject to the interpretation of whichever application code interacts with the result of these workflows (e.g. the shipping service must know to ignore rows in the local purchase DB if they’re not linked to a committed DBOS transaction).

Interesting idea. It seems like zodb (https://zodb.org) might enable some similar things for python - by simply being an object database?

Is it possible to mix typescript and python steps?

What are the limits on Retroaction? Can Retroactive changes revise history?

For example, if I change the code / transactions in a step, how do you reconcile what state to prepare for which transactions. For example, you'll need to reconcile deleted and duplicated calls to the DB?

I see the example for running a distributed task queue. The docs aren't so clear though for running a distributed workflow, apart from the comment about using a vm id and the admin API.

We use spot instances for most things to keep costs down and job queues to link steps. Can you provide an example of a distributed workflow setup?

What is the determinism constraint? I noticed it mentioned several times in blog posts, but one of the use-cases mentioned here is for use with LLMs, which produce non-deterministic outputs.

Why typeorm over something like https://mikro-orm.io/?

Where is the state stored? In my own pg instance? Or is it stored somewhere in the cloud? Also, a small sample code snippet would be helpful.

Is there a way to use it without decorators?

nice work