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

11–20 of 58 posts

Re: Build durable workflows with Postgres

#11

Post by KraftyOne »

alpb wrote: post #8

I've been following DBOS for a while and I think the model isn't too different than Azure Durable Functions (which uses Azure Queues/Tables under the covers to maintain state). https://learn.microsoft.com/en-us/azure/azure-functions/dura... Perhaps the only difference is that Azure Durable Functions has more syntactic sugar in C# (instead of DBOS choice being Python) to preserve call results in the persistent storage…

Both do durable workflows with similar guarantees. The big difference is that DBOS is an open-source library you can add to your existing code and run anywhere, whereas Durable Functions is a cloud offering for orchestrating serverless functions on Azure.

Re: Build durable workflows with Postgres

#12

Post by KraftyOne »

abtinf wrote: post #5

Why not just use Temporal?

We wanted to make workflows more lightweight--we're building a Postgres-backed library you can add to your existing application instead of an external orchestrator that requires you to rearchitect your system around it. This post goes into more detail: https://www.dbos.dev/blog/durable-execution-coding-compariso...

Re: Build durable workflows with Postgres

#14

Post by jedberg »

tonyhb wrote: post #4

Anything that guarantees exactly once is selling snake oil. Side effects happen inside any transaction, and only when it commits (checkpoints) are the side effects safe. Want to send an email, but the app crashes before committing? Now you're at-least-once. You can compress the window that causes at-least-once semantics, but it's always there. For this reason, this blog post oversells the capabilities of these types…

> Anything that guarantees exactly once is selling snake oil.

That's a pretty spicy take. I'll agree that exactly-once is hard, but it's not impossible. Obviously there are caveats, but the beauty of DBOS using Postgres as the method of coordination instead of the an external server (like Temporal or Inngest) is that the exactly-once guarantees of Postgres can carry over to the application. Especially so if you're using that same Postgres to store your application data.

Re: Build durable workflows with Postgres

#15

Post by skrtskrt »

qianli_cs wrote: post #13
at0mic22 wrote: post #6

Every few years someone discovers FOR UPDATE SKIP LOCKED and represents it. I remember it lasting for 15 years at least

Yup, some features are timeless and deserve a re-intro every now and then. SKIP LOCKED is definitely one of them.

with a nice NOWAIT when appropriate

Re: Build durable workflows with Postgres

#16

Post by cmdtab »

Recently moved some of the background jobs from graphile worker to DBOS. Really recommend for the simplicity. Took me half an hour.

I evaluated temporal, trigger, cloudflare workflows (highly not recommended), etc and this was the easiest to implement incrementally. Didn't need to change our infrastructure at all. Just plugged the worker where I had graphile worker.

The hosted service UX and frontend can use a lot of work though but it's not necessary for someone to use. OTEL support was there.

Re: Build durable workflows with Postgres

#17

Post by cpursley »

ishita_julep wrote: post #3
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.

what are you using the DSL for?

It’s used to generate the database migration that defines the flows. More syntax sugar than anything.

Re: Build durable workflows with Postgres

#19

Post by LudwigNagasena »

cmdtab wrote: post #16

Recently moved some of the background jobs from graphile worker to DBOS. Really recommend for the simplicity. Took me half an hour. I evaluated temporal, trigger, cloudflare workflows (highly not recommended), etc and this was the easiest to implement incrementally. Didn't need to change our infrastructure at all. Just plugged the worker where I had graphile worker. The hosted service UX and frontend can use a lot of…

What was the reason for the transition?

Re: Build durable workflows with Postgres

#20

Post by alpb »

KraftyOne wrote: post #11
alpb wrote: post #8

I've been following DBOS for a while and I think the model isn't too different than Azure Durable Functions (which uses Azure Queues/Tables under the covers to maintain state). https://learn.microsoft.com/en-us/azure/azure-functions/dura... Perhaps the only difference is that Azure Durable Functions has more syntactic sugar in C# (instead of DBOS choice being Python) to preserve call results in the persistent storage…

Both do durable workflows with similar guarantees. The big difference is that DBOS is an open-source library you can add to your existing code and run anywhere, whereas Durable Functions is a cloud offering for orchestrating serverless functions on Azure.

As far as I know, Azure Durable Functions doesn't have a server-side proprietary component and it's actually fully open source framework/clients as well. So it's actually not a cloud offering per-se. You can see the full implementations at:

* https://github.com/Azure/durabletask

* https://github.com/microsoft/durabletask-go

Post reply on HN