Frequently Asked Questions:
- What replaces Redis in Rails 8? Rails 8 introduces SolidQueue (job queues), SolidCache (caching), and SolidCable (ActionCable/Turbo Streams messaging), which run on your relational database instead of Redis.
- How does SolidQueue avoid the lock contention that plagued earlier DB-backed queues? SolidQueue relies on PostgreSQL’s FOR UPDATE SKIP LOCKED when selecting a job from solid_queue_ready_executions so multiple workers can concurrently pick distinct jobs without blocking each other.
- Can I schedule recurring jobs with SolidQueue? Yes. SolidQueue has built-in cron-style recurring jobs configured in config/recurring.yml. The scheduler enqueues due jobs and re-schedules the next occurrence deterministically.
- How do I migrate from Sidekiq to SolidQueue? Switch your ActiveJob adapter to :solid_queue, bundle add the solid_queue gem, run rails solid_queue:install and db:migrate, convert cron schedules to config/recurring.yml, update your Procfile to run solid_queue:start, and remove Redis/Sidekiq gems.
- When should I keep using Redis? Keep Redis if you need sustained thousands-of-jobs-per-second throughput, sub-millisecond job latency, complex multi-service pub/sub patterns, or atomic rate-limiting and counters that benefit from Redis’ primitives.
Summary
Rails 8 replaces Redis and its ecosystem with SolidQueue, SolidCache, and SolidCable, letting Rails apps use their existing relational database for job queues, caching, and real-time messages. SolidQueue leverages PostgreSQL’s FOR UPDATE SKIP LOCKED to let many workers safely claim unique jobs without lock contention, and uses dedicated tables (solid_queue_jobs, solid_queue_ready_executions, solid_queue_scheduled_executions) and small coordinating processes for dispatch, scheduling, and supervision. It includes built-in recurring jobs, database-native concurrency controls (limits_concurrency with semaphores), and pairs with Mission Control Jobs for a free, SQL-friendly UI. The result is lower operational complexity: fewer services to deploy, monitor, back up, and debug. For most apps the tradeoff is favorable — but Redis remains appropriate for ultra-low-latency, extremely high-throughput, or complex cross-service pub/sub and atomic counter use cases.
Highlights:
- Rails 8 drops Redis from the default stack in favor of SolidQueue, SolidCache, and SolidCable.
- SolidQueue uses PostgreSQL’s FOR UPDATE SKIP LOCKED to avoid lock contention and safely distribute jobs.
- Built-in recurring jobs and database-native concurrency limits (limits_concurrency) require no extra gems.
- Mission Control Jobs provides a free web UI that shows job status, failures, retries, and lets you query job data with SQL.
- Migration from Sidekiq is straightforward: change the queue adapter, install SolidQueue, migrate tables, update Procfile and schedules.
Rails 8 rethinks the default background-processing and realtime toolchain by removing Redis and introducing SolidQueue, SolidCache, and SolidCable. These components run on your relational database (PostgreSQL, SQLite, or MySQL) and rely on standard transactional semantics instead of a separate key-value service. Replacing Redis reduces operational overhead — fewer servers to deploy, version, patch, monitor, back up, and secure — and avoids dual-datastore debugging and mismatched semantics between Redis and your RDBMS. For most typical Rails apps (well under the high-throughput extremes), this simplifies infrastructure and centralizes visibility into one store and one query language: SQL.
SolidQueue's design is built on proven database features. It uses PostgreSQL’s FOR UPDATE SKIP LOCKED to let many workers poll solid_queue_ready_executions and atomically claim a job without blocking others. Jobs and metadata live in solid_queue_jobs, scheduled jobs sit in solid_queue_scheduled_executions until due, and ready jobs are queued in solid_queue_ready_executions. Separate processes handle polling, dispatching, scheduling, and supervision so concerns are isolated and polling intervals can be tuned (defaults: ready ~0.2s, scheduled ~1s). SolidQueue also includes recurring-job configuration (config/recurring.yml) and concurrency controls via limits_concurrency, implemented with solid_queue_semaphores and solid_queue_blocked_executions, giving fine-grained throttling without external services.
Migration from Sidekiq is intentionally low friction: set config.active_job.queue_adapter = :solid_queue, add the gem, run solid_queue migrations, convert cron schedules to config/recurring.yml, and update your Procfile to launch solid_queue:start. Mission Control Jobs is a free UI you can mount to monitor jobs, inspect failures with stack traces, retry or discard, and even run SQL against job tables. However, SolidQueue is not a universal replacement: keep Redis when you need sustained thousands-of-jobs-per-second throughput, sub-millisecond queue latency, complex cross-service pub/sub, or atomic rate-limiting primitives. For 95–99% of typical apps, SolidQueue delivers simpler operations, familiar tooling, and strong enough performance.