Solid Queue or Sidekiq? Choosing a Background Job Backend for Rails 8 in 2026

Two years after Rails 8.0 shipped Solid Queue as the default Active Job adapter, the question still comes up in every new project kickoff and every upgrade planning meeting: do we stay on Sidekiq, or do we move to the database-backed default? The short answer in October 2026 is that both are mature, both are actively maintained, and the right pick depends on three things: your Rails version, your throughput, and how much infrastructure you want to own.

The short answer

For a new Rails 8 application, start with Solid Queue. It is the default for a reason: one less service to run, one less credential to rotate, and the feature gap that justified Sidekiq in 2024 has mostly closed.

Choose Sidekiq when you are processing tens of thousands of jobs per minute, when you already run Redis or Valkey and have the operational muscle for it, when you need Sidekiq Pro or Enterprise features such as rate limiting and encrypted jobs, or when your app runs on a Rails version that Solid Queue does not support.

That last point is a hard constraint, so it comes first.

The compatibility constraint: Solid Queue needs Rails 7.1 or newer

Solid Queue is an Active Record application. Its gemspec depends on activejob, activerecord and railties at 7.1 or higher. It will not install on Rails 7.0, 6.1, or anything older. Since Solid Queue 1.5.0 (July 2026) it also requires Ruby 3.2 or newer, after Ruby 3.1 support was dropped.

If you maintain an application stuck on Rails 7.0 or earlier, Solid Queue is simply not an option until you upgrade. That is not a hypothetical: Rails 7.0 reached end of life in 2025, 7.1 only gets security fixes, and the 7.2 series shipped its final release (7.2.4) on September 24, 2026. If you are on one of those, the background job decision is downstream of the framework upgrade decision.

Sidekiq is more forgiving here. Sidekiq 8 supports Rails 7.0 and newer with Ruby 3.2 or newer, and the Sidekiq 7.x line covers older stacks. If you are on a legacy Rails version and need to keep shipping, Sidekiq is the backend that still runs.

Where each one stands today

Solid Queue 1.7.0 was released on August 21, 2026. The headline feature is job batches, which was the most requested gap compared to Sidekiq Pro. The 1.x series over the last year also added:

• Fiber execution mode (1.6.0, July 2026) using the async gem, so a worker can run hundreds of I/O-bound jobs on a single fiber reactor thread. This is a good fit for LLM calls and other long-waiting HTTP work.
• Dynamic recurring tasks (1.4.0, March 2026), scheduled at runtime with SolidQueue.schedule_recurring_task instead of only through recurring.yml.
• A bin/jobs check command to validate configuration before boot, a default polling interval of one second, and a reintroduced async supervisor mode alongside fork mode.

It still runs on PostgreSQL, MySQL and SQLite, and uses FOR UPDATE SKIP LOCKED where the database supports it so workers do not block each other when claiming jobs.

Sidekiq 8.1.7 was released on August 17, 2026 and adds forward compatibility with Active Job 8.1. The 8.x line, which started in March 2025, brought job profiling with Vernier, 72 hours of job metrics, a rewritten Web UI, and support for Redis 7.0+, Valkey 7.2+ and Dragonfly 1.27+. Sidekiq 8.1 added kiq, an official terminal UI, idle Redis connection reaping, and a Sidekiq.testing!(mode) API replacing the old require "sidekiq/testing" pattern. Iterable jobs, which let long-running work checkpoint and resume across deploys, have been in Sidekiq since 7.3.

Both adapters support Rails 8.1 Active Job Continuations: Solid Queue natively, Sidekiq via the stopping? hook added in 8.0.5.

Architecture tradeoffs

Storage and failure modes

Solid Queue stores jobs in your relational database, typically a dedicated queue database configured in database.yml. The benefit is transactional enqueueing: a job inserted inside a transaction is only visible to workers if the transaction commits. The cost is that your job table competes with your application for database connections and I/O, which is why Rails generates a separate database for it.

Sidekiq stores jobs in Redis. Enqueueing is fast and cheap, and a Redis outage does not take down your primary database. The flip side is that Redis is an additional stateful service with its own persistence settings, memory limits and failover story. If Redis evicts keys under memory pressure, you lose jobs. Sidekiq has warned about that configuration for years, but it still happens.

Throughput

Sidekiq is faster at the queue level. Pushing and popping from a Redis list is a different order of magnitude from an INSERT followed by a SELECT ... FOR UPDATE SKIP LOCKED. For most applications this does not matter: if your bottleneck is the job itself, which it usually is, a few milliseconds of claim latency is noise. If you are enqueueing hundreds of thousands of jobs per hour, Sidekiq's architecture gives you more headroom before the queue becomes the problem.

Solid Queue's answer to high concurrency is fibers, not threads. For I/O-bound workloads the 1.6.0 fiber mode changes the math, because a single worker process can hold a hundred in-flight HTTP calls without a hundred database connections. For CPU-bound work, both backends are limited by the GVL in the same way.

Observability

Sidekiq ships a Web UI with metrics, retries, dead jobs and per-job profiles, plus the new kiq terminal UI. Solid Queue has no built-in UI; the companion gem mission_control-jobs provides a dashboard with queue pausing, retries and failed job inspection. It is good enough for most teams, but Sidekiq's tooling is still deeper, especially with Pro.

Operational cost

A new Rails 8 app on Solid Queue needs a database. That is it. The same Postgres instance can host the primary, queue, cache and cable databases, and Kamal deploys it without a Redis accessory. On AWS that is one RDS instance instead of RDS plus ElastiCache, and one fewer security group, parameter group and backup policy to manage.

Sidekiq's Redis dependency is not expensive in dollars, but it is a second system to monitor, upgrade and secure. If you already run Redis for caching or Action Cable, the marginal cost is low. If Solid Queue would let you remove Redis entirely, that is a real simplification.

Feature parity in 2026

The gaps that pushed teams to Sidekiq two years ago have mostly closed:

• Batches: Solid Queue has them since 1.7.0. Sidekiq batches remain a Pro feature.
• Recurring jobs: Solid Queue has them built in, static and dynamic. Sidekiq needs sidekiq-cron or sidekiq-scheduler, or Enterprise.
• Concurrency controls: both have them. Solid Queue's limits_concurrency is built in; Sidekiq's is a Pro and Enterprise feature, or sidekiq-unique-jobs in open source.
• Long-running jobs: Sidekiq has Sidekiq::IterableJob; Solid Queue relies on Rails 8.1 Active Job Continuations.
• Encrypted job arguments, rate limiting, rolling restarts: Sidekiq Enterprise only.

If your requirements list has a Sidekiq Enterprise feature on it, that settles the question. If it does not, Solid Queue covers the rest.

A decision guide

Start with Solid Queue if:

• The app is on Rails 7.1 or newer, ideally 8.x.
• Job volume is moderate, meaning thousands per minute rather than hundreds of thousands.
• You want fewer moving parts, especially on a small team or a Kamal deployment.
• Your workload is I/O-bound and would benefit from fiber mode.

Stay on, or choose, Sidekiq if:

• The app is on Rails 7.0 or older and the upgrade is not scheduled yet.
• You need Pro or Enterprise features: batches with callbacks, rate limiting, encryption, periodic jobs without extra gems.
• You already have Redis or Valkey in production with proper monitoring.
• You are at the throughput tier where queue latency is a measured bottleneck.

Migrating from Sidekiq to Solid Queue

Because both are Active Job adapters, the migration is mostly configuration if your jobs inherit from ApplicationJob. Set config.active_job.queue_adapter = :solid_queue, run the generator, add the queue database, and move your sidekiq.yml queue weights into config/queue.yml. Native Sidekiq::Job classes that use sidekiq_options directly need rewriting, and anything that reaches into the Sidekiq API, such as Sidekiq::Queue.new.size, needs a Solid Queue equivalent.

Run both adapters in parallel during cutover. Point new jobs at Solid Queue while a Sidekiq process drains the Redis queues, then remove Sidekiq once they are empty. Do not try to migrate scheduled jobs in Redis; let them run where they are.

Bottom line

In 2026 the default is the default for good reason. Solid Queue is production-grade, feature-complete for the typical Rails application, and it removes a dependency. Sidekiq remains the better choice for extreme throughput, for teams that depend on its commercial features, and for the legacy Rails apps that cannot run Solid Queue at all. Check your Rails version first; the rest of the decision follows from it.