Solid Queue ou Sidekiq? Escolhendo o backend de jobs para Rails 8 em 2026

Dois anos depois de o Rails 8.0 trazer o Solid Queue como adapter padrão do Active Job, a pergunta continua aparecendo em todo kickoff de projeto e em toda reunião de planejamento de upgrade: ficamos no Sidekiq ou migramos para o padrão baseado em banco de dados? A resposta curta, em outubro de 2026, é que os dois são maduros, os dois têm manutenção ativa, e a escolha certa depende de três coisas: sua versão do Rails, seu throughput e quanta infraestrutura você quer operar.

A resposta curta

Para uma aplicação Rails 8 nova, comece com Solid Queue. Ele é o padrão por um bom motivo: um serviço a menos para rodar, uma credencial a menos para rotacionar, e a diferença de recursos que justificava o Sidekiq em 2024 praticamente desapareceu.

Escolha Sidekiq quando você processa dezenas de milhares de jobs por minuto, quando já roda Redis ou Valkey e tem a maturidade operacional para isso, quando precisa de recursos do Sidekiq Pro ou Enterprise, como rate limiting e jobs criptografados, ou quando seu app roda em uma versão do Rails que o Solid Queue não suporta.

Esse último ponto é uma restrição dura, então ele vem primeiro.

A restrição de compatibilidade: Solid Queue exige Rails 7.1 ou superior

O Solid Queue é uma aplicação Active Record. O gemspec dele depende de activejob, activerecord e railties na versão 7.1 ou superior. Ele não instala no Rails 7.0, no 6.1 nem em nada mais antigo. Desde o Solid Queue 1.5.0 (julho de 2026) ele também exige Ruby 3.2 ou superior, depois que o suporte ao Ruby 3.1 foi removido.

Se você mantém uma aplicação presa no Rails 7.0 ou anterior, o Solid Queue simplesmente não é uma opção até você atualizar. E isso não é hipotético: o Rails 7.0 chegou ao fim de vida em 2025, o 7.1 recebe apenas correções de segurança, e a série 7.2 lançou sua versão final (7.2.4) em 24 de setembro de 2026. Se você está em uma dessas, a decisão sobre background jobs depende da decisão de upgrade do framework.

O Sidekiq é mais tolerante aqui. O Sidekiq 8 suporta Rails 7.0 ou superior com Ruby 3.2 ou superior, e a linha 7.x cobre stacks mais antigas. Se você está em uma versão legada do Rails e precisa continuar entregando, o Sidekiq é o backend que ainda roda.

Onde cada um está hoje

O Solid Queue 1.7.0 foi lançado em 21 de agosto de 2026. O destaque é o suporte a batches de jobs, a lacuna mais pedida em comparação com o Sidekiq Pro. A série 1.x também adicionou, no último ano:

• Modo de execução com fibers (1.6.0, julho de 2026) usando a gem async, permitindo que um worker rode centenas de jobs limitados por I/O em uma única thread com reactor de fibers. Encaixa bem em chamadas a LLMs e outras requisições HTTP de longa espera.
• Tarefas recorrentes dinâmicas (1.4.0, março de 2026), agendadas em runtime com SolidQueue.schedule_recurring_task, e não apenas via recurring.yml.
• O comando bin/jobs check para validar a configuração antes do boot, intervalo de polling padrão de um segundo, e a volta do modo async do supervisor ao lado do modo fork.

Ele continua rodando em PostgreSQL, MySQL e SQLite, e usa FOR UPDATE SKIP LOCKED onde o banco suporta, para que os workers não bloqueiem uns aos outros ao reivindicar jobs.

O Sidekiq 8.1.7 foi lançado em 17 de agosto de 2026 e adiciona compatibilidade com o Active Job 8.1. A linha 8.x, iniciada em março de 2025, trouxe profiling de jobs com Vernier, 72 horas de métricas, uma Web UI reescrita e suporte a Redis 7.0+, Valkey 7.2+ e Dragonfly 1.27+. O Sidekiq 8.1 adicionou o kiq, uma interface oficial de terminal, reaproveitamento de conexões Redis ociosas e a API Sidekiq.testing!(mode), que substitui o antigo require "sidekiq/testing". Os iterable jobs, que permitem a trabalhos longos salvar checkpoints e retomar entre deploys, existem no Sidekiq desde o 7.3.

Os dois adapters suportam as Active Job Continuations do Rails 8.1: o Solid Queue nativamente, o Sidekiq via o hook stopping? adicionado no 8.0.5.

Tradeoffs de arquitetura

Armazenamento e modos de falha

O Solid Queue guarda os jobs no seu banco relacional, normalmente em um banco queue dedicado configurado no database.yml. A vantagem é o enfileiramento transacional: um job inserido dentro de uma transação só fica visível para os workers se a transação for commitada. O custo é que a tabela de jobs disputa conexões e I/O com a aplicação, e é por isso que o Rails gera um banco separado para ela.

O Sidekiq guarda os jobs no Redis. Enfileirar é rápido e barato, e uma queda do Redis não derruba seu banco principal. O outro lado é que o Redis é mais um serviço com estado, com suas próprias configurações de persistência, limites de memória e estratégia de failover. Se o Redis descartar chaves sob pressão de memória, você perde jobs. O Sidekiq alerta sobre essa configuração há anos, mas ainda acontece.

Throughput

O Sidekiq é mais rápido no nível da fila. Fazer push e pop em uma lista do Redis é uma ordem de grandeza diferente de um INSERT seguido de um SELECT ... FOR UPDATE SKIP LOCKED. Para a maioria das aplicações isso não importa: se o gargalo é o job em si, que é o caso normal, alguns milissegundos de latência para reivindicar o job são ruído. Se você enfileira centenas de milhares de jobs por hora, a arquitetura do Sidekiq dá mais folga antes que a fila vire o problema.

A resposta do Solid Queue para alta concorrência são fibers, não threads. Para cargas limitadas por I/O, o modo fiber do 1.6.0 muda a conta, porque um único processo worker pode manter cem chamadas HTTP em andamento sem cem conexões de banco. Para trabalho limitado por CPU, os dois backends esbarram na GVL do mesmo jeito.

Observabilidade

O Sidekiq vem com uma Web UI com métricas, retries, dead jobs e profiles por job, além da nova interface de terminal kiq. O Solid Queue não tem UI embutida; a gem complementar mission_control-jobs fornece um painel com pausa de filas, retries e inspeção de jobs com falha. É suficiente para a maioria dos times, mas as ferramentas do Sidekiq ainda são mais profundas, especialmente com o Pro.

Custo operacional

Um app Rails 8 novo com Solid Queue precisa de um banco de dados. Só isso. A mesma instância Postgres pode hospedar os bancos primary, queue, cache e cable, e o Kamal faz o deploy sem um accessory de Redis. Na AWS, isso significa uma instância RDS em vez de RDS mais ElastiCache, e um security group, um parameter group e uma política de backup a menos para gerenciar.

A dependência de Redis do Sidekiq não é cara em dólares, mas é um segundo sistema para monitorar, atualizar e proteger. Se você já roda Redis para cache ou Action Cable, o custo marginal é baixo. Se o Solid Queue permitir remover o Redis por completo, isso é uma simplificação real.

Paridade de recursos em 2026

As lacunas que empurravam times para o Sidekiq há dois anos praticamente fecharam:

• Batches: o Solid Queue tem desde o 1.7.0. No Sidekiq, batches continuam sendo recurso do Pro.
• Jobs recorrentes: o Solid Queue tem nativo, estático e dinâmico. O Sidekiq precisa de sidekiq-cron ou sidekiq-scheduler, ou do Enterprise.
• Controle de concorrência: os dois têm. O limits_concurrency do Solid Queue é nativo; no Sidekiq é recurso do Pro e do Enterprise, ou sidekiq-unique-jobs em open source.
• Jobs de longa duração: o Sidekiq tem Sidekiq::IterableJob; o Solid Queue conta com as Active Job Continuations do Rails 8.1.
• Argumentos criptografados, rate limiting, rolling restarts: apenas no Sidekiq Enterprise.

Se sua lista de requisitos tem algum recurso do Sidekiq Enterprise, a questão está resolvida. Se não tem, o Solid Queue cobre o resto.

Guia de decisão

Comece com Solid Queue se:

• O app está no Rails 7.1 ou superior, idealmente 8.x.
• O volume de jobs é moderado, ou seja, milhares por minuto, não centenas de milhares.
• Você quer menos partes móveis, especialmente em um time pequeno ou em deploy com Kamal.
• Sua carga é limitada por I/O e se beneficiaria do modo fiber.

Fique no Sidekiq, ou escolha ele, se:

• O app está no Rails 7.0 ou anterior e o upgrade ainda não está agendado.
• Você precisa de recursos do Pro ou Enterprise: batches com callbacks, rate limiting, criptografia, jobs periódicos sem gems extras.
• Você já tem Redis ou Valkey em produção com monitoramento adequado.
• Você está na faixa de throughput em que a latência da fila é um gargalo medido.

Migrando do Sidekiq para o Solid Queue

Como os dois são adapters do Active Job, a migração é quase só configuração se seus jobs herdam de ApplicationJob. Defina config.active_job.queue_adapter = :solid_queue, rode o generator, adicione o banco de filas e mova os pesos de fila do sidekiq.yml para o config/queue.yml. Classes nativas Sidekiq::Job que usam sidekiq_options diretamente precisam ser reescritas, e qualquer coisa que acesse a API do Sidekiq, como Sidekiq::Queue.new.size, precisa de um equivalente no Solid Queue.

Rode os dois adapters em paralelo durante a transição. Aponte os jobs novos para o Solid Queue enquanto um processo Sidekiq drena as filas do Redis, e remova o Sidekiq quando elas estiverem vazias. Não tente migrar jobs agendados que estão no Redis; deixe que eles rodem onde estão.

Conclusão

Em 2026, o padrão é o padrão por um bom motivo. O Solid Queue está pronto para produção, tem recursos completos para a aplicação Rails típica e elimina uma dependência. O Sidekiq continua sendo a melhor escolha para throughput extremo, para times que dependem dos recursos comerciais, e para os apps Rails legados que simplesmente não conseguem rodar o Solid Queue. Verifique sua versão do Rails primeiro; o resto da decisão decorre dela.