27 ms·

Good questions! DBOS naturally scales to distributed environments, with many processes/servers per application and many applications running together. The key

Good questions! DBOS naturally scales to distributed environments, with many processes/servers per application and many applications running together. The key idea is to use the database concurrency control to coordinate multiple processes. [1] When a DBOS workflow starts, it’s tagged with the version of the application process that launched it. This way, you can safely change workflow code without breaking existing ones. They'll continue running on the older version. As a result, rolling updates become easy and safe. [2] [1] https://docs.dbos.dev/architecture#using-dbos-in-a-distributed-setting https://docs.dbos.dev/architecture#using-dbos-in-a-distribut... [2] https://docs.dbos.dev/architecture#application-and-workflow-versions https://docs.dbos.dev/architecture#application-and-workflow-...

plmpsu 1y ago
Thanks for the reply. So applications continuously poll the database for work? Have you done any benchmarking to evaluate the throughput of DBOS when running many workflows, activities, etc.?
- qianli_cs 1y ago
  In DBOS, workflows can be invoked directly as normal function calls or enqueued. Direct calls don't require any polling. For queued workflows, each process runs a lightweight polling thread that checks for new work using `SELECT ... FOR UPDATE SKIP LOCKED` with exponential backoffs to prevent contentions, so many concurrent workers can poll efficiently. We recently wrote a blog post on durable workflows, queues, and optimizations: https://www.dbos.dev/blog/why-postgres-durable-execution https://www.dbos.dev/blog/why-postgres-durable-execution Throughput mainly comes down to database writes: executing a workflow = 2 writes (input + output), each step = 1 write. A single Postgres instance can typically handle thousands of writes per second, and a larger one can handle tens of thousands (or even more, depending on your workload size). If you need more capacity, you can shard your app across multiple Postgres servers.
  - odie5533 1y ago
    Even though I don't use DBOS, that blog post is gold.

plmpsu 1y ago

Thanks for the reply. So applications continuously poll the database for work? Have you done any benchmarking to evaluate the throughput of DBOS when running many workflows, activities, etc.?

qianli_cs 1y ago
In DBOS, workflows can be invoked directly as normal function calls or enqueued. Direct calls don't require any polling. For queued workflows, each process runs a lightweight polling thread that checks for new work using `SELECT ... FOR UPDATE SKIP LOCKED` with exponential backoffs to prevent contentions, so many concurrent workers can poll efficiently. We recently wrote a blog post on durable workflows, queues, and optimizations: https://www.dbos.dev/blog/why-postgres-durable-execution https://www.dbos.dev/blog/why-postgres-durable-execution Throughput mainly comes down to database writes: executing a workflow = 2 writes (input + output), each step = 1 write. A single Postgres instance can typically handle thousands of writes per second, and a larger one can handle tens of thousands (or even more, depending on your workload size). If you need more capacity, you can shard your app across multiple Postgres servers.
- odie5533 1y ago
  Even though I don't use DBOS, that blog post is gold.