SolidQueue vs Sidekiq #

When discussing background job processing in the Ruby on Rails ecosystem, Sidekiq has been the de facto solution for over a decade. Its performance, community support, and reliability made it the go-to option.

But with the introduction of SolidQueue in Rails 8, developers now have a fully-native alternative that doesn’t require Redis or third-party systems.

Each system has its strengths, and the right choice depends on your project’s complexity, scale, and preferences.

Let’s explore how these two systems compare in detail.

1. Architecture and Infrastructure Requirements #

SolidQueue leverages your existing SQL database, meaning fewer moving parts in your infrastructure.

Sidekiq, on the other hand, requires Redis to manage job queues and state. Redis is fast, but it's an additional service to deploy, secure, and monitor.

2. Performance and Scalability #

Sidekiq’s Redis-backed architecture makes it blazingly fast. It supports millions of jobs per day, handles thousands of concurrent threads, and has an optimized event loop. For large-scale systems with high job throughput and complex scheduling needs, Sidekiq remains unmatched.

SolidQueue is no slouch either. It supports concurrent job processing, bulk enqueueing, job priorities, and scheduled jobs. It uses the efficient FOR UPDATE SKIP LOCKED mechanism to safely distribute jobs among workers. However, since it writes to and polls from a relational database, it may hit bottlenecks sooner than Redis at extremely high volumes.

Use case alignment:

• ✅ SolidQueue: Simpler apps, monoliths, MVPs, internal tools, or anything that doesn’t need ultra-high throughput.
• ✅ Sidekiq: High-scale applications, API-heavy services, or when using Pro/Enterprise features.

3. Feature Set Comparison #

SolidQueue is packed with essential features and includes built-in support for recurring jobs, job priorities, and queue pausing. Sidekiq’s open-source version has many features but reserves advanced capabilities like scheduling, rate limiting, and job batching for its paid editions.

If you need a visual dashboard, Sidekiq wins hands down. SolidQueue doesn't ship with a UI—yet. Monitoring in SolidQueue is mostly manual (via queries or custom UIs) OR by using 3rd party gems such as a) https://github.com/rails/mission_control-jobs b) https://github.com/virolea/panoptic.

4. Developer Experience #

SolidQueue wins points for simplicity and convention. It’s tightly integrated with Active Job and doesn’t require learning a new DSL or configuring Redis queues.

#SolidQueue Job (Active Job)
class InvoiceJob < ApplicationJob
  queue_as :invoices

  def perform(invoice_id)
    Invoice.find(invoice_id).send_email
  end
end

Sidekiq, by contrast, gives you more control but also more responsibility:

#Sidekiq Job
class InvoiceJob
  include Sidekiq::Job
  sidekiq_options queue: :invoices, retry: 3

  def perform(invoice_id)
    Invoice.find(invoice_id).send_email
  end
end

In practice:

• If you're already comfortable with Active Job and want everything “The Rails Way,” SolidQueue will feel seamless.
• If you're looking for performance and full control with advanced job workflows, Sidekiq is more flexible and mature.

5. Deployment and Operations #

SolidQueue reduces operational complexity:

• No Redis to maintain
• Fewer services to secure and scale
• Uses the same infrastructure as your Rails app

Sidekiq, while fast, adds Redis as a critical infrastructure dependency. You’ll need monitoring, backups, and failover strategies for it.

Summary: When to Use What? #

Ultimately, the choice between SolidQueue and Sidekiq depends on your scale, team preferences, and infrastructure complexity tolerance.

SolidQueue is a fantastic option for most Rails apps today, and it's only going to get better as it matures.