The workers have to poll Postgres repeatedly at intervals, whereas a worker using a message broker (like RabbitMQ) connects and just waits for something to get tossed its way. Having your task broker separate from your database can save a lot of DB IO if you've got a larger number of workers or a busy task queue. RabbitMQ (and the other more full-featured message brokers) can also do a lot of really slick things with routing, prioritization, and all sorts of other goodies.

Of course, this doesn't matter if you're running a small site with low traffic. I wouldn't get too caught up in worrying about broker selection unless you're cranking out a lot of jobs, or have special needs.

So if I am reading this right, what you are saying is that RabbitMQ is more 'push' and a DB is more 'pull' or rather 'poll'.

Perhaps they should break the brokers down into those two groups.

I seem to recall Redis having a pubsub style interface, which makes it much more push but still is a bit cloudy in my mind.

Thanks for the reply!

If you are asking for postgres as a celeryd backend, it's not really what this dbms is meant to do... Redis is easy to install, run and manage (as long as you don't lean out of the window too much), so for celeryd it's preferable...

Right, but "it's not what this was meant to do" is the kind of vague non-answer that the parent was talking about.