Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building durable workflows on Postgres

dbos.dev

Post reply on HN
Print view View original

121–130 of 159 posts

Re: Building durable workflows on Postgres

#121

Post by whattheheckheck »

tibbar wrote: post #107
bob1029 wrote: post #82

Earlier quoted context omitted.

Version control might not be a big deal if you are all-in on the database. Stored procedures are easiest to version by simply defining multiple variants and then incrementally moving the callers in the direction you want. The durability comes from (hopefully) your backups. Point-in-time-recovery is often easier for the business to reason about than a git repository.

Having worked for a business that made a serious go of running everything out of stored procedures, I have to say that lack of version control was a huge problem and effectively limited all development to a single person who held all the rules in their head.

Can you not have a repo with conventional commits wired to do cicd for deployment?

Re: Building durable workflows on Postgres

#122

Post by whattheheckheck »

vrm wrote: post #6

Since DBOS doesn't support Rust, we implemented a very minimal Rust version of this at https://github.com/tensorzero/durable . It has been quite stable and extensible but of course you need to be very careful with the SQL implementations. Hope this is interesting to readers here.

Soon this will be open-source

https://flawless.dev/

Re: Building durable workflows on Postgres

#123

Post by banditelol »

For some interesting alternative for postgres as queue (actually more like kafka log), I like what pgque does https://github.com/NikolayS/pgque rather than using select for updates and other semantic, it uses snapshot and table truncate to reduce bloat. I havent used it for my dayjob but the different approach is refreshing to see and interesting for different system trade off.

Re: Building durable workflows on Postgres

#124

Post by mikert89 »

temporal_thr321 wrote: post #88
quacker wrote: post #83

Earlier quoted context omitted.

Honest question: Can you use Temporal Cloud? Have you evaluated Temporal Cloud pricing? Ballparking: 200 events/workflow, 200 workflows/per day and assuming 1 event = 1 cloud action[1], that is 1.2M or so actions per month. The $100/month plan includes 1M actions each month, and even the pay-as-you pricing when you exceed that is $50 per 1M actions[2]. Temporal Cloud seems extremely cheap for your use case, even if I…

I was not clear; I did not mean not 200 a day, it's 10s of thousands of concurrently running workflows, sometimes into the hundreds of thousands, each with 200 events. We run many hundreds of thousands of these a day. Temporal was a bad fit for us, and we regret it deeply.

what would you use instead?

Re: Building durable workflows on Postgres

#125

Post by rossjudson »

This is an excellent pattern; do as much as you can in the database.

External Spanner provides changes streams. Internal spanner is different, mostly because of the extreme scaling requirements in some cases (and a healthy dose of "because it already works" mixed with "arbitrary change streams are scary").

Internal Spanner allows any transaction to write queue entries, where queues are (more or less) tables with some special time awareness. You can schedule delivery. Entries get pushed from queues to a handler which can also do writes to the DB within the dequeue transaction. And all of the same scaling is there.

Re: Building durable workflows on Postgres

#126

Post by selcuka »

pants2 wrote: post #35
throwaw12 wrote: post #4

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

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…

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?

Re: Building durable workflows on Postgres

#127

Post by selcuka »

hilariously wrote: post #13
switchbak wrote: post #7

Earlier quoted context omitted.

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.

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

Amazon SQS has a similar (1MB per message) size limit.

Re: Building durable workflows on Postgres

#128

Post by rjbwork »

stuartaxelowen wrote: post #40

My dream is, instead of separating data storage, state machines, valid state constraints, and the logic that transitions between valid states, we can actually unify these into some kernel of app state. Honestly, Postgres already has a lot of these capabilities, but I don’t see an obvious story on the app or product level, providing provably correct sets of states that apps can transition between, and which they can a…

Temporal.io comes kind of close to this with the ability to do queries, signals, and updates. I'm not sure it's a full unification though.

Re: Building durable workflows on Postgres

#129

Post by pants2 »

selcuka wrote: post #126
pants2 wrote: post #35

Earlier quoted context omitted.

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…

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?

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.

Re: Building durable workflows on Postgres

#130

Post by rcv »

whattheheckheck wrote: post #121
tibbar wrote: post #107

Earlier quoted context omitted.

Having worked for a business that made a serious go of running everything out of stored procedures, I have to say that lack of version control was a huge problem and effectively limited all development to a single person who held all the rules in their head.

Can you not have a repo with conventional commits wired to do cicd for deployment?

This is essentially what we do. All of our stored procedures, views, etc are kept in *_api schemas. Those schemas just get fully dropped and reinstalled whenever we migrate. It works really well, and has basically zero cognitive load overhead for developers.
Post reply on HN