Rails 8 in Production: Is the Solid Stack Enough to Replace Redis + Sidekiq?

Rails 8 made a bold move: reduce operational complexity by promoting a more integrated default stack. Can Solid Queue/Cache/Cable replace parts of Redis + Sidekiq in production? Short answer: sometimes yes, and often partially.

Why This Matters

Every external service adds provisioning overhead, new failure modes, observability complexity, and cost. Redis is battle-tested, but running it means another service to monitor, patch, scale, and wake up for at 3 AM. The Solid Stack promises to consolidate jobs, caching, and pub/sub onto your existing database — fewer moving parts, simpler deploys, and one fewer entry in your on-call runbook.

But consolidation only matters if performance holds. The real question is not whether the Solid Stack works — it does — but whether it works well enough for your specific throughput, latency, and reliability requirements.

Where Solid Queue Works Well

Solid Queue stores jobs in your relational database using FOR UPDATE SKIP LOCKED for concurrency-safe polling. It supports priorities, multiple queues, recurring jobs, and built-in concurrency controls. In practice, it handles the workloads that most Rails applications actually have.

Standard Background Jobs and Moderate Throughput

If your application enqueues fewer than roughly 5,000–10,000 jobs per minute, Solid Queue on a modern PostgreSQL or MySQL instance handles this comfortably. That covers the majority of Rails applications: transactional emails, webhook deliveries, PDF generation, image processing, nightly reports, and scheduled maintenance tasks.

# config/queue.yml — typical Solid Queue configuration
dispatchers:
  - polling_interval: 1
    batch_size: 500

workers:
  - queues: [critical, default, low]
    threads: 5
    processes: 2
    polling_interval: 0.1

Teams optimizing for simplicity over extreme throughput get the most value here. The built-in concurrency controls are a genuine advantage over Sidekiq's open-source tier — you can limit concurrent executions per job class without reaching for Sidekiq Enterprise:

class ExternalApiSyncJob < ApplicationJob
  limits_concurrency to: 3, key: ->(account_id) { account_id }

  def perform(account_id)
    ExternalApi::Client.sync(account_id)
  end
end

Less Ideal Scenarios

Ultra high-throughput event processing and very spiky traffic push Solid Queue's limits. At tens of thousands of jobs per minute, the database write pressure becomes meaningful — each enqueue is an INSERT, each dequeue is a SELECT ... FOR UPDATE plus a DELETE or UPDATE. Redis-backed Sidekiq handles this in memory with sub-millisecond operations, and the raw throughput difference is significant and measurable.

Solid Cache and Solid Cable

Solid Cache replaces RedisCacheStore with a database-backed cache. Evaluate these factors before switching:

Solid Cache shines when cached values are large (HTML fragments, serialized API responses, computed reports) and can tolerate single-digit-millisecond latency. Solid Cable works well for modest WebSocket usage — live notifications, internal tool chat, dashboard updates — but its polling model introduces latency that may not suit real-time features requiring sub-10ms delivery.

# config/cache.yml — Solid Cache on a dedicated database
production:
  databases: [cache_primary]
  store_options:
    max_size: <%= 256.gigabytes %>
    max_age: <%= 60.days.to_i %>

# config/cable.yml — Solid Cable configuration
production:
  adapter: solid_cable
  polling_interval: 0.1.seconds
  keep_messages_around_for: 1.day

Migration Strategy from Redis + Sidekiq

The best migration is incremental. You do not need to adopt all three Solid components at once, and you should not try.

Step 1: Isolate Job Categories

Classify your jobs by risk and throughput. Low-priority queues (mailers, cleanup tasks, weekly digests) are your migration candidates. Critical payment processing and high-throughput event pipelines stay on Sidekiq until you have confidence in the new stack.

Step 2: Move Low-Risk Queues First

# config/application.rb — default to Solid Queue
config.active_job.queue_adapter = :solid_queue

# Keep critical jobs on Sidekiq during migration
class CriticalPaymentJob < ApplicationJob
  self.queue_adapter = :sidekiq

  def perform(payment_id)
    # stays on Sidekiq until you are confident
  end
end

# Low-priority jobs use the default (Solid Queue)
class WeeklyDigestJob < ApplicationJob
  queue_as :low

  def perform
    # runs on Solid Queue immediately
  end
end

Step 3: Keep Hybrid Mode for High-Risk Pipelines

There is no rule that says you must adopt all three or none. Many production Rails applications will settle on a hybrid: Solid Queue for most jobs, Solid Cache for large-value caching, and Redis for Action Cable and latency-sensitive operations. This is a perfectly valid long-term architecture.

Step 4: Standardize Observability Before Full Migration

Before migrating your last queues off Redis, ensure your monitoring covers database CPU, I/O wait, connection pool utilization, job execution latency, and cache hit rates. Monitor for at least two weeks per phase. Update your incident playbooks — cache and job failures now point to database issues, not Redis issues.

Decision Framework

For teams evaluating how different AI tools handle Rails 8 configuration and migration code, WhoCodes Best provides side-by-side comparisons of AI coding models on real-world tasks — useful context when you are asking an assistant to help scaffold your Solid Stack migration.

Final Takeaway

Rails 8 gives teams a credible path to lower operational complexity. The Solid Stack is not a toy — it is production-grade infrastructure backed by Basecamp and HEY's real-world usage. For the majority of Rails applications, it genuinely eliminates the need for Redis.

But "most applications" is not "all applications." Migrate incrementally, measure ruthlessly, and keep hybrid where it makes sense. The best architecture is the one that matches your actual workload, not the one that looks cleanest on a diagram.