I Love You, Redis, but I'm Leaving You for SolidQueue

Why It Matters

Consolidating on the database cuts hosting costs and DevOps complexity, while still meeting the performance needs of the majority of Rails workloads.

Key Takeaways

• Rails 8 removes Redis from default stack
• SolidQueue runs job queues on PostgreSQL
• No separate caching or pub/sub service needed
• Migration replaces Sidekiq with simple config changes
• Redis still required for high‑throughput, sub‑ms latency

Pulse Analysis

Rails 8’s decision to drop Redis from its core stack marks a strategic shift toward simplifying infrastructure for the majority of web applications. By consolidating job queuing, caching, and real‑time messaging into SolidQueue, SolidCache, and SolidCable, developers can rely solely on the existing relational database, eliminating the need to provision, patch, and monitor a separate key‑value store. This reduction in moving parts cuts operational overhead, lowers hosting costs, and removes a common source of latency caused by network hops between the app and Redis.

SolidQueue leverages PostgreSQL’s FOR UPDATE SKIP LOCKED clause to achieve lock‑free job dispatching directly in SQL. Workers poll a ready‑executions table, claim a row with a single statement, and release the lock upon completion, allowing thousands of concurrent workers without contention. The architecture also includes built‑in scheduling, recurring jobs, and semaphore‑based concurrency limits, removing the need for external cron or Sidekiq‑Enterprise add‑ons. Monitoring is handled through the open‑source Mission Control UI, which reads the same database tables, providing real‑time visibility without a separate dashboard service.

For most Rails teams the migration path is straightforward: switch the ActiveJob adapter, add the solid_queue gem, run the provided migrations, and replace Sidekiq‑cron entries with a simple YAML schedule. This eliminates Redis‑related hosting fees and reduces the operational burden of HA clusters, backups, and network security rules. Organizations that process fewer than a hundred jobs per second or can tolerate latency above 100 ms typically see comparable performance on PostgreSQL, while high‑frequency trading, real‑time bidding, or massive pub/sub workloads still justify a dedicated Redis layer.