A database-backed queuing backend for Active Job in Ruby on Rails, designed for simplicity and performance.
Solid Queue is a database-based queuing backend for Ruby on Rails' Active Job framework. It enables reliable, persistent background job processing by storing jobs in SQL databases like PostgreSQL, MySQL, or SQLite, eliminating the need for external queue services. It solves the problem of job durability and scalability while maintaining tight integration with Rails' conventions and tooling.
Ruby on Rails developers who need a reliable, database-backed background job system without external dependencies, particularly those deploying on platforms where external Redis or RabbitMQ services are undesirable or complex to manage.
Developers choose Solid Queue for its simplicity, durability, and seamless Rails integration. It reduces infrastructure complexity by leveraging the existing database, provides transactional integrity for job enqueuing, and offers features like concurrency controls and recurring tasks out of the box.
Database-backed Active Job backend
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Jobs are stored in SQL tables with ACID compliance, ensuring persistence through crashes and allowing transactional enqueuing within database writes, as noted in the 'Jobs and transactional integrity' section.
Configured by default in Rails 8 and works as an Active Job backend, reducing setup overhead and leveraging Rails conventions like migrations and configuration files.
Allows limiting simultaneous job executions by key, group, or arguments, with configurable conflict handling (block or discard), useful for scenarios like rate-limiting per account.
Supports cron-like scheduling via a YAML file or dynamic runtime scheduling, eliminating the need for external cron jobs or separate schedulers.
Concurrency controls introduce significant overhead, and the README advises against using them for simple throttling, recommending limited workers per queue instead, which can complicate scaling.
Optimal performance requires databases with SKIP LOCKED support (e.g., MySQL 8+, PostgreSQL 9.5+); without it, lock contention can degrade performance, limiting older setups.
Installation involves configuring separate database connections and schemas (e.g., queue database in database.yml), which adds complexity and potential for errors compared to drop-in solutions.