💾

Solid Cache (Rails)

SSD instead of Redis — database-based Rails cache store

GitHub: rails/solid_cache

Solid Cache is a DB-based cache store created by 37signals. It starts from a simple observation: "RAM is expensive, SSD is cheap." By using SSD (several TB) instead of Redis's memory limits (several GB), you can maintain a much larger cache at much lower cost.

Please refer to the Korean version for the detailed architecture analysis, including: the core idea of storing cache entries as DB table rows, the solid_cache_entries schema, cache read/write operations, the write-frequency-proportional probabilistic expiration mechanism (EXPIRY_MULTIPLIER = 2), Maglev consistent hashing for sharding, configuration options, and the Redis vs Solid Cache comparison.

Trade-off: Slightly slower (ms level), but can operate much larger caches at much lower cost. In most Rails apps, this difference is imperceptible.

Architecture Diagram

Cache Storage Structure

💾 solid_cache_entries entry.rb ↗
key string
Cache key
key_hash int64
SHA256 → signed int
value blob
Serialized value
byte_size integer
Value size (for expiry)
INDEX: key_hash (lookup) / ID order = time order (expiry)
Key point: Fast lookup with <strong>key_hash</strong> + FIFO expiry by <strong>ID order</strong> (no created_at index needed)

Cache Read/Write Flow

Write
1. Rails.cache.write('key', value)
↓
2. Entry.write_multi → upsert_all code ↗
↓
3. track_writes → increment counter
↓
Probabilistic expiry trigger? expiry.rb ↗
Read
1. Rails.cache.read('key')
↓
2. Check LocalCache (memory L1 cache)
↓
3. Entry.read_multi → key_hash IN (?)
↓
uncached(dirties: false)
Query cache OFF → always fresh

Expiry Mechanism (Probabilistic, not TTL)

write
write
write
write
50%!
↓ 50% of batch_size reached
expire_later (async) expiration.rb ↗
max_age
Delete if > 2 weeks
max_entries
FIFO delete by ID order
max_size
Size-based delete
EXPIRY_MULTIPLIER = 2 → 2x expiry pressure per write

Redis vs Solid Cache

Redis
Solid Cache
Storage
RAM (expensive)
SSD (cheap)
Cache size
~a few GB
~a few TB
Speed
~0.1ms
~1-5ms
Expiry
TTL-based
Probabilistic FIFO
Ops
Redis server required
DB only
Sharding
Redis Cluster
Maglev Hashing ↗

Sharding (Maglev Consistent Hashing)

Rails.cache.write('user:123', data)
↓
MaglevHash
CRC32('user:123') → table[2053] → shard decision
maglev_hash.rb ↗
↓
Shard 1
cache_db_1
↓
Shard 2
cache_db_2
↓
Shard 3
cache_db_3
Key point: When adding/removing shards, <strong>only minimal keys are redistributed</strong> (consistent hashing)

Key Points

1

Open rails/solid_cache repository on GitHub

2

app/models/solid_cache/entry.rb → analyze cache entry model

3

app/models/solid_cache/entry/expiration.rb → analyze expiration logic

4

lib/solid_cache/store.rb → ActiveSupport::Cache::Store subclass structure

5

lib/solid_cache/store/expiry.rb → write-based probabilistic expiration trigger

6

lib/solid_cache/maglev_hash.rb → analyze consistent hashing implementation

7

lib/solid_cache/connections/ → single DB vs sharding connection management

8

db/migrate/ → check solid_cache_entries table schema

Pros

  • ✓ No Redis needed — simplified operations infrastructure
  • ✓ SSD utilization — much larger cache than RAM
  • ✓ ActiveSupport compatible — use Rails.cache API as-is
  • ✓ Works by default in Rails 8 without separate configuration
  • ✓ Maglev hashing — elegant sharding support
  • ✓ Encryption support — leverages ActiveRecord Encryption

Cons

  • ✗ Slower than Redis (RAM ~0.1ms vs SSD ~1-5ms)
  • ✗ Increased DB load — separate cache DB recommended
  • ✗ Probabilistic expiration — no exact expiry timing like TTL
  • ✗ Redis still advantageous for high-performance real-time systems
  • ✗ Always hits DB due to query cache being disabled

Use Cases

Remove Redis: simplify infrastructure (cache with DB only) Large cache: SSD-based caching up to several TB Self-hosted apps: run without Redis in single-server apps like ONCE Rails.cache.fetch pattern: swap backend without changing existing code Sharding: distribute cache across multiple DBs for performance

Related

💨
Caching
Dramatically improve response speed by reducing repeated computations
→
← 📋 Solid Queue (Rails) 💎 Rails 8 + SQLite — Why It Works in Production →