Rails 8 preview: Solid Queue, Solid Cache, and no Redis

For most of the last decade, a production Rails app has had a standard supporting cast: Postgres for the database, and Redis for the things Postgres supposedly couldn’t do well — background job queues (Sidekiq), caching, and so on. “Rails plus Postgres plus Redis” became so reflexive that few people questioned it. Rails 8, due to land soon, ships a quietly radical proposition: you might not need Redis anymore. A family of libraries under the “Solid” name — Solid Queue for background jobs and Solid Cache for caching — move those workloads back into your database, and the new-app defaults are being built around them. This is a preview of what the Solid libraries actually do, why the “just use Postgres” instinct keeps winning, and the honest question of when the old Redis answer still applies.

The stack Rails 8 is trying to collapse

To see what’s changing, name the thing being changed. The conventional Rails production stack has at least three stateful pieces:

Postgres — your primary database, holding your application data.
Redis — an in-memory data store, used as the backend for background-job queues (most commonly via Sidekiq), for caching, and often for other ephemeral state.
And the operational weight of running, monitoring, securing, and backing up both of those independent systems.

Redis earned its place: it’s fast, and a decade ago the database-backed job and cache options were genuinely worse. But every additional piece of stateful infrastructure is a permanent tax — another thing to provision, monitor, secure, upgrade, and reason about when something breaks. Rails 8’s bet is that for a great many apps, that second datastore is no longer worth its weight, because the database can now do those jobs well enough. The Solid libraries are how it makes good on that bet.

Solid Queue: background jobs in the database

Solid Queue is a database-backed Active Job backend — a job queue that stores its jobs in your relational database instead of Redis. You enqueue jobs exactly as you always have through Active Job; the difference is purely where they live and how they’re processed. The jobs sit in database tables, and Solid Queue’s worker processes pull and run them.

The argument for it is the one this series keeps making: operational simplicity through consolidation. With Solid Queue, your jobs live in the same database as your application data, which buys real things:

One datastore instead of two. No separate Redis to run, monitor, secure, and back up purely for the job queue. For a small team, deleting an entire piece of infrastructure is a meaningful reduction in operational surface.
Transactional enqueueing. Because the jobs are in your database, you can enqueue a job in the same transaction as the data change that triggers it. Either both commit or neither does — which neatly eliminates a classic class of bug where the data commits but the Redis enqueue fails (or vice versa), leaving the two stores inconsistent. With the queue in the database, that whole inconsistency window closes.
The same backups and tooling. Your jobs are backed up by your database backups, inspectable with the SQL tools you already use. There’s no second system with its own operational model.

Solid Queue is designed to handle substantial job volumes, and modern Postgres is more than capable of backing a job queue for the vast majority of applications. Sidekiq-on-Redis is still faster at extreme throughput — but “extreme” is the operative word, and most apps never approach it.

Solid Cache: caching in the database

Solid Cache applies the identical idea to caching: it’s a database-backed cache store. At first glance this sounds backwards — isn’t the whole point of a cache that it’s faster than the database you’re caching in front of? The insight that makes it work is that Solid Cache is designed around disk storage and modern hardware, and that for many caching needs the database, properly used, is fast enough — while the dramatically larger capacity of disk-backed storage means you can cache far more than fits in an in-memory store, often improving hit rates enough to offset the per-lookup difference. It’s a different point on the speed/capacity curve, and for a lot of apps it’s the better point — and again, it’s one fewer system to run.

Why “just use Postgres” keeps winning

There’s a clear through-line in Rails’ recent direction, and it’s worth naming because it’s a genuine philosophy, not just a feature: prefer fewer moving parts; reach for the database before reaching for another system. This is the same instinct behind “Postgres for everything” that runs through so much of what I’ve written — handle queues, caching, full-text search, and more in the database you already run, rather than adding specialized infrastructure for each. The payoff is operational: fewer datastores means less to operate, less to break, fewer consistency boundaries to coordinate across, and a smaller team can run the whole thing. For the one-person framework ethos Rails has leaned into, removing Redis from the default stack is squarely on-mission — it’s one less thing standing between a developer and a deployed, maintainable app.

It’s worth being clear that this is a default shifting, not a capability being removed. Rails 8 makes the database-backed options the out-of-the-box path so that a new app needs only Postgres to run queues and caching — but you remain entirely free to use Redis and Sidekiq, and for some apps you still should.

When the old answer still applies

In keeping with every honest “should you adopt this” in this series: the Solid libraries are the right default, not a universal mandate. Redis still wins in specific cases, and you should reach for it deliberately when you have the reason:

Extreme job throughput. If you genuinely process a very high volume of jobs where Redis’s in-memory speed materially matters, Sidekiq-on-Redis remains the stronger choice. But measure first — most apps that assume they need this don’t.
Caching that truly needs in-memory latency. If you have a hot cache path where the difference between in-memory and disk-backed lookup actually shows up in your metrics, a memory cache is right. Again: measure, don’t assume.
You already run Redis well for other reasons. If Redis is in your stack serving needs the Solid libraries don’t cover, the consolidation argument is weaker.

The decision is the familiar match-the-tool-to-the-need one. Default to the Solid libraries and enjoy the collapsed stack; keep Redis when a measured requirement justifies the extra infrastructure. What you shouldn’t do is reflexively add Redis to a new Rails 8 app out of habit, paying for a second datastore you no longer need.

Verdict

Rails 8’s quietly radical idea is that the reflexive “Rails plus Postgres plus Redis” stack can collapse: Solid Queue moves background jobs into your database and Solid Cache moves caching there too, and the new-app defaults are built around them so a fresh Rails app needs only Postgres. The payoff is the operational simplicity this series keeps returning to — one stateful system instead of two, transactional enqueueing that closes a classic consistency gap, the same backups and tooling for everything, and a stack a small team can actually run. It’s the “just use Postgres / one-person framework” philosophy made into a default, and for the great majority of apps it’s the right default: modern Postgres is more than capable of backing queues and caching at the volumes most applications actually see. The old Redis answer still applies in specific, measured cases — extreme job throughput, a cache path that genuinely needs in-memory latency, or a Redis you already run well — and there you should keep it. But the reflex to add Redis to every Rails app has had its day. Default to the Solid stack, delete the datastore you no longer need, and reach for Redis only when a real requirement, not habit, puts it back on the table.