Rails 8 remove o Redis do padrão com Solid Queue, Solid Cache e Solid Cable

O Rails 8 troca Redis por três componentes baseados em banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →: Solid Queue, Solid Cache e Solid Cable. Veja como migrar um app existente e quando ainda compensa manter Sidekiq.

Nota da redação: este artigo cita recursos pagos do Sidekiq Pro/Enterprise (rate limiting, unicidade, batches), a observabilidade via Sidekiq Web e a manutenção do adaptador Redis no Rails 8 sem remoção. Essas afirmações são de conhecimento geral no ecossistema Ruby, mas não encontramos documentação oficial do Sidekiq ou trecho explícito nas release notes do Rails que as confirme diretamente. Os fatos centrais sobre Solid Queue, Solid Cache, Solid Cable e o mecanismo FOR UPDATE SKIP LOCKED foram verificados e batem com as release notes oficiais do Rails 8.

O Rails 8.0 mudou uma decisão de arquitetura antiga: a dependência quase automática de Redis. A versão 8 vem com três componentes novos: Solid Queue, Solid Cache e Solid Cable. Os três fazem o que Redis (e, no caso de filas, Sidekiq) faziam antes, só que usando o banco de dados relacional que a aplicação já tem rodando.

Para quem mantém um app Rails 6 ou 7 em produção, isso não é só um detalhe de changelog. É uma peça a menos (ou a mais, dependendo do caso) na lista de serviços que alguém precisa provisionar, monitorar e atualizar às 3 da manhã quando cai.

O que cada Solid substitui, exatamente

Solid Queue substitui a combinação de Redis com um framework de jobs separado, como Sidekiq, Resque ou Delayed Job. Ele roda sobre a mesma técnica de FOR UPDATE SKIP LOCKED, introduzida no PostgreSQL 9.5 e hoje disponível também no MySQL 8.0 e no SQLite. Isso significa que múltiplos workers podem puxar jobs da fila sem travar uns aos outros, usando só o banco já existente.

Solid Cache substitui Redis ou Memcached para cache de fragmento 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) →. Em vez de guardar os dados em memória num processo separado, ele grava os dados em uma tabela do banco de dados relacional já usado pela aplicação.

Solid Cable substitui o adaptador Redis do Action Cable, usado para distribuir mensagens WebSocket entre processos. Por padrão, as mensagens ficam retidas no banco por um dia, o que também dá um histórico de pubsub que o Redis, por ser só memória volátil, nunca ofereceu.

Como fica a configuração num app existente

Para um app Rails 7.2 (a guia de upgrade recomenda passar por essa versão antes de ir para a 8.0), a migração começa pelos Gemfiles e pelos geradores de instalação:

# Gemfile
gem "solid_queue"
gem "solid_cache"
gem "solid_cable"

bin/rails solid_queue:install
bin/rails solid_cache:install
bin/rails solid_cable:install
bin/rails db:migrate

Depois, trocam-se os adaptadores em config/environments/production.rb:

config.active_job.queue_adapter = :solid_queue
config.cache_store = :solid_cache_store
config.action_cable.adapter = :solid_cable

Um ponto que vale considerar: se as tabelas do Solid Queue, do Solid Cache e do Solid Cable ficarem no mesmo banco da aplicação, isso pode se tornar um gargalo em produção, já que cada job processado e cada leitura de cache vira uma query concorrendo com o tráfego normal da aplicação. Por isso faz sentido usar a configuração de bancos múltiplos que o Rails 8 já suporta, para separar essa carga:

# config/database.yml
production:
  primary:
    <<: *default
    database: app_production
  queue:
    <<: *default
    database: app_production_queue
    migrations_paths: db/queue_migrate
  cache:
    <<: *default
    database: app_production_cache
    migrations_paths: db/cache_migrate
  cable:
    <<: *default
    database: app_production_cable
    migrations_paths: db/cable_migrate

Com isso, o banco principal da aplicação não compete com fila, cache e pubsub por I/O e locks. É o equivalente, em espírito, a ter o Redis separado do Postgres, só que todos os três bancos extras podem rodar na mesma instância de Postgres ou MySQL, sem precisar de outro motor de banco de dados.

Quando o trio Solid ainda não substitui Sidekiq + Redis

Aqui entra o ponto que o anúncio não vende: Solid Queue resolve o caso comum, mas não é um substituto 1:1 de Sidekiq em toda situação. A diferença central é mecanismo de polling em banco versus fila em memória.

Em resumo: se a aplicação roda numa instância de banco bem dimensionada e não depende de recursos pagos do Sidekiq Pro (batches, unicidade distribuída, rate limiting avançado), o Solid Queue cobre o caso sem dor. Se a fila é o coração de um sistema com volume muito alto de eventos, ou se o time já paga por Sidekiq Enterprise por motivo concreto, a troca ainda não compensa.

O mesmo raciocínio vale para o Solid Cache: cache em banco relacional tende a ter latência de leitura maior que Redis em memória, mesmo com índices bem desenhados. Para fragmentos de página que mudam pouco, a diferença é imperceptível. Para cache de altíssima frequência de leitura, tipo contador de visualizações atualizado a cada request, Redis continua sendo a escolha mais previsível.

O caminho de migração recomendado

Para quem decide migrar um app em produção, a sequência que reduz risco é gradual, não um "big bang":

1. Atualizar primeiro para Rails 7.2, rodando toda a suíte de testes e confirmando que nada quebrou antes de tocar na 8.0 - a própria guia de upgrade do Rails recomenda esse passo intermediário.
2. Adicionar Solid Cache primeiro, em paralelo ao cache atual, usando um ambiente de staging para comparar hit rate e latência antes de trocar em produção.
3. Migrar Solid Queue só depois, começando pelas filas de menor criticidade (envio de e-mail transacional, por exemplo) antes das filas de negócio sensíveis a atraso.
4. Deixar Solid Cable por último, porque trocar o adaptador de WebSocket em produção sem um canary de alguns minutos de sobreposição pode derrubar conexões ativas.

O que isso não resolve sozinho

Vale lembrar que Redis não desaparece do ecossistema Rails por decreto: ele continua sendo a opção recomendada para quem precisa de rate limiting agressivo (via rack-attack com store Redis), de sessões compartilhadas em escala muito grande, ou de estruturas de dados como sorted sets que o banco relacional não modela bem. O Rails 8 também manteve o adaptador Redis disponível para quem quiser continuar usando, nada foi removido, só o padrão de novos apps mudou.

O ganho real, para a maioria dos times de produto pequenos e médios, é operacional: menos um serviço para provisionar, atualizar e monitorar, e uma conta de infraestrutura mais simples. Para quem já opera Redis há anos sem dor, a régua de decisão é simples: se não tem motivo concreto para migrar hoje, não precisa. O trio Solid é a opção certa para quem está começando um projeto novo ou para quem já estava insatisfeito com o custo operacional de manter Redis só para jobs e cache.

Fonte: Rails Guides — 8.0 Release Notes