Rails 8 Solid Stack: When to Remove Redis
Guides for deciding which Rails 8 defaults to adopt: Solid Queue, Solid Cache, Kamal, the built-in authentication generator, and Hotwire. Removing Redis is a good outcome only when Redis was not carrying queue latency, locks, pub/sub, rate limiting, or a hot cache path the database cannot absorb.
REDIS ONLY RUNS JOBS
Start with the Sidekiq migration runbook. Inventory queues, retries, scheduled jobs, and pickup-latency requirements before changing the adapter.
REDIS IS THE CACHE
Read the Solid Cache guide only after checking database headroom, cache churn, write amplification, and eviction behavior.
REDIS POWERS COORDINATION
Keep Redis when it provides pub/sub, distributed locks, rate limiting, or Sidekiq Pro and Enterprise features. Rails defaults do not replace those one-for-one.
DEPLOYS ARE THE PAIN
Start with Kamal and rollback checks. A queue migration will not fix missing health checks, migration sequencing, or weak deploy visibility.
Solid Queue in Rails 8: Setup Notes and Trade-offs
Install Solid Queue, configure workers and recurring jobs, choose Puma or a separate jobs process, and identify the Redis features you would lose.
Sidekiq to Solid Queue Migration
A zero-downtime runbook for moving jobs, retries, schedules, and monitoring, with rollback if retry semantics or latency drift.
Solid Queue Recurring and Cron Jobs
Recurring.yml, Fugit syntax, scheduler processes, time zones, staging flags, invalid schedules, and at-least-once job bodies.
Solid Queue vs Sidekiq vs GoodJob
Throughput, pickup latency, retry behavior, feature gaps, and the cases where the Rails default is not the right answer.
Solid Cache in Rails 8
Database-backed caching, write load, eviction behavior, capacity planning, and when a hot Redis cache should stay.
Rails 8 Authentication Generator
Sessions, password resets, email confirmation, rate limiting, and owning the authentication code.
Hotwire and Turbo in Rails
Server-rendered interactivity patterns with Turbo Frames, Turbo Streams, and Stimulus.
Do Not Remove Redis When...
- Sidekiq Pro or Enterprise features are part of the product contract: batches, reliable fetch, unique jobs, or rate limiting.
- The app depends on Redis pub/sub, distributed locks, counters, or request-time rate limits outside Action Cable.
- Queue pickup latency needs to stay in the low-millisecond range under burst load.
- The cache is write-heavy and moving churn into PostgreSQL would compete with the primary application workload.
- The team already operates Redis well and the real failure mode is deploy sequencing, missing observability, or unclear ownership.