GoodJob, Solid Queue, Sidekiq, Active Job, in 2026
16 points by soulcutter
16 points by soulcutter
Beyond connection limits, the biggest downside I see of using a DB for your queue is that often people push off work to a queue because some other part of the app is slow and an extremely common problem rails apps hit is high database load (I talk more here about that metric https://schneems.com/2017/07/18/how-i-reduced-my-db-server-load-by-80/). Adding a bunch of extra writes and reads for the queue logic would increase load.
A solution to that DB load would be to provision a different database for your queue and your app data, though this conflicts with a common motivation of using the DB as a queue which is cheaper hosting costs (if you don't need to provision 2 things).
Last thing to mention is transaction semantics. I know some backends that relied on the semantics they got from delayed job by accident and those assumptions are so thoroughly baked into every line of code in a very load bearing project, so it will likely never be able to migrate to a different backend if they wanted. If you start with a Redis queue, moving to a database queue is easy, but not always the other way around.
Overall good write up. Or should I say GoodJob with the write up.
Redis is also easier to host than a database in my experience. The idea that it’s onerous to have two things instead of one breaks down when you take into account how complex it can be to have “just one” when they are sharing disparate workloads.
“So the takeaway here is that today in 2026 there are a small number of really, really good Active Job backends to choose from, and the most important consideration is that you make friends along the way.“
Great takeaway! Seems like a good approach to lots of things in life.
If you are worried about performance at all with Sidekiq, we've knocked over other people's APIs with it, so ¯\_(ツ)_/¯