Sidekiq: threaded background jobs for Ruby applications

What Sidekiq is for, and who it is not for

Sidekiq is a background job framework for Ruby. The README describes it as "Simple, efficient background jobs for Ruby" and states that it uses threads to handle many jobs at the same time in the same process, and that any Ruby application can use it. That last clause matters: nothing in the README ties Sidekiq to Rails. Sidekiq 8.0 supports Rails and Active Job 7.0+, but plain Ruby code can enqueue and process jobs without either.

The problem it addresses is latency. Sending mail, calling a third party API, or generating a report inside a web request makes the user wait for work that has nothing to do with the response. Sidekiq moves that work out of the request cycle into a separate process that pulls jobs from a queue. The process model is the design decision worth understanding before you adopt it: Sidekiq is not a fleet of worker processes by default, it is one process running many threads. That shapes everything else, including where it fails.

Threads, Redis, and the JSON that moves between them

The mechanism visible in the repository is a Redis-backed queue with threads on the consuming side. A client pushes a job onto a Redis list; a Sidekiq process pops jobs and hands each one to a thread. Because the work happens in threads inside one Ruby process, a job that blocks on network I/O releases the interpreter and lets other threads run. A job that burns CPU does not. This is the central trade-off of the design, and the README's own performance section reflects it: the benchmark in `bin/sidekiqload` is described as IO-bound, which is why concurrency is raised to 25 for that measurement.

The README gives the benchmark numbers directly. In its table, Sidekiq 7.0.3 processing 500,000 no-op jobs with Ruby 3.2.0 and YJIT at concurrency 30 reached 23,500 jobs/sec with a `Sidekiq::Job`, and 14,700 jobs/sec with ActiveJob 7.0.4. The same table shows the same run without YJIT at 21,300 and 10,700 jobs/sec respectively. The README attributes most of Sidekiq's overhead to Redis network I/O and notes that ActiveJob adds CPU overhead from argument deserialization and callbacks. It also warns that real applications rarely need concurrency greater than 10.

Job arguments cross a process boundary, so they have to be serializable. The README does not spell out the serialization rules in the text available here, but the wiki is named as the product documentation. Treat argument shape as something to confirm in the wiki before designing a job interface, not something to assume.

Installing Sidekiq and running a first job

The README gives one installation command. It adds the gem to your bundle rather than installing it globally, which is the right default for an application.

bundle add sidekiq

The README then points to the Getting Started wiki page for the setup process and to a YouTube playlist for a walkthrough. The repository also ships an `examples/` directory with a `config.yml`, `por.rb`, and directories for `systemd/`, `upstart/`, `testing/`, and `webui-ext/`, so there is a working configuration to compare against once the gem is in place. The README does not reproduce the worker class definition inline, so the exact class body belongs to the wiki, not to this article.

Where threaded processing breaks down

The failure mode follows from the architecture. Every thread shares one Ruby process, one heap, and one set of global state. A job that allocates heavily, holds a large object graph, or runs a tight numerical loop competes with every other thread for the same CPU. The README's own guidance is explicit about the ceiling: concurrency of 30 was chosen experimentally to maximize one CPU without saturating it, and real applications rarely need concurrency above 10. That is a statement about a single process on a single machine, not a claim about horizontal scale.

There is a second boundary. Sidekiq requires Redis, or Valkey, or Dragonfly. If your environment cannot run one of those, Sidekiq is not a candidate regardless of how good the job API is. The README treats Redis 7.2.4 as the canonical implementation and says incompatibilities with that version are considered bugs, which tells you where compatibility effort is concentrated if you run an alternative.

The third boundary is thread safety. The README does not discuss it, and that silence is worth noticing. Any gem your job touches, any connection pool, any memoized class variable is now shared across concurrent threads. If your codebase has never been run concurrently, adopting Sidekiq means auditing it.

Delayed Job and the process-per-worker alternative

The clearest contrast is with a process-based job runner that stores jobs in the relational database you already have. Delayed Job is the long-standing example in Ruby: jobs live in a database table, and workers are separate processes rather than threads. The difference is not cosmetic. A process per worker gives you memory isolation, so a leaking job dies with its process and a CPU-heavy job cannot starve its neighbours. It also means you do not add Redis to your operational surface, because the queue is a table in the database you already back up and monitor.

The cost is throughput and database load. Polling a SQL table for new work is heavier per job than a Redis pop, and the database becomes part of the job hot path. Sidekiq's benchmark numbers in the README, tens of thousands of no-op jobs per second, are not numbers a database-backed queue reaches. So the choice is roughly: Redis and threads when you need volume and your jobs are I/O-bound, database and processes when you value isolation and want one fewer piece of infrastructure. Neither is universally correct, and the README makes no attempt to argue the point.

Maintenance, licensing, and the paid tiers

The repository is not archived, and the last push was on 2026-09-15, so the project is being worked on. The README documents the upgrade path in one line: `bundle up sidekiq` upgrades Sidekiq and all its dependencies, and upgrade notes between major versions live in the `docs/` directory. There are also `Changes.md`, `Pro-Changes.md`, and `Ent-Changes.md` at the top level, which means the changelog is split by edition. Reading the right file before a major upgrade is the practical step.

Licensing needs care here. The repository metadata reports the licence as NOASSERTION, and the README does not state the terms in its own text; it points to `LICENSE.txt` for the licence and to `COMM-LICENSE.txt` for Sidekiq Pro and Sidekiq Enterprise. The README also says the author sells Pro and Enterprise, describing them as extensions providing more features and a commercial-friendly license. That is the shape of an open core project: the open source gem and the commercial extensions are licensed separately, and the README does not summarise either. Read `LICENSE.txt` before you ship, and read `COMM-LICENSE.txt` before you evaluate Pro or Enterprise. This is not legal advice; it is a pointer to the two files that decide the question.

Editorial conclusion

Adopt Sidekiq if you have a Ruby application, a Redis-compatible server, and job code that spends its time waiting on the network. Do not adopt it if your jobs are CPU-bound, because threads share one process, or if you cannot operate Redis as durable infrastructure. Verify first that your Redis, Valkey or Dragonfly version satisfies the requirements in the README, that your job arguments are JSON-safe, and that your thread safety story is real. The README points to the wiki Getting Started page and to a YouTube playlist for the setup walkthrough, and those are the two places to read before you write your first worker.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. sidekiq/sidekiq on GitHub