[igortg]

Any known issue on implementing a queue with Postgres? Do you at least know it has a pretty good pub/sub mechanism?

[mmcclure]

Postgres is having a moment with excellent queueing libraries right now, not sure what GP is referring to. We use Oban[1] at Mux for some workloads and love it, and a former colleague just built something similar in Go that was on the front page yesterday (River)[2].

[1] https://github.com/sorentwo/oban

[2] https://github.com/riverqueue/river

[0xbadcafebee]

Connection limits, locking issues, concurrency issues, multiple consumer/producer issues, dead-letter, record expiration, performance limits, scalability limits, lack of gateway, lack of interoperable standards, tightly-coupled applications, general architectural limits.

Can you "work around" all that? Sure, it's technically possible (well actually it's not possible to solve all of the above, but most of it). Just like it's also possible to take a mini-van and convert it into a hot rod, so it can pick up groceries after it's entered in a drag race. It will just cost you a lot of extra time and money, and do both jobs poorly.

It's NIH syndrome plain and simple. Hipster nerds who want to invent something for fun, rather than using something off the shelf. People decrying "complexity", who then poorly implement complexity themselves, in the form of functionality shoved into a system not built for it. Software architecture by HN meme.

[otabdeveloper4]

By "queue" they mean here a table with the columns (job_id, job_status, update_time).

You could store that in a text file, there aren't really any serious requirements.