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

Build durable workflows with Postgres

dbos.dev

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Build durable workflows with Postgres

#51

Post by cpursley »

mmcclure wrote: post #31
cpursley wrote: post #2

I've been using https://www.pgflow.dev for workflows which is built on pgmq and am really impressed so far. Most of the logic is in the database so I'm considering building an Elixir adapter DSL.

Just curious, if you’re already in Elixir and using Postgres, why not use Oban[1]? It’s my absolute favorite background job library, and the thing I often miss most when working in other ecosystems. [1] https://github.com/oban-bg/oban

Oban is awesome, but I really like the ideas around pgmq and most of the logic living in the database. And the idea of "flows" design from pgflow for multi-step processes (which Elixir is naturally a great match for)

Re: Build durable workflows with Postgres

#52

Post by jscheel »

mnahkies wrote: post #48
jumploops wrote: post #29

I've been looking at migrating to Temporal, but this looks interesting. For context, we have a simple (read: home-built) "durable" worker setup that uses BullMQ for scheduling/queueing, but all of the actual jobs are Postgres-based. Due to the cron-nature of the many disparate jobs (bespoke AI-native workflows), we have workers that scale up/down basically on the hour, every hour. Temporal is the obvious solution, bu…

As another commentator said, temporal is quite tricky to self host/scale in a cost effective manner. This is also reflected in their cloud pricing (which should've been the warning sign to us tbh) Overall it's a pretty heavy/expensive solution and I've come to the conclusion it's usage is best limited to lower frequency and/or higher "value" (eg: revenue or risk) tasks. Orchestrating a food delivery that's paying you…

This was my problem with Dagster, too. All the documentation and all the examples encourage you to split items into small discrete tasks. Then you realize that their cloud pricing is absolutely bonkers if you go over the paltry 30k credits… unless you sign up for a meaty annual enterprise contract. Got a $500 bill for something like 13k executions over the limit. That’s less than 45k executions in a month. Just for comparison, our main product’s sidekiq queue processes tens of millions of jobs every single day. Just a silly imbalance. I ended up having to combine a bunch of tasks to the point that I started asking myself why I was even bothering with using it at all.

Re: Build durable workflows with Postgres

#53

Post by jedberg »

hanikesn wrote: post #50
KraftyOne wrote: post #36

Earlier quoted context omitted.

Like Inngest and Restate, DBOS provides durable workflows. The difference is that DBOS is implemented as a Postgres-backed library you can "npm install" into your project (no external dependencies except Postgres), while Inngest and Restate require an external workflow orchestrator. Here's a blog post explaining the DBOS architecture in more detail: https://www.dbos.dev/blog/what-is-lightweight-durable-execut... Here…

First: It's great to have some serious competition in the durable execution market! You build some impressive tech already! It took me a decent time to investigate before pulling the trigger on temporal at my current PSP fintech as you'll end up with a pretty hard vendor lock-in which has to be worth it. I have to say the architecture blog post is very leightweight on details, which makes it hard to judge so you have…

Hey there, DBOS CEO here. I really appreciate your feedback, super helpful! If you are willing, I'd love to get some more feedback from you, specifically around your showstoppers. I have contact info in my HN profile, or you can join our discord: https://discord.com/invite/jsmC6pXGgX

Thanks!

Re: Build durable workflows with Postgres

#55

Post by bogantech »

cyberpunk wrote: post #44
jumploops wrote: post #29

I've been looking at migrating to Temporal, but this looks interesting. For context, we have a simple (read: home-built) "durable" worker setup that uses BullMQ for scheduling/queueing, but all of the actual jobs are Postgres-based. Due to the cron-nature of the many disparate jobs (bespoke AI-native workflows), we have workers that scale up/down basically on the hour, every hour. Temporal is the obvious solution, bu…

Unless you’re planning on using their (temporalio’s) saas you’re in for building a very large database cluster for this if you need some scale. (source: i run way more cassandra than i ever thought reasonable)

Just got roped into setting up an on prem temporal cluster myself :(

What causes the need for massive database clusters? Now I'm worried this is going to fall apart on us in a very big way

Re: Build durable workflows with Postgres

#56

Post by Shorn »

cmdtab wrote: post #49
johtso wrote: post #34

Earlier quoted context omitted.

Why would you not recommend Cloudflare workflows? Was thinking of using them in my current project..

They inherit all the limitations of DO. For example, if you want to do anything that requires more than 6 TCP connection. Every fetch request will start failing silently because there is no more TCP connection to go through. This was a deal breaker for us. Their solution was split our code into more workflows or DOs. You are limited to 128 MB ram which means everything has to be steamed. You will rewrite your code ar…

That is valuable, info dense comment. Thanks.

Re: Build durable workflows with Postgres

#57

Post by cyberpunk »

bogantech wrote: post #55
cyberpunk wrote: post #44

Earlier quoted context omitted.

Unless you’re planning on using their (temporalio’s) saas you’re in for building a very large database cluster for this if you need some scale. (source: i run way more cassandra than i ever thought reasonable)

Just got roped into setting up an on prem temporal cluster myself :( What causes the need for massive database clusters? Now I'm worried this is going to fall apart on us in a very big way

Take a look at the official “basic scaling” guide especially the metric about state transitions / second.

To get an idea of what you’ll need that metric to be try running 1/10th of your workload as a benchmark against it.

In order for our particular setup to handle barely 5000 of these we have almost 100cpus just for cassandra. To double this, it’s 200 cpus just for database.

Oh and make sure you get your history shard count right as you can’t change it without rebuilding it.

Maybe it makes sense for low volume high value jobs e.g uber trips, for high volume low value this doesn’t work economically.

We are likely to drop it.

Re: Build durable workflows with Postgres

#58

Post by secondrow »

yencabulator wrote: post #54

It's so weird that they went from "operating system with all OS state in a database" on VoltDB to "yet another Typescript framework using Postgres" with the same name. https://dbos-project.github.io/

lol - don't overlook DBOS Cloud, a serverless compute platform, which also originated from the DBOS R&D project(s) at MIT/Stanford.
Post reply on HN