For a long time, Redis has been a default part of any serious Ruby on Rails architecture. It has powered critical components such as background job processing, application caching, and real-time updates. In most production environments, Redis was not something teams actively evaluated; it was simply assumed to be part of the stack, forming an essential layer alongside the database and application server.

With Rails 8, that long-standing assumption is now being challenged. The introduction of the Solid Trifecta Solid Queue, Solid Cache, and Solid Cable marks a shift in how Rails applications can be designed. Instead of relying on an external system like Redis, Rails now offers built-in solutions that move these responsibilities directly into the primary database.

This change is not about completely replacing Redis but about rethinking when and why it is needed. Rails 8 enables a simplified, database-first architecture where teams can start with fewer dependencies and less operational overhead. Redis becomes optional rather than mandatory, allowing developers to scale their infrastructure more intentionally, based on real application needs rather than default assumptions.

The Traditional Rails Stack: Effective but Heavy

The traditional Ruby on Rails production stack typically consists of an application server, a PostgreSQL or MySQL database, a Redis instance, background workers such as Sidekiq, and supporting monitoring and logging tools. While this architecture is well-proven and highly scalable, it also introduces a level of complexity that many applications do not immediately require, especially in their early stages.

The Hidden Cost of “Standard” Infrastructure

Operational Overhead

Each additional component requires:

• Setup and configuration
• Monitoring and alerting
• Scaling and maintenance

For early-stage products, this increases engineering effort without directly impacting product value.

Fragmented System Design

Responsibilities are split across systems:

• Jobs → Redis
• Cache → Redis
• Data → Database

This separation makes debugging slower and increases system complexity.

Infrastructure Costs

Redis is memory-based:

• More expensive than disk-based systems
• Requires replication for reliability
• Often over-provisioned to avoid performance issues

For many applications, this cost is avoidable at the start

Rails 8’s Approach: Simplifying the Architecture

Rails 8 adopts a database-first approach where background jobs, caching, and real-time messaging are handled directly within the database. This reduces external dependencies like Redis, simplifies system architecture, and enables teams to build and scale applications with fewer moving parts and lower operational complexity.

Why This Works Now

This approach is practical today because:

• Modern databases handle concurrency efficiently
• NVMe SSDs reduce disk latency significantly
• Most applications do not require extreme throughput initially

The result:

Fewer moving parts. Lower overhead. Easier scalability.

Solid Queue: Reliable Background Jobs

Solid Queue replaces Redis-based job processors by using the database as the queue.

It uses SQL mechanisms like row-level locking to ensure safe concurrent job processing.

Transactional Integrity: The Key Advantage

A common issue in traditional setups is race conditions.

The Problem

Order.create!(...)

OrderMailer.receipt.deliver_later

If the job is triggered before the transaction completes:

• The job may execute
• The data may not exist

The Solid Queue Solution

def create

  ActiveRecord::Base.transaction do

    @order = Order.create!(order_params)

    # Job is part of the same transaction

    OrderMailer.with(order: @order).receipt.deliver_later

  end

  redirect_to @order, notice: "Order placed!"

end

Result:

• Jobs and data are committed together
• No inconsistent states
• Better reliability for critical workflows

Trade-offs

• Lower throughput compared to Redis
• Increased load on the database

For most applications, the gain in reliability outweighs the performance trade-off.

Solid Cache: Persistent Caching Without Redis

Solid Cache replaces in-memory caching with database-backed storage.

config.cache_store = :solid_cache_store, {

  max_age: 2.weeks,

  max_size: 1.gigabyte

}

Benefits

Solid Cache in Rails 8 offers a reliable, cost-effective alternative by ensuring persistence, stability, and efficient storage for modern applications.

Persistence : Cache data remains intact even after application restarts, eliminating cold-start delays. This ensures consistent performance, reduces recomputation overhead, and improves user experience by maintaining previously stored results.

Cost Efficiency: Using disk storage instead of RAM significantly lowers infrastructure costs. It allows storing larger datasets without expensive memory allocation, making it ideal for applications with heavy caching requirements.

Stability: Unlike memory-based systems, disk-backed caching avoids sudden eviction due to memory pressure. This ensures predictable behavior, consistent performance, and reduces risks of cache-related failures in production environments.

Example

def total_sales_stats

  Rails.cache.fetch("vendor_stats_#{id}", expires_in: 24.hours) do

    orders.completed.sum(:total_amount)

  end

end

Trade-offs

• Disk-based caching is slower than RAM
• Not ideal for high-frequency read scenarios

Redis still performs better for ultra-low latency needs.

Solid Cable: Real-Time Without External Dependencies

Solid Cable replaces Redis Pub/Sub with database-backed messaging.

after_update_commit -> {

  broadcast_replace_to "inventory",

    target: "product_#{id}_stock",

    partial: "products/stock_count"

}

Benefits

• No external messaging system
• Simplified deployment
• Easier debugging and traceability

Trade-offs

• Not suited for high-frequency real-time applications
• Less efficient at large scale

The Trade-Off: Database as the Core System

With the Solid Trifecta, the database becomes the central component.

What to Monitor

• CPU usage
• Query latency
• Disk I/O

If your database is under constant heavy load, it may become a bottleneck.

When Redis Still Makes Sense

Redis remains valuable for:

• High-throughput job processing
• Low-latency caching
• Large-scale real-time systems

The key is to use Redis when your application needs it, not by default.

Bluetick’s Recommended Approach

At Bluetick Consultants, we suggest a practical adoption strategy:

Start Simple

• Use the Solid Trifecta
• Avoid unnecessary infrastructure
• Focus on building core product features

Monitor Early

Track:

• Database performance
• Job processing time
• Cache efficiency

Scale Based on Real Usage

Introduce Redis only when:

• Performance bottlenecks appear
• Throughput requirements increase
• Latency becomes critical

Keep Flexibility

Rails 8 allows easy switching:

config.active_job.queue_adapter = :sidekiq

config.cache_store = :redis_cache_store

This ensures scaling decisions are reversible and low-risk.

Rails 8 and the Shift Toward Database-First Design

Rails 8 reshapes how applications are built by reducing early dependence on external systems like Redis. Teams can begin with a simpler, database-centric setup, lowering complexity and operational effort. As applications grow, infrastructure can evolve based on actual demands. This approach promotes clarity, efficiency, and flexibility, allowing developers to introduce tools like Redis only when they genuinely add value.

Bluetick Consultants helps organizations build scalable digital products, implement AI-driven solutions, and design modern, efficient architectures.

If you’re evaluating Rails 8 or planning to simplify your infrastructure, our team can help you choose the right approach based on your product and scale requirements.