Item — HN Reader

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/

[1]: https://github.com/NikolayS/pgque

8 comments

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

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? ':)

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

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.

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.

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.

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

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.

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.

Do you thank the OSS community or Claude?