Hacker News

That's definitely worth considering! The core algorithms can work with any data store. That said, we're focused on Postgres right now because of its incredible support and popularity.

Also this reminds me of orthogonal persistence https://wiki.c2.com/?TransparentPersistence

Did you do literature research of Smalltalk?

Hi there, I think I might have found a typo in your example class in the github README. In the class's `workflow` method, shouldn't we be `await`-ing those steps?

Can you change the workflow code for a running workflow that already advanced some steps? What support DBOS have for workflow evolution?

I know this this might sound scripted or can be considered cliche but what is the use case for DBOS.

How do you persist execution state? Does it hook into the Python interpreter to capture referenced variables/data structures etc, so they are available when the state needs to be restored?

About workflow recovery: if I'm running multiple instance of my app that uses DBOS and they all crash, how do you divide the work of retrying pending workflows?

Hai, really cool project! This is something I can actually use.

FYI the “Build Crashproof Apps” button in your docs doesn’t do anything.

That's a really good question! Because DBOS is backed by Postgres, it scales as well as Postgres does, so 10K+ steps per second with a large database server. That's good for most workloads. Past that, you can split your workload into multiple services or shard it. Past that, you've probably outscaled any Postgres-based solution (very few services need this scale).

The big advantages of using Postgres are:

1. Simpler architecturally, as there are no external dependencies.

2. You have complete control over your execution state, as it's all on tables on your Postgres server (docs for those tables: https://docs.dbos.dev/explanations/system-tables#system-tabl...)

Yes, if your workflow interacts with multiple external systems and you need it to fully back out and clean up after itself after a step fails, you'll need backup steps--this is basically a saga pattern.

Where DBOS helps is in ensuring the entire workflow, including all backup steps, always run. So if your service is interrupted and that causes the Stripe call to fail, upon restart your program will automatically retry the Stripe call and if that doesn't work, back out and run the step that closes out the failed purchase.

Generally we recommend against retroaction--the assumed model is that every workflow finishes on the code version it started. This is managed automatically in our hosted version (DBOS Cloud) and there's an API for self-hosting: https://docs.dbos.dev/typescript/tutorials/development/self-...

That said, we know sometimes you have to do surgery on a long-running workflow, and we're looking at adding better tooling for it. It's completely doable because all the state is stored in Postgres tables (https://docs.dbos.dev/explanations/system-tables).

Got it! What specifically are you looking for? If you launch multiple DBOS instances connected to the same Postgres database, they'll automatically form a distributed task queue, dividing new work as it arrives on the queue. If you're looking for a lightweight deployment environment, we also have a hosted solution (DBOS Cloud).

Great question! A workflow should be deterministic: if called multiple times with the same inputs, it should invoke the same steps with the same inputs in the same order. But steps don't have be deterministic, they can invoke LLMs, third party APIs, or any other operation. Docs page on determinism: https://docs.dbos.dev/typescript/tutorials/workflow-tutorial...

In addition to TypeORM, DBOS supports several popular ORMs:

- Drizzle (we're also a sponsor to Drizzle): https://docs.dbos.dev/typescript/tutorials/orms/using-drizzl...

- Knex: https://docs.dbos.dev/typescript/tutorials/orms/using-knex

- Prisma: https://docs.dbos.dev/typescript/tutorials/orms/using-prisma

More ORM support is on the way.

The state can be stored in any Postgres instance, either locally or in any cloud.

For code, here's the bare minimum code example for a workflow:

  class Example {
    @DBOS.step()
    static async step_one() {
      ...
    }

    @DBOS.step()
    static async step_two() {
      ...
    }

    @DBOS.workflow()
    static async workflow() {
      await Example.step_one()
      await Example.step_two()
    }
  }

Then we have a bunch more examples in our docs: https://docs.dbos.dev/.

Or if you want to try it yourself download a template:

    npx @dbos-inc/create