Solid Queue (Rails)
DB-only without Redis — Rails 8 default background job system
GitHub: rails/solid_queue
Solid Queue is a DB-based ActiveJob backend created by 37signals, included by default starting with Rails 8. It started from the question: "Do we really need Redis?"
Please refer to the Korean version for the detailed architecture analysis, including: the core idea of managing state via separate tables instead of status columns, the 10-table DB schema, the job lifecycle (enqueue → dispatch → claim & execute), 3 process types (Worker/Dispatcher/Scheduler), FOR UPDATE SKIP LOCKED for non-blocking polling, and transaction safety with enqueue_after_transaction_commit?.
Architecture Diagram
Job State Table Separation (ERD)
Optimized indexes per table = fast polling
Job Lifecycle
3 Process Types
Key Points
Open rails/solid_queue repository on GitHub
db/migrate/ → check 10 table schemas (state-per-table separation pattern)
lib/solid_queue/worker.rb → analyze polling loop and claim logic
lib/solid_queue/dispatcher.rb → analyze scheduled job dispatch logic
app/models/solid_queue/job.rb → check enqueue flow
app/models/solid_queue/ready_execution.rb → check FOR UPDATE SKIP LOCKED
app/models/solid_queue/claimed_execution.rb → execution/success/failure handling
lib/solid_queue/supervisor.rb → Fork vs Async process management
Pros
- ✓ No Redis needed — complete job system with DB only
- ✓ Rails 8 default — ready to use without separate installation
- ✓ ActiveJob compatible — switch without changing existing job code
- ✓ FOR UPDATE SKIP LOCKED — non-blocking competition between workers
- ✓ Built-in concurrency control — semaphore-based concurrency limit
- ✓ Puma plugin — no separate process needed in development
Cons
- ✗ May have lower throughput than Redis-based Sidekiq
- ✗ Increased DB load — heavy write burden with many jobs
- ✗ SKIP LOCKED not supported in SQLite (graceful fallback)
- ✗ Sidekiq/Redis still advantageous for large-scale services
- ✗ Web UI less mature than Sidekiq (Mission Control separate)