Solid Queue

What Is Solid Queue?

Historically, background job processing in Rails relied on Redis-backed tools like Sidekiq. While effective, this introduced an additional piece of infrastructure to install, configure, monitor, and scale.

Solid Queue, developed by the Rails core team and bundled as the default Active Job backend starting in Rails 8, removes that dependency by storing jobs directly in the application's relational database (PostgreSQL, MySQL, or SQLite). It integrates with Active Job, so job definitions look and behave the same as they always have in Rails.

Solid Queue is part of a broader "Solid" trilogy introduced around Rails 8:

• Solid Queue – Background jobs (replaces Redis + Sidekiq/Resque)
• Solid Cache – Caching (replaces Redis/Memcached for caching)
• Solid Cable – Action Cable pub/sub (replaces Redis for WebSockets)

Together, these allow a Rails app to run in production without Redis at all, simplifying deployment.

Why Is Solid Queue Useful?

Relying on Redis for background jobs introduces:

• Additional infrastructure to provision, monitor, and pay for
• Another moving part that can fail independently of the app
• Extra operational complexity for small teams or simple deployments

Solid Queue helps by:

• Removing the need for Redis in many applications
• Using the existing database for job storage, reducing infrastructure
• Supporting multiple queues, priorities, retries, and recurring jobs out of the box
• Integrating natively with Active Job, requiring minimal code changes
• Simplifying deployment, especially for smaller apps or single-server setups

It's particularly useful for teams that want a "batteries-included" Rails setup with fewer external dependencies to manage.

How Does Solid Queue Work?

Solid Queue stores jobs as rows in database tables rather than in Redis. A separate Solid Queue supervisor process (similar to how Sidekiq workers run) polls the database for pending jobs and dispatches them to worker threads/processes for execution.

Key components:

• Active Job – The standard Rails interface used to define and enqueue jobs (unchanged).
• Database tables – Store queued jobs, scheduled jobs, and job execution state.
• Solid Queue supervisor – Runs as a separate process, polling the database and dispatching jobs to workers.
• Dashboard (optional) – Tools like mission_control-jobs can provide a Web UI similar to Sidekiq's, for monitoring queues and job status.

Examples

Scenario 1: Defining a Job (Unchanged from Standard Active Job)

class WelcomeEmailJob < ApplicationJob 
  queue_as :default 
 
  def perform(user_id) 
    user = User.find(user_id) 
    UserMailer.welcome_email(user).deliver_now 
  end 
end 

Scenario 2: Enqueuing a Job

WelcomeEmailJob.perform_later(@user.id) 

No code changes are required to switch from Sidekiq to Solid Queue, since both use the standard Active Job interface, only the configured queue adapter changes.

Scenario 3: Configuring Solid Queue as the Active Job Backend

# config/environments/production.rb 
config.active_job.queue_adapter = :solid_queue 

Scenario 4: Defining Queues and Priorities

# config/queue.yml 
production: 
  workers: 
    - queues: [default, mailers] 
      threads: 5 
      processes: 2 

This configures how many worker processes and threads handle each queue, similar to Sidekiq's concurrency settings.

Scenario 5: Recurring Jobs

# config/recurring.yml 
production: 
  cleanup_expired_tokens: 
    class: CleanupExpiredTokensJob 
    schedule: every day at 2am 

Solid Queue supports recurring/scheduled jobs natively, without needing an additional gem like sidekiq-cron.

Where to Use Solid Queue?

• New Rails 8 applications that want to avoid Redis entirely
• Small to mid-sized applications where reducing infrastructure complexity matters
• Single-server or simple deployment setups (e.g., via Kamal)
• Teams standardizing on a "batteries-included" Rails stack
• Any app already using Active Job that wants to simplify its background processing infrastructure

A Note of Caution

Since Solid Queue uses the primary application database (unless configured to use a separate database), high job volume can add load to the same database serving the rest of the application. For very high-throughput background processing needs, Redis-backed solutions like Sidekiq may still offer better raw performance. Solid Queue's advantage is primarily simplicity and reduced infrastructure, not necessarily raw throughput at extreme scale. Rails allows configuring a separate database specifically for Solid Queue to help mitigate this.

In Summary

Solid Queue is Rails 8's built-in, database-backed background job processor that eliminates the need for Redis in many applications. By integrating natively with Active Job and storing jobs in the application's existing database, it simplifies infrastructure while still supporting queues, priorities, retries, and recurring jobs.