Rails 8 dispensa Redis com Solid Queue, Solid Cache e Solid Cable

Desde o lançamento do Rails 8.0, o framework oferece Solid Queue, Solid Cache e Solid Cable como substitutos de Redis e Sidekiq, usando o próprio banco relacional para filas, cache e pubsub.

O Rails 8.0, cujas release notes estão documentadas no Rails Guides, tira o Redis do caminho crítico de uma aplicação Rails. As três peças que fazem isso se chamam Solid Queue, Solid Cache e Solid Cable, e todas têm o mesmo pressuposto: o banco relacional que já está rodando a aplicação consegue fazer o trabalho que hoje é delegado a um serviço à parte.

Para quem mantém app Rails em produção, isso não é só economia de uma linha a menos no docker-compose.yml. É menos um serviço para monitorar, menos uma conexão de rede que pode cair, menos um ponto de falha fora do banco que já tem backup, replicação e observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → configurados.

Três peças, um só backend

Cada Solid resolve o problema de uma ferramenta específica:

• Solid Queue substitui Sidekiq, Resque ou Delayed Job para rodar jobs em background, usando Active Job como já era o padrão.
• Solid Cache substitui Redis ou Memcached para cache de fragmentos HTML↳HTML45 conteúdosA importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Como hostear seu site HTML gratuitamente com GitHub PagesDev (Back & Front) · jun 2025SQL Server – Como criar um versionamento de código das suas Stored Procedures em HTML e com comentários da alteraçãoData · nov 2020Ver tudo em Dev (Back & Front) → e cache geral da aplicação.
• Solid Cable substitui o Redis adapter do Action Cable, que relaia mensagens WebSocket entre processos diferentes do servidor.

As três guardam seus dados no mesmo banco relacional da aplicação (ou, como alternativa comum em produção, em um banco dedicado só para isso, configurado como role extra no database.yml). Não é obrigatório usar as três juntas: dá para trocar só a fila e manter o Redis como cache, por exemplo.

Como o Solid Queue sustenta fila sem Sidekiq

A parte tecnicamente mais interessante é o Solid Queue, porque ele resolve o problema clássico de usar banco relacional como fila: concorrência. Dois workers não podem pegar o mesmo job ao mesmo tempo, e fazer isso com SELECT seguido de UPDATE cria condição de corrida.

A solução do Solid Queue é usar FOR UPDATE SKIP LOCKED, mecanismo introduzido no PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → 9.5 e hoje também disponível no MySQL 8.0 em diante. Com SKIP LOCKED, cada worker trava a linha do job que vai processar e os demais, em vez de esperar a trava liberar, simplesmente pulam para a próxima linha disponível. Isso elimina o gargalo de lock sem precisar de lógica de retry na aplicação.

O detalhe que separa Solid Queue de alternativas como good_job é que ele também funciona com SQLite, segundo a documentação oficial. Isso é coerente com outra aposta do Rails 8: aplicações pequenas e médias rodando inteiramente em SQLite, sem precisar de um Postgres gerenciado à parte.

Na prática, isso significa trocar a configuração e o processo de worker do Sidekiq por uma gem própria do Rails, que usa a mesma tabela de jobs que a aplicação já grava. Quem já usa Active Job (a maioria dos apps Rails) não precisa mudar o código dos jobs em si, apenas o adapter configurado na aplicação.

Solid Cache e Solid Cable: cache e pubsub no banco

Solid Cache resolve cache como o Rails sempre resolveu com Redis ou Memcached: chave e valor, com expiração. A diferença é que ele usa um banco relacional dedicado como backend, com uma tabela indexada por chave, para fragment caching e cache geral da aplicação.

Solid Cable é o mais ousado dos três porque ataca o caso de uso que tradicionalmente mais justificava o Redis em apps com WebSocket: o pubsub do Action Cable. Quando um app Rails roda em múltiplos processos ou servidores, uma mensagem publicada em um processo precisa chegar aos clientes conectados em outro, e isso exige um broker.

Solid Cable retains the messages sent in the database for a day by default.

Solid Cable retains the messages sent in the database for a day by default.Rails Guides, Ruby on Rails 8.0 Release Notes

Isso significa que o Solid Cable não é um pubsub efêmero puro como o Redis: as mensagens ficam persistidas por um dia (configurável), o que tem custo de espaço, mas também dá uma trilha de auditoria que o Redis, por natureza volátil, não oferecia.

O trade-off: menos peças, mais carga no banco

Tirar o Redis do stack não é troca de graça. Tudo que antes ia para um serviço em memória, otimizado para latência de microssegundos, agora passa pelo banco relacional que também serve as queries da aplicação. Em volume alto, isso compete por I/O, conexões e CPU com o tráfego principal.

Em resumo: Solid Queue, Solid Cache e Solid Cable fazem sentido para a maioria dos apps Rails de porte pequeno a médio, onde a simplicidade operacional de rodar um serviço a menos pesa mais do que o ganho de latência do Redis. Para apps com volume de jobs na casa de milhares por segundo, ou com WebSocket em escala (muitos canais, muitas mensagens simultâneas), o Redis ainda tende a ter vantagem de throughput puro.

Uma prática recomendada por quem já adota essas soluções é configurar um banco separado (pode ser outro arquivo SQLite, ou outro schema Postgres) só para as tabelas dos Solid, via config/database.yml com múltiplos roles. Isso isola o tráfego de fila e cache do banco principal da aplicação, mitigando parte da contenção.

Quando manter o Redis

Há cenários em que a troca simplesmente não compensa:

1. Jobs de altíssima frequência, como processamento de eventos em tempo real ou filas que recebem milhares de itens por segundo, onde a latência de escrita em disco do banco relacional vira gargalo visível.
2. WebSocket com volume alto de canais simultâneos, onde o overhead de persistir cada mensagem no Solid Cable soma custo de armazenamento que o Redis nunca teve.
3. Times que já têm Redis maduro em produção, com observabilidade, alertas e runbooks prontos: trocar por algo novo introduz risco operacional que só se paga se o ganho de simplicidade for real.

O ponto central da mudança não é que Redis ficou pior. É que o Rails 8 tornou opcional uma dependência que antes era quase obrigatória, e isso é bom principalmente para quem está começando um projeto novo ou mantém um app pequeno que paga uma conta de serviço gerenciado de Redis só para um volume de jobs que caberia tranquilamente numa tabela.

Fonte: Rails Guides, Ruby on Rails 8.0 Release Notes (https://guides.rubyonrails.org/8_0_release_notes.html)

Fonte: Rails Guides — Rails 8.0 Release Notes