Hacker News: hmaxdml

New comment by hmaxdml in "pg_durable: Microsoft open sources in-database durable execution"

hmaxdml — Sat, 06 Jun 2026 11:53:53 +0000

The database is exactly the hardcore piece of engineering that's been designed to scale and be fault tolerant for decades

New comment by hmaxdml in "pg_durable: Microsoft open sources in-database durable execution"

hmaxdml — Sat, 06 Jun 2026 11:52:01 +0000

Because you likely already have a database and likely don't need to bring on an entire new distributed system to orchestrate your workflows.

New comment by hmaxdml in "pg_durable: Microsoft open sources in-database durable execution"

hmaxdml — Sat, 06 Jun 2026 11:43:59 +0000

A PG-backed queue is in code right after being in PG, and the beauty of a neat durable queue framework is in exposing it conveniently and efficiently.

New comment by hmaxdml in "Building durable workflows on Postgres"

hmaxdml — Tue, 02 Jun 2026 16:23:20 +0000

Postgres does scale pretty well: https://www.dbos.dev/blog/benchmarking-workflow-execution-sc...

Tens of thousands of workflows per second

New comment by hmaxdml in "SQLite is all you need for durable workflows"

hmaxdml — Sat, 30 May 2026 20:54:42 +0000

That's why their entire business model -- like Astronomer's -- is geared toward cloud hosting. The architecture is so complex it takes a full time team to run it.

New comment by hmaxdml in "SQLite is all you need for durable workflows"

hmaxdml — Sat, 30 May 2026 20:51:42 +0000

Have you looked into DBOS? Same thesis: durable and reliable workflows are hard to manage -- it just doesn't have to be as hard as Temporal makes it be :)

New comment by hmaxdml in "Building durable workflows on Postgres"

hmaxdml — Fri, 29 May 2026 22:18:07 +0000

DBOS python supports SQLite. Go is supporting it next release

New comment by hmaxdml in "Building durable workflows on Postgres"

hmaxdml — Thu, 28 May 2026 23:07:06 +0000

I've talked to dozens of engineers who built their home grown "durable" stack. Most of them eventually moved on to buying vs building, when their system actually scaled. It's just not a side-hustle to build a foundational reliability layer.

New comment by hmaxdml in "Building durable workflows on Postgres"

hmaxdml — Thu, 28 May 2026 23:03:40 +0000

Yeah, we've observed that too: people start implementing their own retry logic, idempotency, etc. But then they grow a hard to maintain, complex stack that's not their core business logic. There's a reason why there is a dedicated team building DBOS, every day. Because it's not that easy to build a solid durable workflows engine on Postgres.

New comment by hmaxdml in "Building durable workflows on Postgres"

hmaxdml — Thu, 28 May 2026 19:46:39 +0000

Listen/notify is poised to become much better in PG 18 and 19

New comment by hmaxdml in "Building durable workflows on Postgres"

hmaxdml — Thu, 28 May 2026 19:35:25 +0000

As you said, the example is simple and it might not be obvious to people without prod experience what the problems can be. Postgres can give you all the primitives you need to solve this at the application layer. Durable workflows on Postgres is an effective way to access these primitives.

New comment by hmaxdml in "Agents need control flow, not more prompts"

hmaxdml — Thu, 07 May 2026 19:54:29 +0000

We've found that durable workflows is a much needed primitive for agents control flow. They give a structure for deterministic replays, observability, and, of course, fault tolerance, that operators need to make the agent loop reliable.

Stonebraker on Postgres, Disagreeing with Google, and Future Problems [video]

hmaxdml — Thu, 23 Apr 2026 23:13:35 +0000

Article URL: https://www.youtube.com/watch?v=YPObBOwIrHk

Comments URL: https://news.ycombinator.com/item?id=47883452

Points: 1

# Comments: 0

New comment by hmaxdml in "Go-Native Durable Execution"

hmaxdml — Tue, 03 Mar 2026 17:19:26 +0000

Automatic crash detection for your process is built-in our Conductor offering. The library has a default recovery mode when used standalone.

What do you find strange with workflow versioning? Would love to consider improving the semantics. In fact, we started doing it: https://github.com/dbos-inc/dbos-transact-py/pull/598

New comment by hmaxdml in "Go-Native Durable Execution"

hmaxdml — Tue, 03 Mar 2026 02:26:00 +0000

I notice you didn't provide any specific comparison alongside that comment, which makes me feel frustrated because I think the Temporal workflow SDK is very different. Architecturally, Temporal and DBOS are at two opposites of the durable execution spectrum. I'd love to understand what makes you think this work is a mere copy and paste. Would you be willing to share some more with me?

New comment by hmaxdml in "Go-Native Durable Execution"

hmaxdml — Mon, 02 Mar 2026 17:26:24 +0000

Thanks for the comment (author here). I wanted this post to focus on the Golang specific implementation, not dwell on the durable execution ecosystem at large.

With respect to context, I don't know that anyone invented "having their own context". Go interface are extendable and pretty much every major framework I know of implement their own context.

Would love to learn more about the gaps that offset you. We're constantly improving here ;)

New comment by hmaxdml in "Go-Native Durable Execution"

hmaxdml — Mon, 02 Mar 2026 17:25:11 +0000

Conductor is about enterprise features like automatic workflow recovery, alerting, or RBAC. The GUI is a nice to have -- but all your workflow data are in Postgres. You can access it very easily.

Go-Native Durable Execution

hmaxdml — Thu, 26 Feb 2026 00:17:52 +0000

Article URL: https://www.dbos.dev/blog/how-we-built-golang-native-durable-execution

Comments URL: https://news.ycombinator.com/item?id=47160065

Points: 56

# Comments: 19

New comment by hmaxdml in "Designing a Passively Safe API"

hmaxdml — Sat, 31 Jan 2026 17:00:12 +0000

Durable execution has already been mentioned as the existing solution for this problem, but I would like to call out a specific pattern that DE makes obsolete: the outbox pattern. Imagine just being able to do do

send a() send b()

And know both will be sent at least once, without having to introduce an outbox and re-architect your code to use a message relay. We can nitpick the details, but being able to "just write normal code" and get strong guarantees is, imo, real progress.

New comment by hmaxdml in "Designing a Passively Safe API"

hmaxdml — Sat, 31 Jan 2026 16:55:23 +0000

These are all important concerns, but I'd go for an off the shelf library that does it for me (disclaimer I work at https://github.com/dbos-inc)