Solid Queue vs Sidekiq in 2025: Which Background Job Tool Should You Use?
Background job processing is the backbone of any serious Rails application. Whether you're sending emails, processing payments, generating reports, or handling webhooks, the choice of background job system directly affects reliability, performance, and operational complexity.
With Rails 8 shipping Solid Queue as the default [Active Job backend]
(https://guides.rubyonrails.org/active_job_basics.html)
and Sidekiq 8.0 adding production profiling while continuing to refine job iteration
(https://www.mikeperham.com/2025/03/05/introducing-sidekiq-8.0/),
the trade-offs are no longer theoretical. If you're starting a new project—or reconsidering an existing setup—here's how things actually stack up in 2025.
The State of Background Jobs in Rails Today
Rails 8 introduced what the core team and 37signals refer to as the "Solid Trifecta":
Solid Queue, Solid Cache, and Solid Cable
(https://rubyonrails.org/2024/11/7/rails-8-no-paas-required).
These are database-backed alternatives to Redis-dependent infrastructure for background jobs, caching, and WebSockets. For many applications, Rails now ships with everything needed to handle these concerns using the database you already run in production.
That doesn't make Redis-based tools obsolete. But it does mean Redis is now an opt-in optimization, not a default dependency.
Sidekiq: The Battle-Tested Workhorse
Sidekiq has been the standard background job processor for Rails for well over a decade. According to Sidekiq's author, Enterprise customers alone have processed nearly two trillion jobs, with some systems running at up to 250,000 jobs per second
(https://www.mikeperham.com/2025/03/05/introducing-sidekiq-8.0/).
Strengths
Raw Performance
Sidekiq uses Redis, an in-memory data store, which makes job enqueueing and dequeueing extremely fast
(https://github.com/sidekiq/sidekiq/wiki/Redis).
For systems processing millions of jobs per day with tight latency budgets, this matters.
Mature Ecosystem
Sidekiq's ecosystem is deep and stable. The Sidekiq Web UI, including Chart.js-powered dashboards, has been refined over years of production use
(https://github.com/sidekiq/sidekiq/wiki/Monitoring).
Commercial Features
Sidekiq Pro and Enterprise add functionality that large systems often need, including:
- crash-safe job recovery
- batches
- rate limiting
- unique jobs
- encrypted arguments
- periodic (cron-style) jobs
(https://sidekiq.org/products/enterprise.html)
Enterprise pricing starts at $229/month, reflecting its focus on high-scale production systems.
Sidekiq 8.0 Improvements
Sidekiq 8.0 introduced production job profiling via Vernier, a modernized Web UI, and metrics display windows of up to 72 hours
(https://www.mikeperham.com/2025/03/05/introducing-sidekiq-8.0/).
Job iteration—introduced in 7.3—continues to mature for safely processing very large datasets over time
(https://www.mikeperham.com/2024/07/03/iteration-and-sidekiq-7.3.0/).
Framework Independence
Sidekiq does not require Rails. It works with Sinatra, Hanami, Roda, or plain Ruby
(https://github.com/sidekiq/sidekiq).
Drawbacks
Redis Dependency
Sidekiq requires Redis (or a Redis-compatible service). That means additional infrastructure, monitoring, backups, and operational overhead
(https://github.com/sidekiq/sidekiq/wiki/Redis).
Memory Costs
Redis stores job data in RAM. For large payloads or long retention periods, memory costs can grow quickly.
Operational Complexity
High availability, persistence configuration (RDB/AOF), and cluster management all require expertise—especially at scale.
Solid Queue: The Rails-Native Approach
Solid Queue was built at 37signals as a replacement for their large Resque setup, informed by years of running background jobs at scale for HEY and Basecamp
(https://dev.37signals.com/introducing-solid-queue/).
The goal was simple: install Rails, configure a database, and have background jobs working immediately.
Strengths
No Additional Infrastructure
Solid Queue stores jobs in your existing PostgreSQL, MySQL, or SQLite database
(https://guides.rubyonrails.org/active_job_basics.html#solid-queue).
No Redis server required.
Transactional Semantics
Because jobs live in the database, they can participate in database transactions. When configured appropriately, jobs can be deferred until commit, ensuring they only run if the transaction succeeds
(https://github.com/rails/solid_queue#transactions).
Built-in Recurring Jobs
Solid Queue supports cron-like scheduling via config/recurring.yml
(https://github.com/rails/solid_queue#recurring-tasks).
Concurrency Controls
Concurrency limits are built in—no plugins required
(https://github.com/rails/solid_queue#concurrency-controls).
Queue Pausing
Queues can be paused and resumed during incidents or maintenance
(https://github.com/rails/solid_queue#pausing-queues).
Mission Control — Jobs
Rails provides Mission Control — Jobs, a web UI for inspecting jobs, retrying failures, and viewing error details
(https://github.com/rails/mission_control-jobs).
It exposes Solid Queue's capabilities through a clean operational interface.
Database Visibility
Jobs are rows in tables. You can query them with SQL, inspect them in rails dbconsole, and back them up with the rest of your application data.
Cost Efficiency
Database storage is usually far cheaper than Redis memory. 37signals runs Solid Cache with 10 TB of data and a 60-day retention window, something that would be prohibitively expensive in Redis
(https://rubyonrails.org/2024/11/7/rails-8-no-paas-required).
Drawbacks
Raw Speed
Database polling is slower than in-memory Redis operations. For most applications this difference is irrelevant, but at extreme throughput levels, Sidekiq is faster.
Database Load
Job processing competes with application queries. Rails supports running Solid Queue on a separate database to isolate this load
(https://guides.rubyonrails.org/active_record_multiple_databases.html).
Younger Ecosystem
Solid Queue reached 1.0 in 2024
(https://github.com/rails/solid_queue/releases).
While production-proven at 37signals, its ecosystem is smaller than Sidekiq's.
SQLite Limitations
Solid Queue relies on FOR UPDATE SKIP LOCKED, which SQLite lacks. SQLite works for development and low-traffic deployments, but PostgreSQL or MySQL are better choices in production
(https://www.postgresql.org/docs/current/sql-select.html#SQL-FOR-UPDATE-SHARE).
Performance and Operations
Throughput
Sidekiq benefits from Redis' in-memory speed. Solid Queue incurs database round-trips. For most apps, users will never notice the difference.
Reliability
Sidekiq reliability depends on Redis persistence and shutdown handling. Solid Queue relies on the same ACID guarantees as your application data.
Operations
Eliminating Redis removes an entire category of operational work: separate monitoring, backups, scaling, and failure modes.
Recommendations
- New Rails 8 apps, small teams: Solid Queue
- Mid-sized apps: Start with Solid Queue, monitor, and split databases if needed
- Very high throughput systems: Evaluate Sidekiq carefully
- Existing Sidekiq apps: Don't migrate without a clear operational or cost reason
Notably, HEY processes ~18 million jobs per day using Solid Queue, showing that database-backed job processing scales further than many expect
(https://dev.37signals.com/introducing-solid-queue/).
Final Thoughts
Rails is clearly moving toward database-backed defaults. Solid Queue makes background jobs dramatically simpler for many teams.
Sidekiq remains the right tool when Redis-level performance or Enterprise features are required.
The important thing is that Rails developers now have excellent, first-class options at both ends of the spectrum—and Active Job keeps the door open to change as your needs evolve.