←back to thread

Show HN: DBOS TypeScript – Lightweight Durable Execution Built on Postgres

(github.com)
77 points KraftyOne | 2 comments | 16 Jan 25 17:10 UTC | HN request time: 0s | source

Hi HN - Peter from DBOS here with my co-founder Qian (qianl_cs)

Today we want to share our TypeScript library for lightweight durable execution. We’ve been working on it since last year and recently released v2.0 with a ton of new features and major API overhaul.

https://github.com/dbos-inc/dbos-transact-ts

Durable execution means persisting the execution state of your program while it runs, so if it is ever interrupted or crashes, it automatically resumes from where it left off.

Durable execution is useful for a lot of things:

- Orchestrating long-running or business-critical workflows so they seamlessly recover from any failure.

- Running reliable background jobs with no timeouts.

- Processing incoming events (e.g. from Kafka) exactly once

- Running a fault-tolerant distributed task queue

- Running a reliable cron scheduler

- Operating an AI agent, or anything that connects to an unreliable or non-deterministic API.

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.

One big advantage of this approach is that you can add DBOS to ANY TypeScript application–it’s just a library. For example, you can use DBOS to add reliable background jobs or cron scheduling or queues to your Next.js app with no external dependencies except Postgres.

Also, because it’s all in Postgres, you get all the tooling you’re familiar with: backups, GUIs, CLI tools–it all just works.

Want to try DBOS out? Initialize a starter app with:

    npx @dbos-inc/create -t dbos-node-starter
Then build and start your app with:

    npm install
    npm run build
    npm run start
Also check out the docs: https://docs.dbos.dev/

We'd love to hear what you think! We’ll be in the comments for the rest of the day to answer any questions you may have.

1. chatmasta ◴[16 Jan 25 19:56 UTC] No.42730086[source]▶
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).

replies(1): >>42730152 #
2. KraftyOne ◴[16 Jan 25 20:02 UTC] No.42730152[source]▶
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.