[icebraining]

With a traditional database this typically means a service that is constantly querying for new processing tasks or messages.

Traditionally, but not necessarily; PostgreSQL supports the LISTEN and NOTIFY commands for asynchronous notifications, without polling.

[nesquena]

I agree and if polling was the only consideration then this would mitigate the issue. Admittedly I didn't cover this as much in my article but there's also a lot of other flexibility afforded by a good message queue around delivery strategies, consumption strategies, error handling, etc that you would have to do much more manually and painfully trying to shoehorn it into a database (even a good one). I am not saying PostgreSQL notify commands are not useful for certain tasks, just encouraging people to understand the tools available and pick the right one for the job.

[lvh]

Also, Axiom, my favorite little Python object layer over SQLite, has native scheduler support. Whenever loading a store (well, starting the store's scheduler service), all things-to-happen are scheduled to run using Twisted's event loop. And, well, event loops are very good at efficiently waiting for things to be done in the future :)

[joevandyk]

queue_classic is a postgresql job queue that can use listen/notify. http://www.postgresql.org/docs/9.1/static/sql-notify.html

Although queue_classic doesn't use listen/notify by default, and I'm not sure why. I think it should, it seems to perform better.