3 ms·

2026 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-a

by levkk 4mo ago

2026 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/ https://www.dbos.dev/ [1]: https://github.com/NikolayS/pgque https://github.com/NikolayS/pgque

dietr1ch 4mo ago
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".
- gdecandia 4mo ago
  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 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.
  - vault 4mo ago
    > 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? ':)
babhishek21 4mo ago
+1 on "prefer my queue logic to be in code". The <shape> of my data doesn't change nearly as much as the actions I need to take on it; it doesn't make sense to me why I'd want to do a migration (which is an all or nothing op btw) every time I want to change how I behave with my data. This is also why I absolutely abhorred having to make postgres functions to do anything remotely non-trivial on Supabase. That said, we did hand-build a simple job queue (just lock, poll, reserve on a column, poll and update reservation to mark job done) on top of postgres at my previous startup. Something like pgque would have made that much more polished.
moomoo11 4mo ago
same but this could be useful for db level things that are not business logic related. i have always had maintenance packages for this type of stuff. if i could deploy them alongside the database itself that could be kind of cool. but yeah i agree with you that i do prefer having this in the code layer.
giancarlostoro 4mo ago
> 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. :) I mean, we used to keep our SQL code in git too for projects where we had DB triggers. I think some were even shoved in there via Django migrations just to let someone setup locally and have the triggers available in their local database.
- jrumbut 4mo ago
  If you have triggers I don't see why you wouldn't put them in a migration. That addresses one of the most problematic aspects of triggers (invisibility, no version tracking, etc) without reducing their usefulness. With some cleverness you could even introduce some testing that way. Not perfect but better than nothing.
- SoftTalker 4mo ago
  I've never heard of not source controlling stored procedures, functions, triggers, etc. I source-control all my schema objects, never imagined this isn't normal.
CuriouslyC 4mo ago
You're not wrong, I've been a big postgres fanboy since version 7, and have tried to build stuff in PG to the greatest degree possible in experiments, and my experience is that at a minimum, the DX/observability isn't there. The multi-master scaling story isn't turnkey or bulletproof either, so I'm hesitant to do any fancy write-bound things that hasten the need to scale the database.
tmpz22 4mo ago
Do you thank the OSS community or Claude?
gitscope_ai 4mo ago
[flagged]
nextaccountic 4mo ago
I like pgmq https://github.com/pgmq/pgmq https://github.com/pgmq/pgmq
hmaxdml 4mo ago
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.
hanzeweiasa 4mo ago
[flagged]
KaiShips 4mo ago
[flagged]

by levkk 4mo ago

dietr1ch 4mo ago

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".

gdecandia 4mo ago
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 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.
- vault 4mo ago
  > 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? ':)

babhishek21 4mo ago

+1 on "prefer my queue logic to be in code". The <shape> of my data doesn't change nearly as much as the actions I need to take on it; it doesn't make sense to me why I'd want to do a migration (which is an all or nothing op btw) every time I want to change how I behave with my data. This is also why I absolutely abhorred having to make postgres functions to do anything remotely non-trivial on Supabase. That said, we did hand-build a simple job queue (just lock, poll, reserve on a column, poll and update reservation to mark job done) on top of postgres at my previous startup. Something like pgque would have made that much more polished.

moomoo11 4mo ago

same but this could be useful for db level things that are not business logic related. i have always had maintenance packages for this type of stuff. if i could deploy them alongside the database itself that could be kind of cool. but yeah i agree with you that i do prefer having this in the code layer.

giancarlostoro 4mo ago

> 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. :) I mean, we used to keep our SQL code in git too for projects where we had DB triggers. I think some were even shoved in there via Django migrations just to let someone setup locally and have the triggers available in their local database.

jrumbut 4mo ago
If you have triggers I don't see why you wouldn't put them in a migration. That addresses one of the most problematic aspects of triggers (invisibility, no version tracking, etc) without reducing their usefulness. With some cleverness you could even introduce some testing that way. Not perfect but better than nothing.
SoftTalker 4mo ago
I've never heard of not source controlling stored procedures, functions, triggers, etc. I source-control all my schema objects, never imagined this isn't normal.

CuriouslyC 4mo ago

You're not wrong, I've been a big postgres fanboy since version 7, and have tried to build stuff in PG to the greatest degree possible in experiments, and my experience is that at a minimum, the DX/observability isn't there. The multi-master scaling story isn't turnkey or bulletproof either, so I'm hesitant to do any fancy write-bound things that hasten the need to scale the database.

tmpz22 4mo ago

Do you thank the OSS community or Claude?

gitscope_ai 4mo ago

[flagged]

nextaccountic 4mo ago

I like pgmq https://github.com/pgmq/pgmq https://github.com/pgmq/pgmq

hmaxdml 4mo ago

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.

hanzeweiasa 4mo ago

[flagged]

KaiShips 4mo ago

[flagged]