Depuis des années, Redis est un passage obligé de toute application Ruby on Rails sérieuse. Files d'attente, cache distribué, WebSockets en temps réel : tout transitait par ce serveur en mémoire. Pratique, certes, mais Redis représente un service supplémentaire à provisionner, à surveiller et à financer. Rails 8, sorti fin 2024, change la donne en profondeur. La Solid Trifecta — Solid Queue, Solid Cache et Solid Cable — apporte des solutions basées sur SQLite ou votre base de données relationnelle existante. Plus besoin d'un serveur Redis dédié pour la majorité des applications. Cette évolution majeure réduit la complexité opérationnelle, diminue les coûts d'infrastructure et accélère les déploiements. Que vous développiez une application métier, une plateforme SaaS ou un MVP, comprendre la Solid Trifecta est désormais incontournable. Voici un guide complet pour adopter ces trois gems en production.
Pourquoi Rails 8 abandonne Redis par défaut
Le problème de la dépendance Redis
Redis est rapide. Mais chaque service supplémentaire dans votre stack est un point de défaillance potentiel. Pour une startup ou une PME, gérer un cluster Redis ajoute de la complexité opérationnelle et du coût mensuel. Sur AWS ElastiCache, un nœud Redis moyen coûte entre 30 et 150 € par mois selon la taille. Sur Heroku, la facture grimpe vite.
DHH et l'équipe Rails ont posé une question simple : les bases de données relationnelles modernes peuvent-elles remplacer Redis pour 80 % des cas d'usage ? La réponse, en 2024, est oui — grâce aux avancées de SQLite et PostgreSQL.
La philosophie « One Person Framework »
Rails 8 pousse à son maximum la vision du One Person Framework. L'objectif : permettre à un seul développeur de gérer une application complète en production sans une équipe DevOps dédiée. Supprimer Redis par défaut s'inscrit parfaitement dans cette philosophie.
« La meilleure infrastructure est celle que vous n'avez pas à gérer. » — DHH, RailsWorld 2024
SQLite en production : le changement de paradigme
Rails 8 réhabilite SQLite pour la production. Grâce à Litestack et aux optimisations de SQLite 3.45+, les performances sont désormais suffisantes pour de nombreuses applications. WAL mode, connexions concurrentes et journalisation améliorée changent tout. La Solid Trifecta exploite ces capacités nativement.
Un écosystème de gems mûr et testé
Solid Queue, Solid Cache et Solid Cable ne sont pas des expériences. Basecamp et Hey.com, deux applications de référence du monde Rails, les utilisent en production depuis leur sortie. Ce sont des gems battle-tested avec des milliers de requêtes par seconde en charge réelle.
Solid Queue : les jobs en background sans Redis
Comment fonctionne Solid Queue
Solid Queue est le remplaçant natif de Sidekiq Redis-backed dans Rails 8. Il stocke les jobs dans votre base de données principale (ou une base SQLite dédiée). Chaque job est une ligne en base. Les workers interrogent cette table via des requêtes SQL optimisées avec SELECT FOR UPDATE SKIP LOCKED, une fonctionnalité disponible sur PostgreSQL et MySQL depuis plusieurs années.
Cette approche élimine le besoin de Redis tout en garantissant la persistance des jobs. Contrairement à Redis, si votre serveur redémarre, les jobs en attente ne sont pas perdus.
Configuration et activation dans Rails 8
Dans un projet Rails 8 neuf, Solid Queue est activé par défaut. Dans un projet existant, l'intégration prend moins de 10 minutes :
- Ajoutez la gem :
gem 'solid_queue'dans votre Gemfile. - Générez les migrations :
bin/rails solid_queue:install:migrations. - Configurez queue_adapter :
config.active_job.queue_adapter = :solid_queue. - Lancez le supervisor :
bin/jobsdémarre automatiquement les workers.
Solid Queue vs Sidekiq : comparaison honnête
| Critère | Solid Queue | Sidekiq (Redis) |
|---|---|---|
| Dépendance externe | Aucune (base SQL) | Redis obligatoire |
| Persistance des jobs | Oui (SQL) | Optionnelle (Sidekiq Pro) |
| Débit maximal estimé | ~1 000 jobs/s | ~10 000 jobs/s |
| Coût infrastructure | 0 € supplémentaire | 30-150 €/mois (Redis) |
| Complexité de setup | Très faible | Moyenne |
| Dashboard natif | Mission Control | Sidekiq Web |
Mission Control : le dashboard intégré
Rails 8 embarque Mission Control Jobs, une interface web montée directement dans votre application. Vous visualisez les queues, les jobs en erreur et les performances sans outil tiers. Pour des applications traitant moins de 500 000 jobs par jour, Solid Queue + Mission Control est largement suffisant.
Solid Cache et Solid Cable : cache et temps réel natifs
Solid Cache : le cache sur disque qui surprend
Solid Cache remplace Redis comme backend de ActiveSupport::Cache. Il stocke les entrées de cache dans une base SQLite ou SQL dédiée. Le principe peut sembler contre-intuitif — le cache sur disque, plus lent que la mémoire — mais les benchmarks montrent des résultats surprenants.
Sur un SSD NVMe moderne, Solid Cache atteint des latences de 0,5 à 2 ms par lecture. Redis en local tourne à 0,1 ms. La différence est réelle mais négligeable pour 95 % des cas d'usage réels. En revanche, Solid Cache offre une capacité de stockage quasi illimitée sans surcoût mémoire. Notre agence Ruby on Rails peut auditer et implémenter la Solid Trifecta adaptée à votre infrastructure.
« Solid Cache stocke 10 fois plus de données que Redis pour le même coût, car le disque est bien moins cher que la RAM. » — Nick Rees, core contributor Rails
Configuration de Solid Cache
L'activation se fait en deux étapes dans config/environments/production.rb :
- Définissez le store :
config.cache_store = :solid_cache_store. - Configurez l'expiration : paramètre
expiry_timepour le TTL automatique. - Optionnel : base de données dédiée pour isoler le cache de vos données métier.
Pour des projets Rails nécessitant une gestion du cache avancée, notre équipe peut vous accompagner. Contactez Akolads pour un audit de votre stack.
Solid Cable : Action Cable sans Redis
Solid Cable remplace l'adapter Redis d'Action Cable. Il utilise la base de données pour propager les messages entre les instances de votre application. Pour des applications avec moins de 1 000 connexions WebSocket simultanées, Solid Cable est parfaitement adapté.
La configuration est minimale. Dans config/cable.yml, remplacez l'adapter Redis par :
- Adapter :
solid_cable - Polling interval : 0,1 seconde par défaut (configurable)
- Database : votre base principale ou une base dédiée
Limites à connaître avant d'adopter Solid Cable
Solid Cable utilise le polling SQL, pas un mécanisme pub/sub natif comme Redis. La latence est légèrement supérieure : 100 à 200 ms contre moins de 10 ms avec Redis. Pour des applications de chat en temps réel haute fréquence ou des flux de données financières, Redis reste préférable. Pour des notifications, des mises à jour de statut ou des dashboards, Solid Cable excelle.
Migrer de Redis vers la Solid Trifecta en production
Évaluer votre dépendance Redis actuelle
Avant de migrer, cartographiez tous vos usages Redis. La plupart des applications utilisent Redis pour trois raisons : les jobs background (Sidekiq), le cache (Redis store) et Action Cable. Pour chaque usage, évaluez le volume et la criticité. Si vous traitez plus de 1 million de jobs par jour, conservez Sidekiq. Sinon, Solid Queue suffit.
Pour aller plus loin sur la stratégie de développement Rails, consultez notre guide : Ruby on Rails 2026 : le guide pro pour livrer vite.
Plan de migration en 4 étapes
- Étape 1 — Solid Queue : migrez d'abord les jobs. Installez la gem, créez les tables, redirigez les ActiveJob vers Solid Queue. Gardez Sidekiq actif jusqu'à la fin du drain des queues existantes.
- Étape 2 — Solid Cache : basculez le cache store en production. Testez sur un environnement staging. Le cache est stateless : la migration est sans risque.
- Étape 3 — Solid Cable : mettez à jour config/cable.yml. Testez toutes les fonctionnalités temps réel. La bascule est instantanée.
- Étape 4 — Suppression Redis : une fois les trois gems validées, supprimez Redis de votre infrastructure. Économisez immédiatement sur la facture cloud.
Impact sur les coûts d'infrastructure
Une application Rails typique hébergée sur Fly.io ou Render utilise un nœud Redis à 25-50 USD par mois. Avec la Solid Trifecta, ce coût tombe à zéro. Sur 3 ans, l'économie dépasse 1 800 USD pour une seule application. Pour un portfolio de 5 applications, l'économie annuelle atteint 3 000 USD.
Ces économies s'ajoutent à la réduction du temps DevOps. Sans Redis à surveiller, mettre à jour et sécuriser, vos développeurs se concentrent sur la valeur métier. Pour comprendre les coûts globaux d'un projet Rails, lisez notre article : Prix Ruby on Rails 2026 : guide complet et tarifs.
Bonnes pratiques pour la Solid Trifecta en production
Quelques recommandations issues du terrain :
- Base dédiée pour le cache : isolez Solid Cache dans une base SQLite séparée pour éviter les conflits d'I/O avec vos données métier.
- Monitoring SQL : ajoutez des alertes sur la taille des tables Solid Queue. Une queue qui grossit sans se vider indique un problème de workers.
- TTL agressif : configurez des TTL courts sur Solid Cache (24h maximum) pour éviter une croissance non contrôlée du fichier SQLite.
- Backups réguliers : contrairement à Redis, vos jobs et cache sont maintenant dans des fichiers SQL. Incluez-les dans votre stratégie de backup.
FAQ
Rails 8 Solid Queue peut-il remplacer Sidekiq en production ?
Pour la majorité des applications traitant moins d'1 million de jobs par jour, Solid Queue remplace avantageusement Sidekiq. Il offre la persistance native, un dashboard intégré (Mission Control) et zéro dépendance externe.
Pour des volumes très élevés ou des besoins avancés comme le rate limiting ou les queues prioritaires complexes, Sidekiq Pro reste une option pertinente.
Solid Cache est-il vraiment plus lent que Redis ?
Oui, légèrement : 0,5 à 2 ms de latence contre 0,1 ms pour Redis local. Mais cette différence est imperceptible pour l'utilisateur final dans la quasi-totalité des cas.
En revanche, Solid Cache offre une capacité de stockage bien supérieure et un coût nul. Pour des applications avec de gros volumes de cache, c'est souvent un meilleur choix global.
Solid Cable supporte-t-il les applications temps réel complexes ?
Solid Cable convient aux notifications, mises à jour de statut et dashboards avec moins de 1 000 connexions simultanées. Sa latence de 100 à 200 ms est acceptable pour ces cas.
Pour des applications de trading, de chat haute fréquence ou des jeux multijoueurs, Redis reste recommandé pour sa latence inférieure à 10 ms.
Comment migrer de Redis vers la Solid Trifecta sans interruption de service ?
La migration se fait en 4 étapes progressives : Solid Queue d'abord (en parallèle avec Sidekiq), puis Solid Cache (stateless, migration sans risque), puis Solid Cable, et enfin la suppression de Redis.
Chaque étape peut être déployée indépendamment. Il n'y a pas de migration en une seule fois obligatoire.
La Solid Trifecta fonctionne-t-elle avec PostgreSQL ou seulement SQLite ?
La Solid Trifecta fonctionne avec SQLite, PostgreSQL et MySQL. Vous pouvez utiliser votre base de données principale ou des bases dédiées pour chaque composant.
SQLite est recommandé pour les petits projets et les déploiements mono-serveur. PostgreSQL est préférable pour les architectures distribuées multi-serveurs.
![Prix Ruby on Rails 2026 : guide complet et tarifs [Pro]](../../assets/images/blog/developpement-et-gestion-financiere.jpg)
