Sidekiq vs SolidQueue vs GoodJob in 2026

The Rails background job landscape settled into three real options: Sidekiq, Solid Queue, and GoodJob. Each is mature, each is shipped in production at scale by serious teams, and each makes a different bet about what you should optimize for.

I’ve shipped all three. Here’s how I’d pick today.

At a glance

	Sidekiq	Solid Queue	GoodJob
Backing store	Redis	Postgres / MySQL / SQLite	Postgres
Throughput ceiling	Highest of the three	Mid (DB-bound)	Mid (DB-bound)
Recurring jobs	Yes (Sidekiq Pro/Ent for cron, free w/ sidekiq-cron)	Yes, built-in	Yes, built-in
Job batches	Pro/Enterprise feature	No native batches	No native batches
Concurrency controls	Pro/Enterprise (unique, throttle)	Built-in	Built-in (advisory locks)
Dashboard	Sidekiq Web (free), Pro adds more	Mission Control Jobs	GoodJob’s /good_job
Operational footprint	Extra service (Redis) + worker process	Just a worker process (DB you already have)	Just a worker process (DB you already have)
License	LGPL (OSS) + commercial Pro/Ent	MIT	MIT
Default in Rails	No	Yes (Rails 8)	No

I haven’t run head-to-head benchmarks recently, so I’ll soften the throughput claim: Sidekiq’s Redis-backed model is widely understood to push more jobs per second on the same hardware than DB-backed alternatives, but for the vast majority of apps (low thousands of jobs/minute, not jobs/second), all three are fast enough that throughput isn’t the deciding factor.

Sidekiq

The veteran. Mike Perham has been refining it for over a decade and the polish shows: the dashboard is the best of the three, the failure handling is battle-tested, and the Enterprise tier (paid) bolts on the features serious shops eventually need — unique jobs, rate limits, batches, expiring jobs, leader election.

What you get with the free version: solid throughput, retries with backoff, scheduled jobs, the Web UI, and a thriving ecosystem of plugins.

What costs money: cron-style recurring jobs (or you bolt on sidekiq-cron, which is fine), batches (the killer feature for fan-out workflows), and unique-job constraints.

The operational cost: Redis. You need it running, monitored, and sized correctly. Memory pressure on Redis is its own skill. If your Redis falls over, your jobs stop processing — which is true of any queue system, but Redis has its own failure modes (forks during BGSAVE, OOM killer, replication lag in clusters) that you have to learn.

Sidekiq is the right answer when:

• You’re processing thousands of jobs per second sustained.
• You already run Redis and operate it well.
• You need batches or other Pro/Enterprise features and the budget is fine.
• You have an ops team that wants the most-instrumented, best-documented option.

Solid Queue

The new default. Shipped with Rails 8, written by 37signals for HEY, designed to make “no Redis required” a real production posture.

What it gets right: the operational story is genuinely simpler. Your jobs live in your database, your worker process is a standard Rails process, your monitoring uses your existing database tooling. Recurring jobs and concurrency controls are first-class, no plugins.

The dashboard story is via Mission Control Jobs, a separate gem. It’s competent but not as feature-rich as Sidekiq Web yet. It’s catching up.

The throughput story: I haven’t benchmarked Solid Queue against Sidekiq myself, and I’d encourage skepticism toward anyone making strong claims either way without numbers. The reasoning from first principles: a database INSERT+SELECT cycle is more expensive than a Redis LPUSH+BRPOP, so per-job overhead is higher. Whether that matters for your workload depends on how many jobs you push and how much each one does. For an app pushing 10/sec where each job takes 500ms, the queue overhead is noise. For an app pushing 5000/sec where each job takes 10ms, it’s the dominant cost.

Solid Queue is the right answer when:

• You’re starting a new app and want to ship without provisioning Redis.
• Your job volume is in the low-to-mid thousands per minute, not per second.
• You’re already a Postgres/MySQL shop and want fewer moving parts.
• You’re on Rails 8 and the defaults align with your stack choices anyway.

GoodJob

Postgres-only by design (it leans hard on Postgres-specific features) and arguably the most thoughtful design of the three for Postgres-first apps. Ben Sheldon has been building it since 2020 and the design choices reflect deep care: it uses Postgres LISTEN/NOTIFY for low-latency job pickup (no polling), advisory locks for unique jobs and concurrency controls, and the result is a system that feels native to Postgres in a way Solid Queue doesn’t quite match.

What you get: recurring jobs (cron), concurrency controls via advisory locks, a dashboard at /good_job with retry, discard, and reschedule actions, multiple execution modes (inline, async, external), and the ability to run jobs in a thread within the Puma process for low-volume apps that don’t want a separate worker.

The throughput story is similar to Solid Queue (DB-bound) with the added detail that LISTEN/NOTIFY keeps pickup latency very low, often sub-100ms. Polling-based queues add latency equal to half the polling interval; GoodJob mostly avoids that.

Where GoodJob shines that Solid Queue doesn’t quite: the concurrency control story is more mature (it predates Solid Queue’s by years), and the in-process execution mode is genuinely useful for small apps that want background jobs without standing up a worker container.

GoodJob is the right answer when:

• You’re Postgres-only and want a queue designed for Postgres.
• You want concurrency controls and unique jobs without paying for Sidekiq Pro.
• Your app is small enough that running jobs in-process is acceptable, and you want that option later.
• You want low pickup latency without tuning poll intervals.

How I’d actually pick

For a new app today, the decision tree:

Sustained throughput above ~1000 jobs/sec, or you need batches? Sidekiq. Pay for Pro/Enterprise if the features earn it. The throughput headroom and operational maturity are worth the Redis dependency.

New Rails 8 app, no existing queue, no Redis? Solid Queue. The defaults are good, the operational simplification is real, and you can migrate to Sidekiq later if throughput becomes the bottleneck (it probably won’t).

Postgres-only shop, want concurrency controls, want a single backend you can reason about? GoodJob. The design choices are coherent and the Postgres-native feel is hard to beat.

Existing app already running Sidekiq? Stay on Sidekiq unless something specific pushes you off. The migration cost is real and “Solid Queue is the new default” is not a sufficient reason on its own.

What I’d skip

DelayedJob. It still works, it’s still maintained, and it’s still wrong in 2026 for any new project. The polling model and the unstructured payload column have been surpassed by all three options above. If you’re maintaining a DelayedJob app, plan a migration to whichever of the three fits — but don’t pick it for greenfield.

Resque. Same logic. It was the right answer in 2012. Sidekiq replaced it for Redis-backed work and never looked back.

What changed since 2024

Two things. Solid Queue stabilized enough to be the Rails 8 default, which is a meaningful credibility signal. And GoodJob added enough features (and gained enough adoption) that “use Sidekiq because everything else is immature” stopped being a defensible default for Postgres apps.

The honest summary: in 2026, the three-way choice is a real choice. Each tool fits a different shape of team and app. The wrong move is picking one based on what was conventional five years ago without checking whether the constraints have changed.

For most new Rails apps I’d start today: Solid Queue. The defaults are aligned, the operational story is clean, and if it doesn’t work out the migration to Sidekiq is straightforward (Active Job abstracts most of the surface area). For most existing apps already on Sidekiq: stay there. Migrations cost more than people remember, and “the queue works” is a feature.