Our industry is full of shysters pushing their own technology. Time and again, it turns out that a RDBMS will handle that job just fine. That's really the premise of this article.

So please, go on and back up your bold statements with some specifics. Why specifically is it not OK to use a database as a message queue?

No time at the moment to break it all down, but here's a previous discussion thread on a similar topic.

https://news.ycombinator.com/item?id=27483003

Good counter-point. I see these main points over there:

1. It doesn't scale (there it is again)

2. Queuing with Postgres is super fiddly to get right

3. You're hacking a queue on top of something that isn't a queue

4. Running redis or rabbit isn't all that complicated

#1 as TFA argues, premature concern about scaling is the root of so much needless complexity. You should make scaling decisions like this: 1) assume boring tech like PG will satisfy your needs; 2) if it demonstrably does not, then find something that does.

#2 is obviously true; just look at this thread. There are battle-tested queuing libraries in most popular languages, but you do have to dig into the details of how they interact with things like pgbouncer.

#3 I guess so? But if the queue abstraction works and isn't leaky, what does it matter?

#4 can be debated. For several years I've been running a moderately complicated setup with 2 databases, redis, and kafka for several years. There's no way I'm going to add another piece of tech unless there's no other choice. The cognitive cost is too high.

The main debate is in the tradeoff between #2 and #4. Personally, if I can use an existing piece of tech to solve a problem to avoid having to ops another piece of tech, then I'm going to do that every time.

#3 applies to Redis as well - it's an in-memory KV-store and not a queue. But as TFA mentioned, it's one of the top tools used to implement queues.