Rails 8 + Solid Queue: Building Production-Ready Job Processing in 2026

Why Solid Queue Changes the Rails Job Processing Game

For years, Rails developers have relied on Redis-backed solutions like Sidekiq for background job processing. While powerful, they introduce operational complexity: another service to monitor, another potential point of failure, another infrastructure bill. Solid Queue, now the default job backend in Rails 8, flips this entirely by letting you process jobs directly through your existing database.

This isn't a performance compromise. Solid Queue is a production-grade job queue built by the Rails core team specifically for the modern web. If you're running Rails 8 in 2026, understanding Solid Queue isn't optional—it's how you're going to process 90% of background jobs efficiently.

What Makes Solid Queue Different

Solid Queue uses your PostgreSQL or MySQL database (or even SQLite in development) as the queue backbone. Jobs are stored as records, workers poll the database for pending work, and execution happens across your application servers. The architectural simplicity is its superpower.

Key Advantages

• Zero external dependencies: No Redis cluster to maintain. Your database is already there.
• Built-in transactionality: Jobs and business logic can share the same ACID guarantees.
• Reduced cost: One less managed service means lower infrastructure spend, especially for small to mid-sized teams.
• SQLite-friendly: Perfect for staging and development environments that don't need a full Postgres setup.
• Native Rails integration: It's in Rails 8 core. No Gem surprises or version conflicts.

When You Still Want Redis

Solid Queue isn't a universal replacement. High-frequency job systems (thousands of jobs per second) or teams already deeply invested in Redis-based microservices might stick with Sidekiq. But for typical North American SaaS, e-commerce, and web applications? Solid Queue handles it beautifully.

Setting Up Solid Queue in Rails 8

Getting started is straightforward. Rails 8 defaults to Solid Queue, so your `Gemfile` already has it. Configure it in `config/solid_queue.yml`:

Example configuration:

```yaml
production:
  dispatchers:
    - batch_size: 500
      polling_interval: 0.1
  workers:
    - threads: 5
      polling_interval: 0.1
```

The `threads` setting controls how many jobs your worker process handles concurrently. For I/O-heavy work (API calls, database operations), 5-10 threads is typical. CPU-bound tasks? Lower that to 2-3.

Database Preparation

Run the Solid Queue migrations to create the necessary tables:

bin/rails solid_queue:install

This creates `solid_queue_jobs`, `solid_queue_scheduled_executions`, and related tables. These tables are heavily indexed for query performance, so don't worry about scaling into the millions of job records.

Practical Patterns for Production Use

Handling Job Retries

Define retry behavior in your job class:

```ruby
class SendEmailJob < ApplicationJob
  queue_as :default
  retry_on StandardError, wait: 5.seconds, attempts: 3
  discard_on EmailAddressInvalid

  def perform(user_id)
    user = User.find(user_id)
    UserMailer.welcome(user).deliver_now
  end
end
```

Solid Queue respects these declarative retry policies. Failed jobs automatically re-enqueue with exponential backoff.

Multiple Queue Priorities

Separate critical work from background processing:

```ruby
class CriticalNotificationJob < ApplicationJob
  queue_as :urgent
  def perform(order_id)
    # Executes with higher priority
  end
end
```

Configure separate worker pools for each queue to ensure urgent jobs don't get blocked by bulk operations.

Monitoring and Observability

Solid Queue provides `SolidQueue::Job` and `SolidQueue::ScheduledExecution` models you can query:

```ruby
SolidQueue::Job.where(queue: 'default').failed.count
SolidQueue::Job.where(created_at: 1.hour.ago..).count
```

Many teams integrate this with New Relic or Datadog for alerting. Since jobs live in your database, standard SQL dashboards work perfectly.

Solid Queue + Kamal Deployment

When deploying Rails 8 with Kamal, declare Solid Queue workers as a separate service:

```yaml
services:
  web:
    cmd: bundle exec rails server
  worker:
    cmd: bundle exec solid_queue:start
    options:
      cpus: 1
      memory: 512m
```

Scale workers independently from web processes. During traffic spikes, spin up extra worker replicas without increasing API server capacity.

Performance Tuning

A few practical optimizations:

1. Tune polling intervals: Shorter intervals (0.05s) catch jobs faster but use more database queries. Find your sweet spot.
2. Use database indexes: Solid Queue migrations include them, but verify they exist after upgrades.
3. Monitor queue depth: If jobs pile up, add worker threads or processes. Solid Queue scales linearly with worker capacity.
4. Batch similar jobs: Instead of 1000 individual jobs, batch them into 100 bulk operations when possible.

The Bottom Line

Solid Queue represents a maturation in Rails background job handling. It's not bleeding-edge—it's battle-tested and backed by Rails core. For most teams building in 2026, it's the right default choice. You get reliability, simplicity, and cost savings without sacrificing capability.

Ready to modernize your Rails job processing? At ElevenClicks, we've helped dozens of North American businesses migrate to Rails 8 and optimize their Solid Queue implementations for scale. Whether you're evaluating job backends, tuning performance, or deploying with Kamal, our Rails expertise ensures your background processing is rock-solid. Let's talk about your architecture.