Ruby on Rails
Solid Queue vs Sidekiq: Should Your Rails App Migrate, and How
Rails 8 made Solid Queue the default Active Job backend, and many teams now ask whether they should drop Sidekiq and Redis. The answer depends less on benchmarks than on your job volume, the Sidekiq features you use and how much infrastructure you want to run. This guide compares both and explains a migration that can be done queue by queue.
How each one works
Sidekiq stores jobs in Redis and processes them with threads. It is mature, very fast, and has a large ecosystem; some features, such as batches and advanced rate limiting, are part of its paid Pro and Enterprise editions.
Solid Queue stores jobs in your relational database: MySQL, PostgreSQL, SQLite or MariaDB. It uses FOR UPDATE SKIP LOCKED where available so workers do not block each other, and it includes concurrency controls, recurring tasks defined in config/recurring.yml, and a dashboard through Mission Control Jobs. In Rails 8 it is configured by default with a separate queue database.
When Solid Queue is enough
For most business applications, background jobs are emails, exports, webhooks, imports and scheduled maintenance. At that volume a database-backed queue performs well and removes Redis from the stack: one less service to host, monitor, back up and secure.
- Your job volume is moderate and latency of a second or two is acceptable.
- You use Sidekiq only through Active Job, without Sidekiq-specific APIs.
- You want recurring jobs and concurrency limits without extra gems or paid tiers.
- Your team prefers fewer moving parts over maximum throughput.
When to keep Sidekiq
Keep Sidekiq if you process very high job volumes, rely on Pro or Enterprise features, or call Sidekiq directly through Sidekiq::Job classes and sidekiq_options. Moving those workloads to the database adds write load to it, so measure before switching rather than migrating because it is the new default.
A gradual migration
Active Job lets you set the adapter per job class, which makes an incremental migration possible.
- Convert jobs that use Sidekiq APIs directly into Active Job classes first.
- Run bin/rails solid_queue:install, review config/queue.yml and decide between a separate queue database or a single one.
- Start the workers with bin/jobs or the Puma plugin (plugin :solid_queue) in a staging environment.
- Move low-risk jobs first by setting self.queue_adapter = :solid_queue on those classes, and watch them in Mission Control Jobs.
- Move recurring jobs to config/recurring.yml, then the rest, and remove Sidekiq and Redis only when no jobs remain in their queues.
Key takeaways
- Solid Queue removes Redis and covers typical business workloads.
- Keep Sidekiq for very high volume or paid Pro/Enterprise features.
- Convert direct Sidekiq jobs to Active Job before migrating.
- Migrate per job class and retire Redis only when its queues are empty.
Related
Want to review your case with context?
Share the codebase, workflow, or systems involved and the result you need. We will use the call to decide a practical next step.