January 14, 2026
Queue the breakup
I Love You, Redis, but I'm Leaving You for SolidQueue
Rails 8 moves in with its database—fans cheer, skeptics warn about scaling
TLDR: Rails 8 drops Redis for built-in features that run on the existing database, promising simpler setups. Comments split between “finally, less ops!” and warnings about reliability and high-scale limits, with many urging: start with the simple path, but keep an easy way to switch back to Redis.
It’s a breakup letter with a plot twist: Rails 8 says “bye” to Redis and moves its jobs, caching, and real-time messages into the plain old database you already have. The crowd went wild. Some cheered the “one box to rule them all” vibe—“Postgres will eat the world,” crowed one fan—while others clutched their cache pearls, whispering “is this really safe?” The new trio (SolidQueue, SolidCache, SolidCable) promise fewer moving parts and fewer 3 a.m. server emergencies.
But the comments were pure drama. Reliability hawks like reena wanted receipts: “switching always feels risky,” especially when jobs fail. Pragmatists like jjgreen shrugged: dev has been no stress, why complicate it? Even Redis legend antirez joined the thread, blessing the simplification but urging a safety hatch: keep a “switch back to Redis” option when queues get slammed.
Then came the cautionary tales. A Node team using Graphile Worker—which uses the same database trick that lets workers grab jobs without bumping into each other—reported “serious issues” around 2k–5k jobs per minute. Memes flew: “Relationship status: It’s complicated,” “Monogamy with Postgres,” and “single point of uh-oh” jokes, since if the database goes down, everything stops. Fans love ditching extra servers; skeptics fear rush-hour traffic. The mood: start simple, but don’t burn the Redis bridge.
Key Points
- •Rails 8 removes Redis from its default stack, introducing SolidQueue, SolidCache, and SolidCable that run on the application’s relational database.
- •The article outlines Redis’s operational overhead, including deployment, monitoring, networking, authentication, HA clustering, process orchestration, and dual backup strategies.
- •SolidQueue implements job queues using PostgreSQL’s FOR UPDATE SKIP LOCKED, allowing multiple workers to claim unique jobs without blocking.
- •A sample SQL query demonstrates workers selecting the next job by priority and job_id, with locks released and execution records deleted upon completion.
- •SolidQueue’s architecture uses three tables—jobs, scheduled executions, and ready executions—and can run on PostgreSQL, SQLite, or MySQL.