3 ms·

I've been looking into this space since I learned about Temporal recently, and I wonder if it would be better to have this integrated in my application, as a li

I've been looking into this space since I learned about Temporal recently, and I wonder if it would be better to have this integrated in my application, as a library, instead of an external dependency. This way, all the state would be in the same DB.

darwin67 2y ago
it depends on your load really. there are background job frameworks in other languages like Oban in Elixir that utilizes postgres. if scale is low, it's not an issue. but once you have high usage, what typically people do is they move it to a separate database, otherwise you're saturating the resources and it starts impacting the application itself. at that point, that's not much different from external state stored else where. also another thing about databases is their ACID transactions can only handle up to certain amount of load. again, if you don't hit that limit, it's totally fine. once you do, which usually means outages, severe delays, etc, and it'll be a shit show. disclaimer: I do work at Inngest, but also this is speaking from experience. :)
secondrow 2y ago
If your application is Python or TS based, you can check out the DBOS libraries, which do that.
- giovannibonetti 2y ago
  No, they don't. They work just like Temporal and the others, which send the durable state to a separate store. I totally understand that this is good for the tool business model, since many users will end up paying for the separate store, instead of keeping it in the same DB where the application already is, without needing to pay extra for it. After all, the amount of data for keeping that state should be relativly small, so no one would provision a separate DB for it if the SDK didn't force them to.
  - qianli_cs 2y ago
    Hello! DBOS co-founder here. We actually use your app’s database (Postgres) as the state store.
    - giovannibonetti 2y ago
      My bad, I had misunderstood that. You're right, and thank you for sharing it. That is a great differentiator. I see you have Python and JS/TS libraries, but my team is working with Go right now, so I'll have to pass. However, I'll keep it on my radar. Being able to handle wrap DB commands in the same transactions as the workflow store is awesome! [2] [2] https://docs.dbos.dev/python/tutorials/transaction-tutorial https://docs.dbos.dev/python/tutorials/transaction-tutorial

darwin67 2y ago

it depends on your load really. there are background job frameworks in other languages like Oban in Elixir that utilizes postgres. if scale is low, it's not an issue. but once you have high usage, what typically people do is they move it to a separate database, otherwise you're saturating the resources and it starts impacting the application itself. at that point, that's not much different from external state stored else where. also another thing about databases is their ACID transactions can only handle up to certain amount of load. again, if you don't hit that limit, it's totally fine. once you do, which usually means outages, severe delays, etc, and it'll be a shit show. disclaimer: I do work at Inngest, but also this is speaking from experience. :)

secondrow 2y ago

If your application is Python or TS based, you can check out the DBOS libraries, which do that.

giovannibonetti 2y ago
No, they don't. They work just like Temporal and the others, which send the durable state to a separate store. I totally understand that this is good for the tool business model, since many users will end up paying for the separate store, instead of keeping it in the same DB where the application already is, without needing to pay extra for it. After all, the amount of data for keeping that state should be relativly small, so no one would provision a separate DB for it if the SDK didn't force them to.
- qianli_cs 2y ago
  Hello! DBOS co-founder here. We actually use your app’s database (Postgres) as the state store.
  - giovannibonetti 2y ago
    My bad, I had misunderstood that. You're right, and thank you for sharing it. That is a great differentiator. I see you have Python and JS/TS libraries, but my team is working with Go right now, so I'll have to pass. However, I'll keep it on my radar. Being able to handle wrap DB commands in the same transactions as the workflow store is awesome! [2] [2] https://docs.dbos.dev/python/tutorials/transaction-tutorial https://docs.dbos.dev/python/tutorials/transaction-tutorial