Live data from Hacker News

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

github.com

41–50 of 51 posts

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

#41
post #29

> 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,…

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…

Unaffiliated with DBOS but I agree that Postgres will scale much further than most startups will ever need! Even Meta still runs MySQL under the hood (albeit with a very thick layer of custom ORM).

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

#42

Earlier quoted context omitted.

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

You'll need to click either the Python or TypeScript icon. We support both languages and will add more icons there.

Thanks the icons work!

I was originally looking at the docs to see if there was any information on multi-instance (horizontally scaled) apps. Is this supported? If so, how does that work?

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

#43

Earlier quoted context omitted.

You'll need to click either the Python or TypeScript icon. We support both languages and will add more icons there.

Thanks the icons work! I was originally looking at the docs to see if there was any information on multi-instance (horizontally scaled) apps. Is this supported? If so, how does that work?

Yeah, DBOS Cloud automatically (horizontally) scales your apps. For self-hosting, you can spin up multiple instances and connect them to the same Postgres database. For fan-out patterns, you may leverage DBOS Queues. This works because DBOS uses Postgres for coordination, rate limiting, and concurrency control. For example, you can enqueue tasks that are processed by multiple instances; DBOS makes sure that each task is dequeued by one instance.

Docs for Queues and Parallelism: https://docs.dbos.dev/typescript/tutorials/queue-tutorial

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

#45
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?

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

#46
post #45

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?

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

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

#48
post #29

> 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,…

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…

yeah its not really about steps per second, its about if steps have heavy processing workload each, eg you dont want to clog up your postgres with a bunch of media processing or basically literally anything long running, which is the point of a separate workflow engine

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

#49

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

Hi! How does it perform under heavy load and with thousands of workflows trying to run concurrently since it relies on Postgres for a lot of things (including using a transaction)? In the end it seems that if I have an application with lots of distributed workers trying to run workflows, I'll still be limited by the CPU/memory of the DB.

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

#50
post #48

Earlier quoted context omitted.

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…

yeah its not really about steps per second, its about if steps have heavy processing workload each, eg you dont want to clog up your postgres with a bunch of media processing or basically literally anything long running, which is the point of a separate workflow engine

I don't think the processing happens in postgres at all, it's just handling the transactions and queues.
Post reply on HN