Solid Trifecta: When to Keep Redis in Rails 8

By JetThoughts Team - April 13, 2026 - 9 min read

Redis is the most expensive line item on most Rails infrastructure bills. And since Rails 8, it’s optional.

Solid Cache, Solid Queue, and Solid Cable - the “Solid Trifecta” - replace Redis for caching, background jobs, and WebSockets. All three are database-backed and ship as defaults in new Rails 8 apps. 37signals runs Solid Cache in production across Basecamp and HEY, handling what used to require 1.1 terabytes of Redis RAM with 80 gigabytes of database storage. That’s an 80% infrastructure cost reduction.

Whether you can drop Redis and whether you should are different questions. We’ve migrated four production apps to the Solid stack in the past six months. Two went fully Redis-free. Two kept Redis for specific workloads. Here’s the decision framework we use.

What Each Component Replaces #

Each component targets a specific Redis use case:

Solid Cache replaces redis_cache_store. It stores cache entries in a dedicated database table instead of Redis memory. The tradeoff: reads are roughly 40% slower than Redis, but the cache can be 6x larger because disk is cheaper than RAM. For most Rails apps - where cached values are HTML fragments, serialized JSON, or computed reports - single-digit millisecond latency is invisible to users.

Solid Queue replaces Sidekiq and Resque for background job processing. It uses FOR UPDATE SKIP LOCKED for efficient polling - no Redis pub/sub needed. 37signals introduced it in production at HEY, processing millions of jobs daily. For apps under 100 jobs/second, it performs identically to Sidekiq in wall-clock terms. The difference shows up above that threshold.

Solid Cable replaces Redis as the Action Cable adapter. It polls the database for new messages instead of using Redis pub/sub. This works well for live notifications, dashboard updates, and internal tool chat. It does not work well for sub-10ms delivery requirements - multiplayer games, collaborative editing, high-frequency trading dashboards.

Keep Redis or Drop It: Three Questions Per Component #

For each component, there’s a short list of deal-breakers. Hit any of them and Redis stays.

Solid Cache #

The main question is throughput. If your app reads cache more than 10,000 times per second, Solid Cache’s 1-2ms PostgreSQL overhead adds up - 10-20 extra seconds of cumulative latency across your request pool. Below that? You won’t notice.

The second question is sneakier. If you use Redis as a data structure server - sorted sets for rate limiting, HyperLogLog for cardinality estimates, Lua scripts for atomic operations - Solid Cache can’t replace any of that. It’s a key-value store. The cache, yes. The data structures, no.

There’s also a write pressure concern that bit us on one migration. Very short-lived cache entries (TTL under 60 seconds) generate constant INSERTs and DELETEs. Redis handles this in memory with zero disk I/O. Your PostgreSQL instance will feel every one of those writes.

For everything else - fragment caching, page caching, API response caching, session storage - Solid Cache works. We’ve written a full migration guide with benchmarks.

Solid Queue #

Throughput is the obvious question here too. Each enqueue is a database INSERT, each dequeue is a SELECT plus UPDATE. Under 100 jobs/second, you won’t notice any difference from Sidekiq’s in-memory operations . Above that, the gap is real and measurable.

Latency is the other concern. Solid Queue polls at a configurable interval - default one second. You can push it lower, but polling will never match Redis pub/sub. If your payment webhooks need to fire within 50ms of enqueue, Sidekiq is still faster.

Then there’s the feature question. Solid Queue covers recurring jobs (since 1.0), but Sidekiq Pro’s batches, rate limiting, and unique jobs have years of production hardening that Solid Queue hasn’t matched yet. If you’re paying for Pro and using its features, don’t switch just because database-backed sounds purer.

One more thing most people don’t think about: spiky traffic. Solid Queue handles steady throughput well. A sudden 50x burst - Black Friday, a concert ticket drop - hits the database hard. Redis absorbs spikes in memory. That’s what it was built for.

For apps under 100 jobs/second with tolerance for 1-2 second queue latency? Solid Queue handles it. Our migration guide walks through the move queue by queue.

Solid Cable #

This one is simpler. Solid Cable polls; Redis pushes. If your chat app shows “user is typing” indicators, or you’re building collaborative editing, or anything where 200ms of polling latency feels broken - keep Redis. (Or look at AnyCable for even better performance.) At 10,000+ concurrent WebSocket connections, each poll is a database query - that’s 50,000 SELECTs per second at a 200ms interval. Redis pub/sub handles the same load with a single publish to all subscribers.

For internal dashboards, admin panels, and notification feeds? Solid Cable is fine.

The Hybrid Architecture That Works #

Most production Rails apps we’ve migrated end up here:

# config/environments/production.rb

# Solid Cache for general caching (HTML fragments, API responses)
config.cache_store = :solid_cache_store

# Solid Queue for most background jobs
config.active_job.queue_adapter = :solid_queue

# Redis ONLY for specific workloads:
# - Rate limiting (sorted sets)
# - Sidekiq Pro batches (if you use them)
# - Action Cable (if >1,000 concurrent connections)

This cuts the Redis bill by 60-80% while keeping it where it earns its cost. You don’t have to choose one or the other. Run Solid Queue for email delivery, report generation, and scheduled tasks. Keep Sidekiq for your payment processing queue where latency matters.

Here’s the configuration for running both:

# app/jobs/application_job.rb
class ApplicationJob < ActiveJob::Base
  # Default: Solid Queue (database-backed)
end

# app/jobs/payment_webhook_job.rb
class PaymentWebhookJob < ApplicationJob
  self.queue_adapter = :sidekiq  # Override: Redis-backed
  queue_as :critical
end

Migration Order: Start With the Lowest Risk #

The safest approach is migrating one component at a time, starting with cache.

Week 1-2: Solid Cache #

Cache is the lowest-risk move. If something goes wrong, you get a cache miss - the app is slower, not broken. Run both cache stores in parallel for a week, comparing hit rates and latency. We wrote about the benchmarks and migration steps in detail.

Week 3-4: Solid Queue (non-critical queues first) #

Begin with email delivery, analytics events, and cleanup jobs. Keep payment processing and time-sensitive webhooks on Sidekiq. Monitor database load - if your connection pool and write throughput can handle it, migrate more queues. Our Solid Queue vs Sidekiq comparison covers the architectural differences.

Week 5+: Evaluate Solid Cable #

This step only applies if you’re using Action Cable and your WebSocket load is modest. Solid Cable has the most noticeable latency difference of the three, so measure before committing.

Track database load at every step #

More Solid components means more database queries. If you’re running PostgreSQL, watch pg_stat_activity for connection counts, pg_stat_user_tables for sequential scans on cache/queue tables, and your overall write throughput. A dedicated database for cache and queue tables keeps that write pressure off your primary instance.

When NOT to Migrate #

Skip the Solid stack when:

If your team is happy with Redis and it costs $50/month, migration has a cost too - leave it alone. There’s no architectural medal for removing a dependency that works. Pre-launch teams should ship the product first and optimize infrastructure after they have traffic to measure; the Solid defaults in new Rails 8 apps are fine for launch, and you can revisit when scaling questions come up. And if your database is already under pressure, adding cache reads, job polling, and WebSocket queries to an overloaded PostgreSQL instance only makes the problem worse. Fix the database first. Consider read replicas or a dedicated queue database before migrating.

Don’t Migrate Everything at Once #

We almost learned this the hard way on migration #2. Moved cache and queue to Solid on the same weekend, didn’t set up a dedicated queue database, and Monday morning the connection pool was exhausted. Rolled back queue, added the separate database, migrated again the following week. No drama - because we’d done cache first and knew the rollback path.

The Solid Trifecta shifts load from Redis to your database. That’s a real architectural tradeoff that requires monitoring and capacity planning . Migrate one component at a time. Measure for a week. Then move the next one.

What We Shipped Last Month #

A client came to us running Rails 7.2 with Redis handling cache, Sidekiq, and Action Cable. Monthly Redis bill: $480. Database: PostgreSQL on RDS.

After migration:

We moved fragment and API response caching to Solid Cache. Cache size went from 2GB (limited by Redis memory) to 50GB (limited by disk - effectively unlimited). Average read latency increased from 0.3ms to 1.1ms. Nobody noticed. P95 page load actually improved because cache hit rate went from 68% to 91% with the larger cache.

Solid Queue took over email delivery, report generation, and scheduled cleanup - 200 jobs/minute, steady, no issues. Active Job Continuations made the long-running import job deploy-safe for the first time.

Sidekiq stayed for the payment webhook queue (needs sub-second latency) and the real-time inventory sync (2,000 jobs/minute bursts during peak hours). Redis also stayed for Action Cable, where 1,200 concurrent WebSocket connections power the admin dashboard.

New monthly Redis bill: $120. Same reliability. Less infrastructure to monitor.

The hybrid approach let us keep Redis only where it earned its cost. We measured each workload, put it where it belonged, and cut the bill by 75%.

Want the same result? We’ve done this migration four times in the past six months. We’ll review your Redis usage, identify which workloads can move, and build the migration plan. Book a technical review - 45 minutes, one senior Rails engineer, a written recommendation.

If you’re planning a Solid stack migration, these are the companion pieces: our Solid Cache benchmarks and migration steps cover the cache move in detail, and the Solid Queue vs Sidekiq comparison digs into the architectural differences. For the deployment side, Kamal in Rails 8 and the Docker production guide round out the stack.