My only concern is that AI agents won’t be good at this.
For better or worse, they “understand” and have seen a lot of message queuing code and read lots of message queue support discussions.
pg_durable: Microsoft open sources in-database durable execution
91–100 of 119 posts
Re: pg_durable: Microsoft open sources in-database durable execution
#92Can anyone explain why I would want to use this over an orchestration tool that lives outside the DB? Read through the Readme and some of the examples, I still don't get it.
Contributor here. At Microsoft, our Postgres customers seem to split pretty evenly into 2 camps, those that want to do as much as they can in the database, and those that agree with your take - want to keep apps and compute outside the DB.
what do you think about using https://github.com/microsoft/duroxide with https://github.com/microsoft/duroxide-pg directly?
Re: pg_durable: Microsoft open sources in-database durable execution
#93Earlier quoted context omitted.
Yeah, it's harder to work on, or maybe just different, but I guess the docs, info(searchable docs, posts, experience), and tooling are lacking. What's the story for version control, debugging, testing, releasing? It'd be cool to have everything together for data locality and simplifying the stack, but it feels you'd lose a lot of useful knowledge about how to do stuff "properly".
Contributor here. Good points, we do need to develop some best practices around managing function versioning and lifecycle for pg_durable. https://github.com/microsoft/duroxide - also OSS, the durable execution framework pg_durable is built on itself supports function versions. We can leverage that to get similar support in pg_durable.
> Access to this repository has been disabled by GitHub Staff due to a violation of GitHub's terms of service
why is Azure/durabletask disabled? ':)
Re: pg_durable: Microsoft open sources in-database durable execution
#94Durable execution was one of my most worth investing techniques 2024, and glad to see it's blooming in 2026. The idea behind it is pretty simple: persistent state machines, auto or semi-auto context capture, and a run engine, but it actually solves many common headaches like exactly once execution with retry, signal based workflow and so on.
Re: pg_durable: Microsoft open sources in-database durable execution
#952026 is the year of the Postgres queue! (DBOS[0], pgQue[1]) It's awesome that the community is contributing this and giving us the option to use it. As an ex-app engineer though, I kind of prefer my queue logic to be in code, in Git, but maybe with the right tooling, you can change my mind. :) [0]: https://www.dbos.dev/ [1]: https://github.com/NikolayS/pgque
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.
Re: pg_durable: Microsoft open sources in-database durable execution
#96Can anyone explain why I would want to use this over an orchestration tool that lives outside the DB? Read through the Readme and some of the examples, I still don't get it.
Because you likely already have a database and likely don't need to bring on an entire new distributed system to orchestrate your workflows.
Re: pg_durable: Microsoft open sources in-database durable execution
#97Isn't the database already one of the hardest piece of infras to scale? Why would you want to load it with additional long-running jobs?
The database is exactly the hardcore piece of engineering that's been designed to scale and be fault tolerant for decades
Re: pg_durable: Microsoft open sources in-database durable execution
#982026 is the year of the Postgres queue! (DBOS[0], pgQue[1]) It's awesome that the community is contributing this and giving us the option to use it. As an ex-app engineer though, I kind of prefer my queue logic to be in code, in Git, but maybe with the right tooling, you can change my mind. :) [0]: https://www.dbos.dev/ [1]: https://github.com/NikolayS/pgque
[flagged]
Re: pg_durable: Microsoft open sources in-database durable execution
#99Earlier quoted context omitted.
Contributor here. At Microsoft, our Postgres customers seem to split pretty evenly into 2 camps, those that want to do as much as they can in the database, and those that agree with your take - want to keep apps and compute outside the DB.
I bet this is correlated with how much they like/know Postgres already. When people don’t understand their database’s features, they want it to behave like something else they do understand (code). They’re leaving a lot of performance on the table by not leveraging everything their database can do.
"When all you have is a hammer, everything looks like a nail."
But this applies to both camps.
Re: pg_durable: Microsoft open sources in-database durable execution
#100This smells like stored procedures. You can’t unit test it. You can’t version it. Business logic in the database, (hidden brain problem), harder to isolate noisy workloads, no observability, scaling pressure lands solely in Postgres, lack of IO, especially API calls. Good for local database only jobs though. Niche use cases.
> This smells like stored procedures. You can’t unit test it. You can’t version it Say what? Stored procedures are awesome when used correctly. Versioning is straightforward. You stick any sort of monotonically increasing id at the end of the name. Whenever you need a breaking change, you bump the id. You also leave the old version with the old id, retiring it only after it’s no longer used. You do need a real story…
The road to eternal burning hell is paved with stored procedures. My experiences (!!) make it so i will never be convinced on the risk:reward being worth it.