Sidekiq vs Solid Queue

Where this comparison comes from

Sidekiq, released by Mike Perham in 2012, became the dominant Ruby background-job library within two years. It used threads inside one process backed by Redis, processed tens of thousands of jobs per second on modest hardware, and shipped a clean web UI for inspecting queues, retries, and dead jobs. For a decade, "background jobs in Rails" meant Sidekiq.

Solid Queue arrived with Rails 8 in September 2024, written at 37signals for HEY. It is database-backed (Postgres, MySQL, or SQLite), removes the Redis dependency, and ships as the default queue adapter in new Rails 8 apps. The framing across the team has been clear: Solid Queue is the new default for most apps, Sidekiq remains the right call for the high-throughput cases.

Both tools work. The question is not which one is better in the abstract but which one fits the workload you actually have. The rest of this lesson walks through the six axes that matter and the verdict on each.

Axis 1: throughput

Sidekiq processes around 8,000 to 10,000 simple jobs per second on a single worker process on modern hardware. That number drops with job complexity (database queries, external calls, payload size) but Redis itself is rarely the bottleneck. Sidekiq Pro and Enterprise add features (batches, rate limiting, encryption) without changing the per-second ceiling much.

Solid Queue's ceiling is closer to 1,000 to 2,000 jobs per second per worker, limited by the cost of database polling and row locking. The number is fine for most Rails apps. A typical web product processes 50 to 500 jobs per second in steady state, with spikes to a few thousand. Solid Queue handles that range without breaking a sweat.

Verdict. Below ~5,000 jobs/sec, Solid Queue is comfortable. Above ~5,000 jobs/sec, Sidekiq's architecture pays back. Most apps will never reach that threshold.

Axis 2: infrastructure cost

Sidekiq requires Redis. On Heroku, that is a Redis add-on at $15 to $200+/month depending on size. On Fly.io or Render, it is a managed Redis instance or a self-hosted Redis container. Either way, it is a second database to monitor, alert on, back up, and reason about during incidents.

Solid Queue runs against your existing Postgres. No new infrastructure, no new credentials, no new incident surface. The cost is some additional load on the Postgres primary: Solid Queue polls for new jobs and updates rows on state transitions. For most apps this is rounding error compared to OLTP traffic; for very high-throughput apps it can become a measurable share of database CPU.

Verdict. If you do not already need Redis for caching or rate limiting, Solid Queue saves a piece of infrastructure. If you already run Redis for other reasons, the marginal cost of adding Sidekiq is small.

Axis 3: transactional integrity

This is where Solid Queue's database-backed design wins decisively. Because jobs are rows in the same database as your app data, enqueueing a job inside a transaction is atomic with the transaction. If the transaction rolls back, the job is not in the queue. If it commits, the job is guaranteed enqueued.

# With Solid Queue: atomic
ApplicationRecord.transaction do
  order = Order.create!(params)
  ChargeOrderJob.perform_later(order.id)  # Same DB transaction
  # If this transaction rolls back, the job is gone too.
end

# With Sidekiq: not atomic
ApplicationRecord.transaction do
  order = Order.create!(params)
  ChargeOrderJob.perform_later(order.id)  # Writes to Redis immediately
  raise "something else fails"            # Order rolls back...
  # ...but the job was already enqueued and will run, finding no order.
end

The Sidekiq community has worked around this with the after_commit callback pattern, where jobs are enqueued only after the transaction commits. The pattern works but adds a layer of careful discipline. Forget the wrapper in one place and you get phantom jobs.

Verdict. If your jobs need to be transactionally consistent with database writes (payments, state machines, ordering-sensitive flows), Solid Queue is the right choice. Sidekiq can do it, but requires discipline you have to enforce yourself.

Axis 4: ecosystem and observability

Sidekiq's web UI has been the gold standard for a decade. Queue inspection, retry counts, scheduled jobs, dead jobs with full stack traces, batch progress, real-time stats. Most Rails teams who use Sidekiq have a bookmarked URL they open during incidents and know exactly what they are looking at.

Sidekiq's plugin ecosystem extends beyond the UI: sidekiq-cron, sidekiq-unique-jobs, sidekiq-status, integrations with every observability tool. The community has solved most operational corner cases.

Solid Queue is younger and the ecosystem is thinner. The 37signals team ships Mission Control as a sibling gem for a queue-management UI, and it has improved fast through 2024 and 2025. The UI is good now, although not as feature-rich as Sidekiq Web. Integrations with observability platforms are catching up.

Verdict. Sidekiq still leads on UI maturity and plugin breadth. Solid Queue is good enough for most teams in 2026 and the gap is closing.

Axis 5: retries and failure handling

Both tools have retry semantics built on Active Job. retry_on and discard_on work identically. Sidekiq adds its own retry block syntax for finer control; Solid Queue is mostly Active Job-native.

Sidekiq's dead-jobs queue is a separate Redis sorted set. Failed jobs accumulate, you can inspect them, retry them, or delete them. The semantics are well-understood after a decade of teams using them.

Solid Queue's failed jobs are rows in the solid_queue_failed_executions table. Mission Control exposes them. The model is simpler than Sidekiq's retry stack but covers the common needs (inspect, retry, delete).

Verdict. Roughly equivalent for typical Rails-app retry needs. Sidekiq has more knobs if your retry logic is intricate.

Axis 6: cost of being wrong

Both tools sit behind Active Job, so application code (SomeJob.perform_later(...)) looks identical. Migrating from one to the other is mostly an infrastructure swap plus reconfiguring the adapter in config/application.rb. The application-level cost is near zero.

The migration cost lives in operations: standing up the new infrastructure, dual-writing during cutover, monitoring both queues until you trust the new one. A team that picks Solid Queue and outgrows it can swap to Sidekiq in a sprint. A team that picks Sidekiq and decides to simplify can swap to Solid Queue in a sprint.

Verdict. The decision is not load-bearing. Pick the one that fits your current shape; revisit if the shape changes.

The decision rule

Default to Solid Queue if:

• You are starting a new Rails 8 app. It is the default, and the friction of swapping is for a future problem.
• You do not already need Redis for caching or rate limiting.
• Job count is under ~5,000/sec in normal operation.
• Transactional integrity with the database is important (payments, state machines).

Default to Sidekiq if:

• You already run Redis and the team knows it.
• Job throughput exceeds 5,000/sec sustained, or you have spiky workloads where database pressure during job dequeue would compete with OLTP traffic.
• The team has years of Sidekiq operational experience and the plugins it relies on (sidekiq-unique-jobs, batch APIs, custom middleware) do not have direct Solid Queue equivalents.

For an app sitting in the middle, both work. Many production Rails apps in 2026 are migrating to Solid Queue not because Sidekiq is failing them but because removing Redis simplifies their infrastructure. Both are valid moves.

The principle at play

Tooling decisions are not identity. The teams that get the most out of either tool are the ones who picked it for clear reasons and would switch when the reasons changed. The reasons that matter: throughput, transactional integrity, infrastructure cost, ecosystem maturity. Most apps cluster cleanly on one side or the other once those four are evaluated.

The reason Solid Queue exists is that 37signals concluded most of the apps they ship would rather not run Redis. The reason Sidekiq still thrives is that some workloads still benefit from its architecture. Both reasons are legitimate, and the choice in your app is about which side of the line you sit on, not which tool is fashionable this year.