Rails 8 Drops Redis Requirement with Solid Queue, Solid Cache, and Solid Cable

Since the release of Rails 8.0, the framework has offered Solid Queue, Solid Cache, and Solid Cable as replacements for Redis and Sidekiq, using the application's own relational database for queues, cache, and pubsub.

Rails 8.0, whose release notes are documented in the Rails Guides, takes Redis out of the critical path of a Rails application. The three pieces that do this are called Solid Queue, Solid Cache, and Solid Cable, and all three share the same premise: the relational database already running the application can do the work that is currently delegated to a separate service.

For those maintaining Rails apps in production, this isn't just about saving one line in docker-compose.yml. It's one less service to monitor, one less network connection that can drop, one less point of failure outside the database, which already has backup, replication, and observability set up.

Three Pieces, One Backend

Each Solid solves the problem of a specific tool:

• Solid Queue replaces Sidekiq, Resque, or Delayed Job for running background jobs, using Active Job as was already the standard.
• Solid Cache replaces Redis or Memcached for HTML fragment caching and general application caching.
• Solid Cable replaces the Redis adapter for Action Cable, which relays WebSocket messages between different server processes.

All three store their data in the application's same relational database (or, as a common alternative in production, in a database dedicated just to that, configured as an extra role in database.yml). It isn't mandatory to use all three together: you can swap out just the queue and keep Redis as the cache, for example.

How Solid Queue Handles Queuing Without Sidekiq

The technically most interesting part is Solid Queue, because it solves the classic problem of using a relational database as a queue: concurrency. Two workers can't pick up the same job at the same time, and doing this with a SELECT followed by an UPDATE creates a race condition.

Solid Queue's solution is to use FOR UPDATE SKIP LOCKED, a mechanism introduced in PostgreSQL 9.5 and now also available in MySQL 8.0 onward. With SKIP LOCKED, each worker locks the row of the job it's going to process, and the others, instead of waiting for the lock to release, simply skip to the next available row. This eliminates the lock bottleneck without needing retry logic in the application.

The detail that sets Solid Queue apart from alternatives like good_job is that it also works with SQLite, according to the official documentation. This is consistent with another bet Rails 8 is making: small and medium applications running entirely on SQLite, without needing a separate managed Postgres.

In practice, this means replacing Sidekiq's configuration and worker process with a gem of Rails' own, which uses the same jobs table the application already writes to. Those who already use Active Job (most Rails apps) don't need to change the code of the jobs themselves, only the adapter configured in the application.

Solid Cache and Solid Cable: Cache and Pubsub in the Database

Solid Cache solves caching the way Rails has always solved it with Redis or Memcached: key and value, with expiration. The difference is that it uses a dedicated relational database as the backend, with a table indexed by key, for fragment caching and general application caching.

Solid Cable is the boldest of the three because it tackles the use case that traditionally most justified Redis in apps with WebSocket: Action Cable's pubsub. When a Rails app runs across multiple processes or servers, a message published in one process needs to reach clients connected to another, and that requires a broker.

Solid Cable retains the messages sent in the database for a day by default.

Rails Guides, Ruby on Rails 8.0 Release Notes

This means Solid Cable isn't a purely ephemeral pubsub like Redis: messages are persisted for a day (configurable), which has a storage cost, but also provides an audit trail that Redis, being volatile by nature, didn't offer.

The Trade-off: Fewer Pieces, More Load on the Database

Taking Redis out of the stack isn't a free trade-off. Everything that used to go to an in-memory service, optimized for microsecond latency, now goes through the relational database that also serves the application's queries. At high volume, this competes for I/O, connections, and CPU with the main traffic.

In summary: Solid Queue, Solid Cache, and Solid Cable make sense for most small to medium-sized Rails apps, where the operational simplicity of running one less service outweighs Redis's latency advantage. For apps with job volumes in the thousands per second, or WebSocket at scale (many channels, many simultaneous messages), Redis still tends to have a raw throughput advantage.

A practice recommended by those who already adopt these solutions is to configure a separate database (it can be another SQLite file, or another Postgres schema) just for the Solid tables, via config/database.yml with multiple roles. This isolates queue and cache traffic from the application's main database, mitigating some of the contention.

When to Keep Redis

There are scenarios where the switch simply isn't worth it:

1. Very high-frequency jobs, such as real-time event processing or queues receiving thousands of items per second, where the relational database's disk write latency becomes a visible bottleneck.
2. WebSocket with a high volume of simultaneous channels, where the overhead of persisting each message in Solid Cable adds storage costs that Redis never had.
3. Teams that already have a mature Redis setup in production, with observability, alerts, and runbooks in place: switching to something new introduces operational risk that only pays off if the simplicity gain is real.

The central point of this change isn't that Redis got worse. It's that Rails 8 made optional a dependency that used to be nearly mandatory, and that's good mainly for those starting a new project or maintaining a small app that pays for a managed Redis service bill just for a job volume that would comfortably fit in a table.

Source: Rails Guides, Ruby on Rails 8.0 Release Notes (https://guides.rubyonrails.org/8_0_release_notes.html)