5 ms·

Curious to know experience of people using DBOS and Temporal. I have used Temporal in the past, works really good, my only problem with it was some limits on

Curious to know experience of people using DBOS and Temporal. I have used Temporal in the past, works really good, my only problem with it was some limits on request payload or event sizes, created some inconveniences to us when building solutions. It also enforces good engineering practices, but sometimes you don't want to write special logic if your CSV file is larger than 2Mb, upload it to S3, pass link, then download it in the workflow. What is your experience with DBOS? How does it compare to Temporal in terms of operational complexity, feature parity and anything else

NikhilVerma 4mo ago
[flagged]
switchbak 4mo ago
They've just released an external storage approach to solve the large payload issue. I don't 100% love it (it's bolted on, not an intrinsic part), and it's an early release right now - but you can consider this effectively solved for now.
- hilariously 4mo ago
  That's good because back in the day if you were putting entire documents in a message queue I would laugh people out the door, putting something in object storage + linking is much more useful (though the distributed system part/backup current state part can be annoying!)
  - selcuka 4mo ago
    Amazon SQS has a similar (1MB per message) size limit.
  - eecc 4mo ago
    It’s an EIP, called Claim Check. https://www.enterpriseintegrationpatterns.com/patterns/messaging/StoreInLibrary.html https://www.enterpriseintegrationpatterns.com/patterns/messa...
quard8 4mo ago
we're using dbos for ai gen workflows and processing video files. understanding how to migrate from celery took time, but for our case it was worth it.
- devstein 4mo ago
  If anyone else is looking to migrate from Celery to DBOS, we also made this transition and wrote about it https://dosu.dev/blog/migrate-celery-to-dbos-dosu https://dosu.dev/blog/migrate-celery-to-dbos-dosu Very happy we made the switch.
temporal_thr123 4mo ago
I run a large on-prem temporal setup - throwaway acct as they will likely out me. Temporal is, in my opinion having run it in prod for over a year - poorly designed, slow and ridicliously heavy infra wise. If you're doing anything non-trivial (say, 200+ events/workflow) and you need to run only a couple hundred of them concurrently all day, you're going to spend millions on infra, and it's still going to absolutely suck. Try running their own benchmarks, the numbers are pathetic. Their sales team is also absolutely appalling and desperate. From a Developer standpoint, the SDK is quite nice though. Don't get trapped into nexus, and if the sales team call you make sure legal is in the room.
- temporal_thr123 4mo ago
  Since I'm in a ranting mode -- here's a good example: you're limited to _ONE_ IO per shard in the history service: https://github.com/temporalio/temporal/blob/e22e6304b3c4a409b3f5c66ab0f3385d9e610270/service/history/shard/context_impl.go#L2105 https://github.com/temporalio/temporal/blob/e22e6304b3c4a409... https://github.com/temporalio/temporal/blob/e22e6304b3c4a409b3f5c66ab0f3385d9e610270/common/dynamicconfig/constants.go#L1802 https://github.com/temporalio/temporal/blob/e22e6304b3c4a409... Temporal does a crazy amount of database operations and all of these are behind that mutex. Oh, and you can't change the shard count on existing clusters. Great stuff.
- dakiol 4mo ago
  Agree. Have worked in a codebase using Temporal, and is pretty much a nightmare. I don't know about the infra side, but from the developer side, all the abstractions they bring to the table are poorly designed. Wouldn't recommend
  - jiggunjer 4mo ago
    Biggest design bug imo is the workers need to register for the workflows they support, but will happily pull tasks from unrelated workflows if they're on the same queue. No way to put failed tasks back into the queue again either.
- Linell 4mo ago
pants2 4mo ago
I thought Temporal was overly complex, but as you said the best part is it does enforce good engineering practices. Then I tried their Cloud offering and was appalled at their pricing. I burned through the $1,000 free credits before I even got something to production. Didn't want to bother with running a local Temporal, either. Best solution is to just take inspiration from their architecture and then do it yourself in Postgres, IMO.
- selcuka 4mo ago
  That's an interesting take. You didn't want to bother with running a local Temporal, but you are happy to engineer it yourself in Postgres?
  - pants2 4mo ago
    We already have a Postgres instance running (as I'm sure most stacks have), so it's just another database table rather than a whole new piece of infrastructure that needs to be maintained, with its associated cost, attack surface, risk of Temporal going under or dropping support for OSS, authentication, and other unknowns.
jhot 4mo ago
Haven't used DBOS but use Temporal at current job and used it at previous job as well so I have about 1.5 years under me now. I also run it at home to handle some home automation tasks that aren't super time sensitive (the latency of workflows isn't super bad, but I wouldn't use one for something that is triggered by a motion event in my house unless we're talking about a timeout to turn something off after inactivity). I really like running a thin rest API in front of it inside your vpc or k8s cluster or whatever to help with event driven triggers so that they don't have to worry about Temporal auth and checking workflow status if there is any decision making around that. This helps keep your event as logic-free as possible. Let me give a vague example: you have some sort of db trigger, and this trigger either acts directly or puts the event on a queue, your handler calls the thin rest api with the necessary event details, rest API can make the decision if this starts a workflow, signals an existing one, or ignores it (the pattern for this can vary based on the situation, but SignalWithStart is common for me or just dropping if the event is not worthy of starting a workflow and no workflow for that <ItemYouCareAbout> exists). Then the parent/child workflow ability is very valuable when you need to orchestrate different self-contained behaviors for a single object's lifecycle, with cancellability when an external factor changes the trajectory of an object. Long, vague story short, I find it very powerful and easy to work with and has really helped move lifecycle logic out of APIs where things can easily become riddled with debt and precarious to manage. I agree with you that it helps follow more best-practices instead of just throwing logic some place that seems easy but becomes a hidden trap later.
halfcat 4mo ago
DBOS is much less complexity compared to Temporal. That’s the benefit. Main tradeoff is lower performance. Or at least, you’re going to be limited to what you can push through Postgres. If that’s sufficient for your needs DBOS is great.
- hmaxdml 4mo ago
  Postgres does scale pretty well: https://www.dbos.dev/blog/benchmarking-workflow-execution-scalability-on-postgres https://www.dbos.dev/blog/benchmarking-workflow-execution-sc... Tens of thousands of workflows per second

NikhilVerma 4mo ago

[flagged]

switchbak 4mo ago

They've just released an external storage approach to solve the large payload issue. I don't 100% love it (it's bolted on, not an intrinsic part), and it's an early release right now - but you can consider this effectively solved for now.

hilariously 4mo ago
That's good because back in the day if you were putting entire documents in a message queue I would laugh people out the door, putting something in object storage + linking is much more useful (though the distributed system part/backup current state part can be annoying!)
- selcuka 4mo ago
  Amazon SQS has a similar (1MB per message) size limit.
- eecc 4mo ago
  It’s an EIP, called Claim Check. https://www.enterpriseintegrationpatterns.com/patterns/messaging/StoreInLibrary.html https://www.enterpriseintegrationpatterns.com/patterns/messa...

quard8 4mo ago

we're using dbos for ai gen workflows and processing video files. understanding how to migrate from celery took time, but for our case it was worth it.

devstein 4mo ago
If anyone else is looking to migrate from Celery to DBOS, we also made this transition and wrote about it https://dosu.dev/blog/migrate-celery-to-dbos-dosu https://dosu.dev/blog/migrate-celery-to-dbos-dosu Very happy we made the switch.

temporal_thr123 4mo ago

I run a large on-prem temporal setup - throwaway acct as they will likely out me. Temporal is, in my opinion having run it in prod for over a year - poorly designed, slow and ridicliously heavy infra wise. If you're doing anything non-trivial (say, 200+ events/workflow) and you need to run only a couple hundred of them concurrently all day, you're going to spend millions on infra, and it's still going to absolutely suck. Try running their own benchmarks, the numbers are pathetic. Their sales team is also absolutely appalling and desperate. From a Developer standpoint, the SDK is quite nice though. Don't get trapped into nexus, and if the sales team call you make sure legal is in the room.

temporal_thr123 4mo ago
Since I'm in a ranting mode -- here's a good example: you're limited to _ONE_ IO per shard in the history service: https://github.com/temporalio/temporal/blob/e22e6304b3c4a409b3f5c66ab0f3385d9e610270/service/history/shard/context_impl.go#L2105 https://github.com/temporalio/temporal/blob/e22e6304b3c4a409... https://github.com/temporalio/temporal/blob/e22e6304b3c4a409b3f5c66ab0f3385d9e610270/common/dynamicconfig/constants.go#L1802 https://github.com/temporalio/temporal/blob/e22e6304b3c4a409... Temporal does a crazy amount of database operations and all of these are behind that mutex. Oh, and you can't change the shard count on existing clusters. Great stuff.
dakiol 4mo ago
Agree. Have worked in a codebase using Temporal, and is pretty much a nightmare. I don't know about the infra side, but from the developer side, all the abstractions they bring to the table are poorly designed. Wouldn't recommend
- jiggunjer 4mo ago
  Biggest design bug imo is the workers need to register for the workflows they support, but will happily pull tasks from unrelated workflows if they're on the same queue. No way to put failed tasks back into the queue again either.
Linell 4mo ago

pants2 4mo ago

I thought Temporal was overly complex, but as you said the best part is it does enforce good engineering practices. Then I tried their Cloud offering and was appalled at their pricing. I burned through the $1,000 free credits before I even got something to production. Didn't want to bother with running a local Temporal, either. Best solution is to just take inspiration from their architecture and then do it yourself in Postgres, IMO.

selcuka 4mo ago
That's an interesting take. You didn't want to bother with running a local Temporal, but you are happy to engineer it yourself in Postgres?
- pants2 4mo ago
  We already have a Postgres instance running (as I'm sure most stacks have), so it's just another database table rather than a whole new piece of infrastructure that needs to be maintained, with its associated cost, attack surface, risk of Temporal going under or dropping support for OSS, authentication, and other unknowns.

jhot 4mo ago

Haven't used DBOS but use Temporal at current job and used it at previous job as well so I have about 1.5 years under me now. I also run it at home to handle some home automation tasks that aren't super time sensitive (the latency of workflows isn't super bad, but I wouldn't use one for something that is triggered by a motion event in my house unless we're talking about a timeout to turn something off after inactivity). I really like running a thin rest API in front of it inside your vpc or k8s cluster or whatever to help with event driven triggers so that they don't have to worry about Temporal auth and checking workflow status if there is any decision making around that. This helps keep your event as logic-free as possible. Let me give a vague example: you have some sort of db trigger, and this trigger either acts directly or puts the event on a queue, your handler calls the thin rest api with the necessary event details, rest API can make the decision if this starts a workflow, signals an existing one, or ignores it (the pattern for this can vary based on the situation, but SignalWithStart is common for me or just dropping if the event is not worthy of starting a workflow and no workflow for that <ItemYouCareAbout> exists). Then the parent/child workflow ability is very valuable when you need to orchestrate different self-contained behaviors for a single object's lifecycle, with cancellability when an external factor changes the trajectory of an object. Long, vague story short, I find it very powerful and easy to work with and has really helped move lifecycle logic out of APIs where things can easily become riddled with debt and precarious to manage. I agree with you that it helps follow more best-practices instead of just throwing logic some place that seems easy but becomes a hidden trap later.

halfcat 4mo ago

DBOS is much less complexity compared to Temporal. That’s the benefit. Main tradeoff is lower performance. Or at least, you’re going to be limited to what you can push through Postgres. If that’s sufficient for your needs DBOS is great.

hmaxdml 4mo ago
Postgres does scale pretty well: https://www.dbos.dev/blog/benchmarking-workflow-execution-scalability-on-postgres https://www.dbos.dev/blog/benchmarking-workflow-execution-sc... Tens of thousands of workflows per second