A DBOS blog post titled "Postgres is all you need for durable execution" reached the Hacker News front page this week (306 points, 132 comments). The thread split the way these threads always do. One half read it as relief: no more standing up a separate workflow service only to make a multi-step job survive a crash. The other half read it as a warning: you are about to put orchestration load on the same database that already runs your app. Both reactions are correct, and which one applies to you depends on a question the headline skips.
I run a site that compares developer tools, so I read a lot of "X vs Y." Durable execution is one of the categories where the architecture choice matters far more than the brand on the box. Here is the grounded version, checked against DBOS's own docs, an independent write-up from Supabase, and the source libraries themselves.
What durable execution solves
Picture a function that runs five steps and crashes on step four. Steps one through three already happened, step four half-happened, and a naive retry runs all five again. If step two charged a customer, you charged them twice. Durable execution fixes this with checkpointing. Each step records its result before the next one starts, so a crash-and-restart resumes from the last completed step instead of the top. The promise is that a workflow finishes exactly once even if the machine running it dies in the middle. Payment capture, order fulfillment, any multi-step process where a double-run costs real money is the use case that makes this worth the effort.
