Background jobs in Rails: Solid Queue, Sidekiq, GoodJob and older options
Sending email, resizing images, calling slow APIs: anything that should not happen during a web request belongs in a background job. Rails provides the interface; the backend that actually stores and runs jobs is your choice.
Release figures are from RubyGems.org, October 2026.
Active Job: the common interface
Since Rails 4.2, Active Job has provided a standard API for declaring and enqueuing jobs:
class ReceiptJob < ApplicationJob
queue_as :mailers
retry_on Net::OpenTimeout, wait: :polynomially_longer, attempts: 5
def perform(order)
OrderMailer.receipt(order).deliver_now
end
end
ReceiptJob.perform_later(order)
Arguments such as order are serialised with GlobalID, so the job receives a fresh record from the database rather than a stale copy. Retries, discards, callbacks and scheduling (set(wait: 10.minutes)) are part of the framework. The Active Job Basics guide documents the API and the list of adapters.
Writing jobs against Active Job keeps you free to change backends later. Some backends also offer a native API with extra features; using it ties your code to that backend, which can be worth it.
Solid Queue
Solid Queue (1.7.0, August 2026) is the default Active Job backend for new Rails 8 applications. It stores jobs in a relational database (PostgreSQL, MySQL or SQLite) and relies on FOR UPDATE SKIP LOCKED where the database supports it, so several workers can poll the same tables without blocking one another. It supports delayed jobs, recurring tasks declared in config/recurring.yml, concurrency limits per job, queue priorities and pausing queues.
The Rails 8 default configuration keeps the queue in a separate database, and Solid Queue can run inside the Puma process through a plugin, which is convenient for small deployments with a single server. The Mission Control – Jobs engine adds a web dashboard for inspecting, retrying and discarding jobs.
Choose it when you want no extra infrastructure: no Redis, one less service to monitor. Its throughput is lower than a Redis-based system, but more than enough for most applications.
Sidekiq
Sidekiq (8.1.7, August 2026) runs jobs in threads inside a long-lived process and stores them in Redis or a Redis-compatible server. It has been the performance reference for Ruby background processing for over a decade and has a mature web UI, extensive middleware and a large ecosystem of extensions.
The open-source edition is licensed under LGPL-3.0. Sidekiq Pro and Sidekiq Enterprise are commercial editions that add features such as batches, more reliable fetching, rate limiting, unique jobs and periodic jobs; check the project's own feature comparison for the current split.
Because Sidekiq is multi-threaded, your job code and the gems it calls must be thread-safe, which was far from guaranteed for gems of the Rails 2 era. Today most popular gems are thread-safe, since Puma has made threaded Rails servers the norm.
Choose it when you process large volumes of jobs, already run Redis, or need its commercial features.
GoodJob
GoodJob (4.22.1, October 2026) is a PostgreSQL-only backend built for Active Job. It uses advisory locks to claim jobs and LISTEN/NOTIFY to wake workers immediately, and includes a dashboard engine, cron-style recurring jobs, batches and concurrency controls. It can run in a separate process or asynchronously inside the web server process.
Choose it when you are committed to PostgreSQL and want a database-backed queue with a long track record and rich features. Applications that adopted GoodJob before Solid Queue existed have little reason to switch.
delayed_job and Resque
delayed_job stores jobs in a database table and dates back to the Rails 2 era; it is still released (4.2.0, December 2025) and widely deployed. Resque uses Redis and forks a child process per job, which isolates memory leaks at the cost of speed; it too is still released (3.2.0, October 2026). Both are reasonable to keep in an existing application. For a new one, Solid Queue covers delayed_job's niche and Sidekiq covers most of Resque's.
What happened to Workling, Spawn and BackgrounDRb
Before Active Job, Rails 2 applications used a variety of plugins. Workling provided a common interface over several queue servers (Starling, RabbitMQ and others), an idea that Active Job later standardised; its last gem release is from December 2010. Spawn let a controller fork a process or start a thread to finish slow work after the response; it was popular for its simplicity, and it is the kind of solution a proper queue replaced, because forked work vanished when the process died and could not be retried. BackgrounDRb ran workers over DRb. None of these is maintained, and none should be used today.
Practical advice, whichever backend you choose
- Make jobs idempotent. Every backend can run a job twice: after a crash, a deploy or a retry. Design
performso that running it again does no harm. - Pass identifiers, not big objects. GlobalID handles records; for everything else, pass small, serialisable values.
- Mind transactions. A job enqueued inside a database transaction can start before the transaction commits and fail to find its record. Recent Rails versions have settings for enqueueing after commit; check the Active Job guide for the behaviour of your version and backend.
- Monitor queue latency, not only failures. A queue that is growing is an outage in slow motion.
- Separate queues by urgency so that a flood of low-priority work does not delay password-reset emails.
Calls to rate-limited external services are a classic use. In the comparison of geocoding gems for a Rails apartment search, addresses are geocoded in a job on a single-worker queue to respect the provider's one-request-per-second limit, and slow file processing follows the same pattern with your file upload library of choice.
Summary
| Backend | Storage | Notes |
|---|---|---|
| Solid Queue | PostgreSQL, MySQL, SQLite | Rails 8 default; Mission Control dashboard |
| Sidekiq | Redis-compatible | Highest throughput; commercial editions |
| GoodJob | PostgreSQL | Built-in dashboard, cron, batches |
| delayed_job | Database | Long-lived, still released |
| Resque | Redis | Forks per job; still released |
Category guidesFile uploads
Choosing a file attachment solution for Rails: Active Storage, Shrine and CarrierWave compared, image variants with image_processing, validation, and migrating away from Paperclip.
Category guidesTesting
The Rails testing toolbox in 2026: Minitest or RSpec, fixtures or FactoryBot, system tests with Capybara, shoulda-matchers, and what replaced Webrat, Spork and factory_girl.
Plugin historiesSpork
What Spork did for RSpec and Cucumber in the Rails 2 and 3 era, why it stopped at 1.0.0rc4, and how Spring, Bootsnap and parallel testing solve the same problem today.