DBOS Co-founder here. Great question! The big difference is that DBOS runs as a library inside your program, whereas the Temporal architecture is an external workflow server managing tasks on distributed workers. The advantages of DBOS are:
1. Simpler architecturally. Just a normal Python process versus a workflow server coordinating multiple workers.
2. Easier dev/debugging. A Temporal program is essentially distributed microservices, with control flow split between the workflow server and workers. That complicates any testing/debugging because you have to work through multiple components. Whereas DBOS is just your process.
3. Performance. A state transition in DBOS requires only a database write (~1 ms) whereas in Temporal it requires an async dispatch from the workflow server (tens-hundreds of ms).
Note that it is possible to embed temporal server into a program. I wrote a simple demo that embeds client/worker/server all into one Go app. It should be straightforward to modify this to support clustering.
Having my app with direct write access to the scheduling backend could be... problematic from the separation of concerns. We'll have to deal with connection pooling etc and we typically prefer to separate DB logic (interaction with postgres) from application logic.
Ignoring my setup, I'm a bit confused from the website if I can run this as a library? Seems that I need to use your SaaS backend to get started? Or did I misunderstand the flow from my quick flow?
And yes, you can absolutely run this locally as a library! The bottom half of the quickstart covers how to do it: https://docs.dbos.dev/explanations/system-tables Just use a local (or Docker) Postgres.
How does workflow orchestration work across multiple running processes of my application? Say I have 3 processes, and process-1 that has initiated a workflow crashes. How and where does this workflow resume?
All processes use Postgres as a reference, so they can learn about pending workflows in need of recovery. The DBOS library handles concurrency management under the hood, such that only 1 process can work on a workflow at a given time.
DBOS Co-founder here. Great question! The big difference is that DBOS runs as a library inside your program, whereas the Temporal architecture is an external workflow server managing tasks on distributed workers. The advantages of DBOS are:
1. Simpler architecturally. Just a normal Python process versus a workflow server coordinating multiple workers.
2. Easier dev/debugging. A Temporal program is essentially distributed microservices, with control flow split between the workflow server and workers. That complicates any testing/debugging because you have to work through multiple components. Whereas DBOS is just your process.
3. Performance. A state transition in DBOS requires only a database write (~1 ms) whereas in Temporal it requires an async dispatch from the workflow server (tens-hundreds of ms).
Note that it is possible to embed temporal server into a program. I wrote a simple demo that embeds client/worker/server all into one Go app. It should be straightforward to modify this to support clustering.
https://github.com/abtinf/temporal-a-day/blob/main/001-all-i...
Having my app with direct write access to the scheduling backend could be... problematic from the separation of concerns. We'll have to deal with connection pooling etc and we typically prefer to separate DB logic (interaction with postgres) from application logic.
Ignoring my setup, I'm a bit confused from the website if I can run this as a library? Seems that I need to use your SaaS backend to get started? Or did I misunderstand the flow from my quick flow?
For separation of concerns/isolation, DBOS does all its bookkeeping in a separate Postgres database from your app database (documented here: https://docs.dbos.dev/explanations/system-tables).
And yes, you can absolutely run this locally as a library! The bottom half of the quickstart covers how to do it: https://docs.dbos.dev/explanations/system-tables Just use a local (or Docker) Postgres.
How does workflow orchestration work across multiple running processes of my application? Say I have 3 processes, and process-1 that has initiated a workflow crashes. How and where does this workflow resume?
All processes use Postgres as a reference, so they can learn about pending workflows in need of recovery. The DBOS library handles concurrency management under the hood, such that only 1 process can work on a workflow at a given time.
Seems like you didn't read any of it