I almost alway use Que [1] now. It uses postgres advisory locks instead of Redis so one less dependency to worry about. You probably only need Redis if you're running a tonne of jobs.
If you're already using Resque (the audience for the blog post), you're already using Redis, so Sidekiq would make more sense. Additionally, a quick glance at the syntax for a que job appears that you'd need to change more code (I could be wrong), and the available UI seems to lag Sidekiq's.
Reading this: "Que's job table undergoes a lot of churn when it is under high load, and like any heavily-written table, is susceptible to bloat and slowness if Postgres isn't able to clean it up. The most common cause of this is long-running transactions, so it's recommended to try to keep all transactions against the database housing Que's job table as short as possible." I wonder what consistutes "high load". I throw hundreds of thousands of jobs atop Sidekiq often; if you're using the same database to manage your jobs, it seems that would dogpile your database (since each of those jobs is likely making db calls, and if it's a Rails app, you're typically using the same database)
Reading this: "Que's job table undergoes a lot of churn when it is under high load, and like any heavily-written table, is susceptible to bloat and slowness if Postgres isn't able to clean it up. The most common cause of this is long-running transactions, so it's recommended to try to keep all transactions against the database housing Que's job table as short as possible." I wonder what consistutes "high load". I throw hundreds of thousands of jobs atop Sidekiq often; if you're using the same database to manage your jobs, it seems that would dogpile your database (since each of those jobs is likely making db calls, and if it's a Rails app, you're typically using the same database)