[lsh123]

1) The article claims that queues is a replacement for a database thus it solves all the problems with DB solution. In reality, if you have to have reliability and data integrity guarantees, then a messaging queue system will be using a DB under the hood (in the best case, it will be off-the-shelf DB, in the worst, something homegrown). All the same problems and considerations apply. You run into the same DB problems with the need to manually optimize queue tables, etc. because message queues rarely do a good job there. Of course, all the commit issues discussed above apply to.

2) The issue with polling is easily solved by using modern DBs (e.g. Postress with listen/notify) or just plain old triggers/stored procedures. Yes, it will be a custom solution but it will be simpler from operational perspective than a "generic" do-it-all solution.

3) Lastly, it all depends on the task. At WePay we use gearmand backed by a DB. We have seen it working really well and helping us handle 1000x spikes from normal load w/o a single problem. However, we did quite a few modifications to get there from the "stock" code to customize it to our use-case and have 200% data integrity and reliability guarantees.

[rhettg]

I understood the point as "Don't use a database as a replacement for a queue". Use the right tool for the job.

The fact that gearmand is backed by a DB is not at all the same as using a DB for a queue directly. Gearmand just uses a database as a backup that it can reload tasks when it get's restarted.

[lsh123]

Yes. However, you have same issues with DB tables receiving tons of inserts/deletes/selects. This is the worst possible DB load :)

[seunosewa]

DB's are designed for this purpose.