The short answer
Use Solid Queue if you're on Rails 8, processing under 5,000 jobs per minute, and want one less piece of infrastructure to operate. Stay on Sidekiq if you need sub-100ms pickup latency, run 10,000+ jobs per minute sustained, or you already have Redis in production. Most teams should default to Solid Queue and switch only when measurements force the issue.
We've run Sidekiq in production since 2014 on Rails apps that processed everything from transactional email to SEO crawl pipelines. We've migrated one of those apps to Solid Queue, kept another on Sidekiq, and shipped two greenfield Rails 8 apps with Solid Queue from day one. None of those decisions were obvious from the docs. They became obvious from the numbers.
This is the framework we use when a client asks "should we switch?"
Watch first: Rosa Gutiérrez on Solid Queue internals
Rosa Gutiérrez maintains Solid Queue at 37signals. This Rails World 2024 talk is the single best 30 minutes you can spend understanding why Solid Queue is architected the way it is, why FOR UPDATE SKIP LOCKED matters, and what the design intentionally cannot do.
The 4-question decision framework
Answer these honestly. There's no clever tally — three of them are veto questions.
1. How many jobs per minute are you running at peak?
This is the single most important number, and most teams genuinely don't know it. Either run a quick aggregation in production (last 7 days of enqueue volume divided by minutes-with-load) or instrument it properly with a counter. Get the number before you decide anything else.
Under 1,000 jobs/min: Solid Queue, no debate. The architectural simplicity wins. 1,000–5,000 jobs/min: Solid Queue still wins for most teams, but pay attention to questions 2 and 4. 5,000–10,000 jobs/min: grey zone. Solid Queue can handle it if your jobs are short and your Postgres is sized right, but Sidekiq is the easier choice. 10,000+ jobs/min sustained: stay on Sidekiq, or look at Sidekiq Enterprise. Solid Queue isn't designed for that scale.
One caveat: burst traffic is different from sustained. A nightly batch firing 50,000 jobs in two minutes is fine on Solid Queue if the rest of the day is quiet. A sustained 8,000 jobs/min during business hours is a different problem.
2. What's your latency budget on job pickup?
Job pickup latency is the gap between perform_later and the worker actually starting. On Sidekiq, that's about 8 milliseconds. On GoodJob, 50–200ms. On Solid Queue, 100ms–1.2 seconds depending on poll interval and connection pool config. Mike Perham's benchmark gist (he's the Sidekiq author, benchmarking Solid Queue honestly) is the numbers everyone keeps citing.
For most jobs — sending an email, generating a report, processing a webhook — none of this matters. The job will run within a second either way and nobody notices. Where it matters:
- Jobs that drive visible UI updates. "Click upload, see thumbnail appear" feels broken at 1.2 seconds. Feels instant at 8ms.
- Jobs that fan out to other jobs. A pipeline with 5 sequential job hops at 1.2s pickup each adds 6 seconds of dead latency before any actual work happens.
- Real-time integrations. Webhook handlers that must echo back to an external service inside a 5-second timeout window.
If any of those describe your jobs, Sidekiq is a real advantage. Otherwise, the latency difference is invisible to users.
3. Do you already have Redis in production?
This question matters more than people admit. The "Solid Queue eliminates Redis" pitch is great if Redis is your only reason for running Redis. It's irrelevant if you're already running it for caching, Action Cable, rate limiting, or session storage.
If Redis is already in your stack and load-tested, switching to Solid Queue saves you nothing operationally — you still have to run Redis. You're just trading Sidekiq's mature ecosystem for Solid Queue's newer one and gaining maybe 5% on your AWS bill.
If you're greenfielding, or you're only running Redis for Sidekiq, the "one fewer service" pitch is real and worth taking. Managed Redis (AWS ElastiCache, Render Redis) runs $50–$300/month on small apps and scales linearly. Cutting it costs you nothing functional.
4. What's your team's operational headcount?
This is the question senior engineers tend to underweight. Sidekiq's UI, ecosystem, and tooling have a 12-year head start on Solid Queue. Sidekiq has better dashboards, better alerting integrations, and better community fixtures for the weird production scenarios you'll inevitably hit.
Solid Queue ships with a basic dashboard via Mission Control. It works. It's not Sidekiq Pro's dashboard. If your team has a dedicated SRE who'll instrument and monitor a younger system properly, this is fine. If you're a 3-person team and you want the boring, battle-tested choice, Sidekiq still has the operational maturity edge — even if the architecture is "worse."
The numbers most comparisons leave out
Here's the side-by-side we wish we'd had on day one. Numbers reflect a Postgres-backed marketplace processing roughly 80K jobs/day during business hours, with cross-references to the official Solid Queue repo.
| Metric | Sidekiq | GoodJob | Solid Queue |
|---|---|---|---|
| Median pickup latency | ~8ms | 50–200ms | 400ms–1.2s |
| Throughput ceiling (single host) | ~10K jobs/min | ~3K jobs/min | ~5K jobs/min |
| Infra cost (small app) | +$50/mo Redis | $0 extra | $0 extra |
| Transactional enqueue | No (race risk) | Yes | Yes |
| Dashboard quality | Excellent (Pro $$$) | Decent | Basic (Mission Control) |
| Recurring jobs | Pro only | Built-in | Built-in |
| Unique / concurrency control | Pro only | Built-in | Built-in |
The transactional-enqueue row is the one that flips most decisions on its head. With Sidekiq, you can enqueue a job inside an ActiveRecord transaction that later rolls back — and the job runs anyway, looking for a record that doesn't exist. We've debugged that bug across four different client codebases. With Solid Queue, the enqueue commits or rolls back with your transaction. The race is gone.
Solid Queue gotchas you'll hit at scale
The autovacuum problem
Solid Queue churns rows hard. On a busy queue, you're inserting and deleting tens of thousands of rows per hour into solid_queue_jobs, solid_queue_ready_executions, and friends. Postgres autovacuum defaults are fine for application tables but will fall behind on queue tables under load. Index bloat creeps in, queries get slower, and the symptoms read like "Solid Queue is slow" — when really it's an autovacuum tuning problem.
Fix: lower the autovacuum scale factor on Solid Queue's tables. Something like ALTER TABLE solid_queue_ready_executions SET (autovacuum_vacuum_scale_factor = 0.02, autovacuum_analyze_scale_factor = 0.01);. Monitor index bloat via pg_stat_user_indexes. If you're not already comfortable with Postgres tuning, this is where Solid Queue surprises you — see our ActiveRecord patterns guide for the broader query-tuning context.
Connection pool sizing
Every Solid Queue worker holds a database connection while it polls. With 20 workers across 3 processes, you've consumed 60 connections just for the queue. Add your app server pool, and you'll blow past your Postgres connection limit fast.
Fix: configure Solid Queue with a separate database connection (Rails 6.1+ multi-database setup), or use a connection pooler like PgBouncer in transaction mode on the queue side. The Postgres FOR UPDATE SKIP LOCKED docs are worth reading to understand what Solid Queue is doing on every poll — once you see it, the connection cost becomes obvious.
Long-running jobs and lock leases
Solid Queue holds a lock on a job while it executes. If the worker crashes, the lock has a lease that times out and the job becomes pickable again. The default lease duration may not match your longest jobs. A job that runs 15 minutes can lose its lock if the lease is set to 10 minutes — and then a second worker picks it up and runs it in parallel. Idempotency saves you here, the way it does on Sidekiq retries, but you should be deliberate about it.
Set your concurrency_maintenance_interval and process_heartbeat_interval based on actual job durations. If you have one 30-minute job and a thousand 200ms jobs, isolate the long one to its own queue with different config.
Migrating from Sidekiq to Solid Queue: the actual playbook
This is the migration path we ran on a Rails 7.1 app processing about 40K jobs/day. End-to-end took 3 weeks of part-time engineering plus 2 weeks of parallel-run observation.
- Upgrade to Rails 7.2 or 8. Solid Queue requires 7.2+ and is the Rails 8 default. Don't try to use it on older Rails versions — the Active Job adapter contract changed in subtle ways.
- Install Solid Queue alongside Sidekiq, both registered as Active Job adapters. At this point both work; you haven't switched anything live yet.
- Migrate one queue at a time, low-stakes first. Start with the email queue. Set
config.active_job.queue_adapter = :solid_queueonly inside the mailer, or via per-job override usingself.queue_adapter. - Run Sidekiq and Solid Queue in parallel for 1–2 weeks per migrated queue, watching error rates, pickup latency, and Postgres CPU. If anything looks wrong, the rollback is one config line.
- Move the high-volume queues last. By the time you get there, you've burned in the Postgres tuning and connection pool config on lower-stakes traffic.
- Drain Sidekiq, then remove Redis — or keep Redis if you use it for caching, but at least remove Sidekiq's queue keys and worker processes.
What can go wrong: surprise long-tail jobs you didn't know about (background imports, infrequent crons), idempotency assumptions that worked on Sidekiq's at-least-once delivery but trip on Solid Queue's slightly different failure modes, and the autovacuum issue above hitting you 3 days post-cutover. Plan for it.
One real takeaway from production: queue adapter switches rarely solve scaling problems on their own — the bottleneck is usually elsewhere (database, slow jobs, fan-out shape). Profile before you migrate. For broader context on the architecture trade-offs in a Rails SaaS build, the Rankloop case study walks through how we made those calls on a production app.
When NOT to switch from Sidekiq
Don't switch if any of these are true:
- You're processing 10K+ jobs/minute sustained. Solid Queue isn't designed for it.
- You're already using Sidekiq Pro or Enterprise and depending on features like batches or expiring jobs. Solid Queue has some equivalents but not all.
- Your team has zero capacity to debug Postgres-level issues. Sidekiq fails in well-known, well-Googleable ways; Solid Queue fails in newer ways that haven't accumulated 12 years of Stack Overflow answers yet.
- You're on Rails 6 or earlier. Upgrade first, switch backends second. Doing both at once is how migrations turn into 6-month projects.
- Your Postgres is already at 70%+ CPU during normal load. Adding queue traffic to that database is a bad idea — get to a separate queue database first, or stay on Sidekiq until you sort out Postgres capacity. Our Rails performance optimization guide covers the diagnostic steps.
Where this fits in a broader Rails 8 upgrade
Solid Queue isn't a standalone decision. It ships alongside Solid Cache (Postgres-backed cache) and Solid Cable (Postgres-backed Action Cable) as the Rails 8 "solid trifecta." If you're already adopting the Rails 8 release, the decisions stack: Redis-for-cache, Redis-for-Action-Cable, and Redis-for-queue can potentially all go away.
That's appealing — but be honest about why Redis is in your stack. If you use it for one thing, removing it is real savings. If you use it for five things, you're keeping it whether Solid Queue ships or not. For high-throughput real-time use cases, see our Action Cable patterns post on when Redis-backed Action Cable still wins over Solid Cable.
FAQ: Solid Queue vs Sidekiq
Can I run Solid Queue and Sidekiq side-by-side in the same Rails app?
Yes. Both are Active Job adapters. You can run them simultaneously, route different jobs to different adapters via self.queue_adapter per job class, and migrate queue by queue. This is how the recommended migration path works — gradual, not flag-day.
Is Solid Queue free? What about Sidekiq?
Solid Queue is fully open-source under the MIT license — no paid tier. Sidekiq's open-source version is free but reserves features like batches, unique jobs, recurring jobs, and rate limiting for Sidekiq Pro (~$179/month) and Sidekiq Enterprise (~$249/month per developer and up). Solid Queue ships most of those features at no cost.
Does Solid Queue work with MySQL or only Postgres?
Both. Solid Queue requires a database that supports FOR UPDATE SKIP LOCKED — Postgres 9.5+ and MySQL 8.0+ qualify. SQLite is supported as of Solid Queue 1.0, though realistic production use means Postgres or MySQL.
What happens to my Sidekiq middleware and ecosystem on Solid Queue?
Active Job has its own middleware system (callbacks like before_perform, around_perform). Most Sidekiq middleware patterns translate cleanly. Sidekiq-specific gems (Sidekiq-cron, Sidekiq-unique-jobs) don't carry over — but Solid Queue's built-in concurrency control and recurring jobs cover most of what those gems provide.
How much load testing should I do before cutover?
For a marketplace or SaaS, replay 2–4 weeks of production job volume through staging running Solid Queue before cutover. Watch Postgres CPU, connection count, and index bloat under load. Don't trust microbenchmarks — your actual job shape matters more than synthetic throughput numbers.
How we can help
At TechVinta, we've migrated Rails apps from Sidekiq to Solid Queue, built new apps on Solid Queue from day one, and made the call to not migrate when the throughput numbers said stay. We've also unblocked Postgres autovacuum issues that masqueraded as "Solid Queue is slow" bugs. A typical Solid Queue migration takes 3–5 weeks for a mid-sized app, including the parallel-run observation period.
Stuck on a Sidekiq scaling decision, or planning a Rails 8 upgrade and weighing the Solid trifecta? Talk to our Rails team, or get a free estimate — we'll review your job volume, infrastructure, and roadmap and propose a plan within 48 hours.
