zlacker

>>anonu+(OP)
Strong disagree on using a database as a message queue. This article[0] covers many of the reasons why. Summary: additional application complexity and doesn't scale well with workers.

0. https://www.cloudamqp.com/blog/why-is-a-database-not-the-rig...

EDIT>> I am not suggesting people build their own rabbitmq infrastructure. Use a cloud service. The article is informational only.

>>daenz+X9
Basically all of those reasons are solved by using LISTEN/NOTIFY and FOR UPDATE SKIP LOCKED, which every queue built on pg will use.

>>SahAss+wm
>all of those reasons are solved

How does it solve the additional code complexity problem?

>>daenz+8s
Which complexity? Of running a SQL query on the same database you're already using, vs writing code to support some other new system?

>>KptMar+Lu
>Of running a SQL query on the same database you're already using

Go back and read OPs link. They create new SQL types, tables, triggers, and functions, with non-trivial and very unforgiving atomic logic. And every system that needs to read or write from this "db queue" needs to leverage specific queries. That's the complexity.

>vs writing code to support some other new system

You mean using a stable well maintained library with a clean and sensible interface to a queueing system? Yes, that is far more simple.

>>daenz+Yv
Not necessarily. Many languages like Java already have queuing libraries that operate on rdbms through JPA. So not even a single additional line needs to be written for this to work. We got ours working in a day and it works great. I don't know if other languages have these libraries but I'm inclined to believe they do (at least nodejs has).

>>option+RG
Do you have to set up the triggers, tables, and procedures beforehand or how does that work?

>>daenz+ZH
The libraries create their own tables, triggers etc during initialization.