Sidekiq vs Solid Queue in 2026: when to switch and when not to.

A founder messaged me last week asking whether they should rip Sidekiq out of a six-month-old Rails app and move to Solid Queue, because they’d read on Hacker News that Rails 8 made the switch official. I gave them the answer I give most people who ask: maybe, but probably not yet, and definitely not for the reason you’re thinking. The reason you’d switch is not “Redis is bad” and not “Basecamp ships it now.” The reason is operational, and most apps don’t have the operational pressure that makes the move worth the disruption. This post is the decision rubric I use when a client asks. It is opinionated, it is short on case studies on purpose, and it ends with one falsifiable claim about where the line sits.

What we’re actually comparing

Sidekiq is a Redis-backed background job processor for Ruby, first released by Mike Perham in 2012. It runs jobs in threads inside a separate process and stores queues, retries, and scheduled jobs in Redis. The OSS tier is free; Pro and Enterprise are paid and add features like unique jobs, batches, and rolling restarts.

Solid Queue is a database-backed job runner extracted from HEY and shipped by 37signals. It became the Rails 8 default in late 2024 alongside Solid Cache and Solid Cable. It uses your relational database — Postgres, MySQL, or SQLite — as the durable store and runs workers as separate processes that poll the jobs tables.

Both speak the Active Job interface, so MyJob.perform_later works on either adapter. The choice is not about API surface. It is about what runs in production, what fails at 3am, and how much of your monthly bill is infrastructure you don’t strictly need.

The rubric I actually use

The decision compresses to four questions. I run them in order and stop at the first one that gives a hard answer.

The first question is the one most people skip. If you have a working Sidekiq setup and Redis is already a managed dependency you trust, switching to Solid Queue is migration work for an aesthetic preference. The bill on a small Redis instance is in the single-digit dollars per month on most managed providers. That is not a forcing function.

The second question is where Sidekiq’s architecture earns its keep. Threads inside a single process, in-memory queue state in Redis, no row-level locking against your primary database. For job volumes typical of B2B SaaS — webhooks, email sends, scheduled reports — Solid Queue handles it without breathing hard. For high-frequency event ingestion or background analytics fan-out, Sidekiq still has headroom that DB-backed runners don’t.

The third question is the one that traps teams already on Sidekiq Pro. Batches with completion callbacks, unique jobs across the cluster, the reliability fetcher — these are not yet 1:1 in Solid Queue. You can rebuild some of them. You will spend a week doing it. Budget the week or stay.

The fourth question is the one that pushes new projects toward Solid Queue. One less service to monitor, one less thing that can be misconfigured, one less line item on Render or Fly or wherever you deploy. For a solo founder shipping their first Rails app in 2026, the default of “just the database” is genuinely easier.

Pitfalls that show up after the switch

The first pitfall is treating Solid Queue like Sidekiq with a different backend. It is not. Polling-based pickup means there is a latency floor of whatever your polling interval is — typically a few hundred milliseconds. For most jobs nobody notices. For “send the SMS the instant the user clicks the button” you will notice, and you will want to tune the polling interval down, which costs database load.

The second pitfall is forgetting that your jobs table is now in your primary database. Long-running jobs that hold connections, jobs that themselves do heavy database work, and jobs that fail in tight retry loops can all create contention you didn’t have when Redis was absorbing it. The recommended pattern is to run Solid Queue against a separate database, which is fine but adds back some of the operational complexity people moved to escape.

The third pitfall is the migration itself. Running both adapters in parallel during a cutover is doable but requires discipline about which queue handles which class of work. I have seen teams flip the adapter setting and then spend a day debugging why scheduled jobs from a week ago never ran. Drain Sidekiq fully, or accept the loss, or write a one-off rake task to translate the schedule. Do not “just switch” on a Friday.

The fourth pitfall is monitoring. Sidekiq has a built-in web UI and decades of third-party tooling. Solid Queue’s Mission Control dashboard is good but newer; if your team’s incident runbooks reference Sidekiq dashboards by URL, those URLs go dead.

What the pattern looks like in practice

The right way to think about this is not as a one-time decision but as a default that changes per project. The shape of a decision I’d make on a new Rails 8 SaaS, conceptually:

# config/application.rb
config.active_job.queue_adapter = :solid_queue

# config/recurring.yml — replaces sidekiq-cron / sidekiq-scheduler
production:
  cleanup:
    class: CleanupJob
    schedule: every day at 3am

That is the entire infrastructure decision. No Redis to provision, no sidekiq.yml, no separate dashboard auth to wire up. Deploy is bin/jobs start as a separate process type in your Procfile or render.yaml.

The shape of a decision I’d make on a five-year-old Rails app with Sidekiq Pro:

# Do nothing. Keep running.
# Revisit when Pro renewal comes up, not before.

The shape of a decision I’d make on a brand-new app that I know will need batched fan-out within a year:

I would still start on Solid Queue, because the cost of switching later is a day of work and the cost of running infrastructure I don’t need is a year of monthly bills and one more thing to remember. The “you might need it” argument loses to the “you don’t need it yet” reality almost every time.

The conceptual point: the Sidekiq vs Solid Queue choice is downstream of the question “what am I optimistic about and what am I pessimistic about?” Optimistic about throughput needs, pessimistic about ops capacity: Sidekiq. Pessimistic about throughput needs, optimistic about Rails defaults: Solid Queue. Both answers are defensible. Neither is universal.

What “done” looks like

You know you’ve made the right call when you stop thinking about it. Jobs run, retries behave, the dashboard tells you what failed and why, and the on-call rotation never has to explain to a stakeholder why a stateful service they didn’t know existed is the reason emails are late.

For Solid Queue specifically, “done” means: the jobs database (whether shared or separate) is monitored, the polling interval is tuned for your latency requirements, recurring jobs are in config/recurring.yml instead of a half-dozen scattered cron entries, and you have a runbook for what to do when a poison job clogs a queue. Mission Control is deployed behind auth.

For Sidekiq, “done” looks similar but with Redis monitoring on top, a documented strategy for what happens if Redis goes down (do you tolerate job loss?), and a renewal calendar entry for whichever tier you’re paying for. The cost of “done” is roughly the same in engineer-hours. The cost of “done” in monthly dollars is where they diverge.

When this whole post does not apply

If you are on Rails 6 or earlier, the calculus is different — Solid Queue requires Rails 7.1+ and was tuned for 8. If you’re running on Heroku and your dyno costs already include Redis as a managed addon you’re stuck with, the savings disappear. If your team has zero Postgres operational expertise and a deep Redis bench, switching to a database-backed runner is moving the failure surface to the side you understand less.

And if your background work is a single nightly cron that emails a PDF, you don’t need either of these. You need whenever and a rake task. I have watched people debate Sidekiq vs Solid Queue for an app whose total background workload was four jobs a day. Pick anything. Move on.

The falsifiable claim

Here is the line I’d defend: for a Rails 8 app shipping its first version in 2026, with no existing Redis dependency and typical SaaS background workload (under a few hundred jobs per minute at peak), choosing Sidekiq over Solid Queue will cost more in cumulative infrastructure spend and operational overhead over the first two years than the engineering hours it would take to migrate to Solid Queue later if you outgrow it. If someone runs that comparison honestly and finds the opposite, I want to see the numbers.