Sidekiq's thread pool, its 500k job benchmark, and the Redis it cannot live without

One process, many threads, one Redis hop per job

Sidekiq runs jobs as threads inside a single process, so the process that parses job payloads is the same process that runs your application code. Its own benchmark shows where the time actually goes. `bin/sidekiqload` creates 500,000 no-op jobs and drains them as fast as possible, and the jobs do nothing at all. Even so, the run takes 21.3 seconds for 23,500 jobs per second on Ruby 3.2.0 with YJIT at concurrency 30, 23.5 seconds for 21,300 jobs per second on the same Ruby without YJIT, and 23.0 seconds for 21,700 jobs per second on Ruby 2.7.5. None of that work touches a database or renders a template. The stated reason is that the benchmark requires a lot of Redis network I/O and JSON parsing, and that most of Sidekiq's overhead is Redis network I/O. That overhead is quoted against a fixed assumed Redis network latency of 1ms, so the table describes a datastore sitting on a fast local network rather than one reached across regions.

ActiveJob halves throughput before your job body runs

Run the same 500,000 no-op jobs through ActiveJob 7.0.4 instead of Sidekiq::Job and the numbers roughly halve: 33.8 seconds and 14,700 jobs per second on Ruby 3.2.0 with YJIT, 46.5 seconds and 10,700 jobs per second on the same Ruby without YJIT, and 46.5 seconds and 10,850 jobs per second on Ruby 2.7.5. The gap is CPU cost added inside the process, attributed to argument deserialization and callbacks, not to extra network traffic. This is the part that decides your wrapper. If your work is sending lots of email or other network-intensive calls, the README says you could see a similar benefit from raising concurrency, with the warning to be careful not to saturate the CPU. If your jobs are wrapped in ActiveJob because they are called from Rails, that deserialization and callback cost is already paid before your first line of job code runs, and it caps how fast one box can clear a backlog regardless of how far you raise concurrency.

There is no datastore inside Sidekiq, so Redis is a hard dependency

The requirements are Redis 7.0+, Valkey 7.2+ or Dragonfly 1.27+, and Ruby MRI 3.2+ or JRuby 9.4+. Sidekiq 8.0 supports Rails and Active Job 7.0+. Redis 7.2.4 is named the canonical implementation, and incompatibilities with that version are treated as bugs. Running on Valkey or Dragonfly therefore does not give you a neutral arbiter: there is no second reference server in the requirements list to compare against, and a deviation on an alternative implementation is answered by pointing back to Redis 7.2.4 behavior. The larger limitation is structural. Sidekiq has no datastore of its own and no in-process queue, so a Redis-compatible server has to be deployed, version-checked, patched and monitored as its own service, separate from your Ruby deploys. Its uptime becomes your job uptime.

The prose says concurrency 25 and the benchmark table says 30

The performance section states that the workload is IO-bound and that concurrency is increased to 25. Every row of the table that follows lists concurrency as 30, and a closing note explains that concurrency of 30 was determined experimentally to maximize one CPU without saturating it. Both figures sit in the project's own documentation, so anyone planning capacity from the prose is not looking at the setting the numbers were collected with. The guidance below them is the part to plan against: real world applications will rarely, if ever, need concurrency greater than 10. The consequence of ignoring that limit is concrete, because threads share a single CPU with your job bodies. On network-heavy work, extra threads buy throughput until the CPU fills. On CPU-heavy work they do not buy throughput at all; they add context switching and convert a slow queue into a saturated process that stops serving anything.

No private channel to the committers without Pro or Enterprise

The project tells contributors not to email committers directly with questions or problems, on the grounds that a community is best served when discussions are held in public. The documented open source paths for a stuck job are the FAQ wiki page, the Problems and Troubleshooting wiki page, searching the issues, the Sidekiq tag on Stack Overflow, and the sidekiq tag on the Ruby Users Forum. There is also a video Office Hour every Thursday morning. Private email support is stated as a benefit of paid tiers only, for Sidekiq Pro and Sidekiq Enterprise customers, who are pointed at https://sidekiq.org and [email protected]. What you cannot obtain without a license is a private reply about your own configuration. If a queue backs up outside business hours, the choices are to work the problem in a public channel, wait for the next office hour, or buy the paid tier.

No GitHub releases means upgrade notes live in docs/ and Changes.md

The repository publishes no GitHub releases, so there is no release page and no generated changelog entry to skim before upgrading. The documented upgrade path is a single Bundler command, which moves Sidekiq and all of its dependencies together rather than letting you pin just the one gem, and the notes for each major version live in the `docs/` directory of the repository. Three separate changelog files sit at the top level: Changes.md, Pro-Changes.md and Ent-Changes.md, tracking the open source line and the two paid extensions independently. The consequence is on review burden. Because the command also raises everything else, the diff you are about to test is much larger than the Sidekiq change, and reading the `docs/` notes first is the only documented way to learn what a new major version expects of your Ruby, your Rails version and your Redis setup.

bundle add sidekiq is the whole documented install

Installation is one Bundler line:

bundle add sidekiq

There is no generator command, no initializer snippet and no packaged service unit in the README. Setup is delegated to a Getting Started wiki page and a YouTube playlist. The repository does ship hints about how the project expects to be operated: `examples/systemd/` and `examples/upstart/` for service management, an `examples/config.yml`, a `examples/por.rb` script, a `bin/lint-herb` executable and a matching `bundle exec rake lint:herb` task that CI runs over every ERB file, all of which were renamed to the `.html.erb` extension for tooling support. What the repository does not document is the configuration most deployments get wrong: Redis connection sizing and queue selection are not spelled out anywhere in the README, so the wiki pages and the shipped `examples/config.yml` are what is left. The Web UI appears only as a screenshot, with no text on how to read what it displays.

Editorial conclusion

Sidekiq fits teams that already operate Redis and want background work handled by threads in a Ruby process. It does not fit a team that wants job processing with no Redis server to run, nor one that needs a private support channel without buying Pro or Enterprise. Before committing, check your queue depth against the 1ms latency assumption the benchmark bakes in, confirm you run Redis 7.0+ or Valkey 7.2+ or Dragonfly 1.27+, and read the notes in `docs/` for the major version you are moving to, since the repository publishes no GitHub releases.

Frequently asked questions

Official sources

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