Overview
Solid Queue is a queuing backend for Rails Active Job that stores jobs in a SQL database: MySQL, PostgreSQL or SQLite. Started in 2023 and hosted under the Rails GitHub organisation, it is configured by default in new Rails 8 applications, replacing the need for Redis in many apps.
It supports delayed jobs, recurring tasks defined in config/recurring.yml, concurrency controls that limit how many jobs with the same key run at once, pausing queues, numeric priorities and bulk enqueuing. It uses FOR UPDATE SKIP LOCKED when available so workers do not block each other, and relies on Active Job for retries, discarding and error handling.
For small apps it can run inside Puma via a plugin or on the web server; larger deployments run bin/jobs on separate machines and can dedicate hosts to dispatchers or workers. The recommended setup uses a separate queue database, though a single-database configuration is supported. It requires Rails 7.1+ and Ruby 3.2+.
Pricing and plans
| Plan | Price | What you get |
|---|---|---|
| Solid Queue | Free | MIT licence, part of the Rails project |
What it does
- SQL-backed
- Jobs stored in MySQL, PostgreSQL or SQLite, using SKIP LOCKED where supported.
- Recurring tasks
- Cron-like recurring jobs configured in config/recurring.yml or scheduled dynamically.
- Concurrency controls
- Limit concurrent executions of jobs sharing a key.
- Priorities and pausing
- Numeric per-job priorities, queue-order priorities and paused queues.
- Puma plugin
- Run the supervisor inside Puma for small single-server deployments.
- Dashboard
- The README includes setup for a separate dashboard UI to inspect jobs.
Strengths and limitations
Strengths
- Default in Rails 8, so no extra setup for new apps
- No Redis required; works with SQLite for small apps
- Recurring jobs and concurrency controls included free
- Maintained within the Rails project
Limitations
- Rails only, and requires Rails 7.1+ and Ruby 3.2+
- Retries and error handling come from Active Job rather than Solid Queue
- Polling a SQL database adds load compared with Redis-based queues
- A separate queue database is the recommended configuration
Who it suits
Good for
- New Rails 8 applications
- Small Rails apps on SQLite or a single server
- Teams dropping Redis from their stack
Look elsewhere if
- Very high job throughput where Sidekiq on Redis is faster
- Non-Rails applications
Alternatives to Solid Queue
| Tool | From | Free option | Stages |
|---|---|---|---|
| Sidekiq Redis-based background job library for Ruby | $99/mo | ||
| Faktory Language-agnostic background job server | $299/mo | ||
| pg-boss PostgreSQL job queue for Node.js | — | ||
| River Postgres-backed job queue for Go | $125/mo | ||
| Celery Distributed task queue for Python | — | ||
| Google Cloud Tasks Managed task queue with HTTP push delivery | Usage-based | Free tier |
Questions
Is Solid Queue the default in Rails 8?
Yes. New Rails 8 applications are configured with Solid Queue as the Active Job backend.
Does Solid Queue need Redis?
No. It stores jobs in MySQL, PostgreSQL or SQLite.
Can Solid Queue run recurring jobs?
Yes, via config/recurring.yml or dynamic scheduling.
Solid Queue or Sidekiq?
Solid Queue avoids Redis and is free with recurring jobs and concurrency controls; Sidekiq on Redis handles higher throughput and has paid Pro and Enterprise features.
Sources read for this page