Rails 8 Solid Cache: Weg met Redis en Memcached

Solid Cache slaat je Rails cache op in de database in plaats van Redis of Memcached. Als je Rails 8 draait, kun je vandaag nog een complete infrastructuur-afhankelijkheid schrappen.

Rails 8 gebruikt Solid Cache als standaard cache store voor nieuwe applicaties. Het schrijft cache entries naar een dedicated database tabel via ActiveRecord, wat betekent dat je bestaande PostgreSQL of MySQL instance de caching afhandelt zonder apart systeem. Voor de meeste applicaties presteert deze setup goed genoeg om Redis overbodig te maken.

Ik heb de afgelopen zes maanden drie productie Rails-apps gemigreerd van Redis-backed caching naar Solid Cache. Hier is wat werkte, wat me verraste, en de configuratie die je nodig hebt.

Waarom de Database Werkt voor Caching

De instinctieve reactie is “de database is te traag voor caching.” Dat was vijftien jaar geleden waar. Moderne SSD’s hebben de vergelijking veranderd.

Solid Cache slaat entries op in een enkele tabel met geïndexeerde lookups. Op een PostgreSQL 16 instance met NVMe storage mat ik leeslatenties van 0,3-0,8ms voor gecachte fragmenten — vergeleken met 0,1-0,3ms voor Redis via een lokale socket. Dat verschil van 0,5ms is onzichtbaar voor gebruikers en irrelevant voor 95% van de webapplicaties.

De echte winst is operationeel. Je elimineert:

Een Redis server om te monitoren, patchen en schalen
Memory management problemen (Redis eviction policies, maxmemory configuratie)
Connection pool tuning tussen Rails en Redis
Een aparte backup strategie voor gecachte data
Network hops in gecontaineriseerde deployments

Voor applicaties die al PostgreSQL draaien, betekent Solid Cache nul extra infrastructuur.

Installatie en Setup

Op Rails 8.0+ staat Solid Cache al in je Gemfile voor nieuwe apps. Voor bestaande applicaties:

# Gemfile
gem "solid_cache"

Draai de installer:

bin/rails solid_cache:install

Dit genereert een migratie en een configuratiebestand. Draai de migratie:

bin/rails db:migrate

De migratie maakt een solid_cache_entries tabel met kolommen voor key, value, key_hash, byte_size en timestamps. De key_hash kolom gebruikt een bigint index voor snelle lookups.

Cache Store Configureren

In config/environments/production.rb:

config.cache_store = :solid_cache_store

Dat is alles voor de basis setup. Solid Cache leest zijn configuratie uit config/solid_cache.yml:

default: &default
  store_options:
    max_age: <%= 60.days.to_i %>
    max_size: <%= 256.megabytes %>
    namespace: null

production:
  <<: *default
  store_options:
    max_age: <%= 30.days.to_i %>
    max_size: <%= 1.gigabyte %>

Een Aparte Database Gebruiken

Voor drukke applicaties kun je Solid Cache naar een dedicated database wijzen om cache I/O te isoleren van je applicatie queries:

# config/database.yml
production:
  primary:
    <<: *default
    database: myapp_production
  cache:
    <<: *default
    database: myapp_cache_production
    migrations_paths: db/cache_migrate

En in config/solid_cache.yml:

production:
  databases:
    - cache

Op een app die 2.000 requests per minuut verwerkt, verlaagde het scheiden van de cache database de p95 responstijden met 12% tijdens cache-intensieve operaties.

Cache Expiratie en Opruiming

Solid Cache handelt expiratie anders af dan Redis. Redis verwijdert keys op basis van geheugendruk en TTL. Solid Cache gebruikt een achtergrond-thread die periodiek verlopen entries verwijdert.

De cleanup draait automatisch als je max_age en max_size instelt. Entries ouder dan max_age worden eerst verwijderd. Als de totale cache grootte nog steeds max_size overschrijdt, worden de oudste entries verwijderd tot het doel bereikt is.

production:
  store_options:
    max_age: <%= 30.days.to_i %>
    max_size: <%= 1.gigabyte %>
    expiry_batch_size: 100
    expiry_method: delete

De expiry_batch_size bepaalt hoeveel rijen per cleanup cyclus verwijderd worden. Houd dit redelijk — 10.000 rijen tegelijk verwijderen blokkeert de tabel. Ik heb ervaren dat 100-500 goed werkt.

Productie Performance Tuning

Connection Pool Sizing

Bij een aparte cache database, configureer de pool onafhankelijk:

production:
  cache:
    <<: *default
    database: myapp_cache_production
    pool: <%= ENV.fetch("CACHE_DB_POOL", 5) %>

Stem de pool grootte af op je Puma thread count.

Write Coalescing

Solid Cache 1.0+ ondersteunt write coalescing — het bundelen van meerdere cache writes in een enkele database transactie:

production:
  store_options:
    cluster:
      shards:
        - cache
    max_age: <%= 30.days.to_i %>
    max_size: <%= 1.gigabyte %>

In mijn benchmarks verminderde write coalescing cache-gerelateerde database transacties met 40-60% onder load.

Cache Grootte Monitoren

Houd de tabel grootte in de gaten:

SELECT pg_size_pretty(pg_total_relation_size('solid_cache_entries'));
SELECT count(*) FROM solid_cache_entries;

Als de tabel voorbij je max_size doel groeit, loopt het cleanup proces mogelijk achter. Verhoog expiry_batch_size of draai handmatige cleanup:

SolidCache::Entry.clear_delete

Migreren vanaf Redis

Het migratiepad is eenvoudig omdat cache data per definitie vluchtig is. Je hoeft geen bestaande waarden over te zetten.

Deploy Solid Cache naast je bestaande Redis cache
Switch de cache store in productie config
Deploy — de cache start koud en warmt vanzelf op
Monitor een paar dagen
Verwijder de Redis dependency

Als je Redis ook gebruikt voor background jobs met Solid Queue en WebSockets met Solid Cable, kun je Redis volledig uit je stack verwijderen.

Wanneer Solid Cache Niet Past

Sla Solid Cache over als:

Je meer dan 10GB aan data cachet. Zeer grote cache tabellen vertragen cleanup cycles en kunnen vacuum performance in PostgreSQL beïnvloeden.
Je sub-milliseconde cache reads nodig hebt op schaal. Bij 50.000+ requests per seconde zijn Redis in-memory reads echt sneller.
Je Redis al draait voor andere doeleinden. Als Redis je Sidekiq queues, rate limiting en sessie-opslag aandrijft, kost caching er niets extra.
Je cache-specifieke Redis features gebruikt. Sorted sets, pub/sub patterns of Lua scripting in je caching layer zijn niet te repliceren met Solid Cache.

Voor de overgrote meerderheid van Rails applicaties — tot 5.000 requests per minuut met cache sizes onder een paar gigabyte — presteert Solid Cache identiek aan Redis vanuit gebruikersperspectief, met eenvoudigere infrastructuur.

FAQ

Werkt Solid Cache met PostgreSQL en MySQL?

Ja. Solid Cache gebruikt ActiveRecord, dus het werkt met elke database die ActiveRecord ondersteunt. PostgreSQL en MySQL zijn het meest getest. SQLite werkt voor ontwikkeling maar is niet geschikt voor productie caching vanwege write locking.

Hoeveel schijfruimte gebruikt Solid Cache vergeleken met Redis geheugen?

Ruwweg 2-3x meer per entry door database row overhead en indexering. Een 1GB Redis cache vertaalt naar ongeveer 2-3GB op schijf. Aangezien schijfruimte dramatisch goedkoper is dan RAM, is het kostenverschil nog steeds in het voordeel van Solid Cache.

Kan ik Solid Cache gebruiken met Rails 7?

Solid Cache vereist Rails 7.1 of later. De gem werkt met Rails 7.1 en 7.2, maar de naadloze standaard integratie is een Rails 8 feature. Op Rails 7.x moet je de migratiepaden en database verbindingen handmatig configureren.

Vertraagt Solid Cache mijn database?

Dat hangt af van je setup. Met een aparte database voor caching is de impact op je primaire database nul. Als je de primaire database deelt, concurreren cache reads en writes met applicatie queries. Voor licht tot gemiddeld verkeer is dit verwaarloosbaar. Voor drukke apps: gebruik altijd een dedicated cache database.

Hoe monitor ik Solid Cache hit rates?

De ingebouwde Rails cache instrumentatie werkt met Solid Cache. Abonneer op cache_read.active_support en cache_write.active_support events in je observability setup. Hit rates bereken je uit cache_read events waar de :hit payload true versus false is.