Why SolidQueue? The Need for a Native Rails Job Processing Solution

As background job processing became an integral part of almost every modern Rails application—from sending emails and notifications to syncing third-party APIs and running scheduled maintenance tasks—the Rails ecosystem increasingly relied on third-party tools to handle this critical responsibility.

While tools like Sidekiq, Resque, and Delayed Job each had their strengths, they also introduced external complexity, operational overhead, and a disconnect from the core Rails philosophy of convention over configuration.

SolidQueue was born out of this realization—a need for a first-class, native queuing system that would work seamlessly within the Rails framework, without the burden of managing an external data store like Redis or adopting the learning curve of third-party job processing libraries.

Rails had standardized background job interfaces through Active Job back in version 4, but up until version 7, the framework itself offered no official backend for job processing. Developers had to choose and wire in a backend manually, often Sidekiq or Delayed Job.

The introduction of SolidQueue in Rails 8 closed that gap. It isn’t just “another job queue system.” It's built by the Rails core team and designed to work with Active Job out-of-the-box.

More importantly, it’s designed with modern needs in mind—concurrency, efficiency, and scalability—while still being simple enough to run on SQLite in both development, production , and other environment such as staging.

Here’s a look at what makes SolidQueue significant:

1. No Redis Required

SolidQueue uses your existing SQL database (PostgreSQL, MySQL, or SQLite) to store and manage job queues. It leverages advanced SQL features like FOR UPDATE SKIP LOCKED to fetch jobs safely in concurrent environments without locking up the entire queue. This removes the need for Redis and makes the stack lighter, cheaper, and easier to manage—especially for small teams or solo developers.

2. Deep Rails Integration

Jobs in SolidQueue are standard Active Job classes. The setup is minimal, and everything from job definitions to enqueuing, retrying, and error handling aligns with standard Rails idioms. You don’t need to learn a new DSL or external concepts—just plain old Rails models, migrations, and initializers.

3. Rich Feature Set

Despite its simplicity, SolidQueue supports:

This makes it suitable not just for simple tasks, but also for high-volume production workloads.

4. Thread-Safe and Multi-Process Ready

SolidQueue is compatible with Rails' multithreaded execution model, which allows it to perform well under load. Jobs can be processed by multiple threads or processes concurrently, making it suitable for horizontal scaling with background workers.

5. Operational Simplicity

With fewer moving parts, deployments are easier. Database backups automatically include job queues. Monitoring and debugging background jobs becomes part of your Rails app, not an external web UI. Logs, database tables, and models are all part of the same system, making everything easier to reason about and manage.

Here’s how simple a SolidQueue job setup is:

#config/application.rb
config.active_job.queue_adapter = :solid_queue

#app/jobs/example_job.rb
class ExampleJob < ApplicationJob
  queue_as :default

  def perform(user_id)
    User.find(user_id).update(last_seen_at: Time.current)
  end
end

#Enqueue the job
ExampleJob.perform_later(current_user.id)

6. Free and Open Source

Unlike Sidekiq Pro or Enterprise, SolidQueue ships with Rails and is completely open-source under the MIT license. There's no paywall between you and production-grade features.

In summary, SolidQueue represents a philosophical return to the Rails way—convention over configuration, batteries included, and simplicity first.

It eliminates the external dependency on Redis, reduces complexity, and gives Rails developers a powerful tool to handle asynchronous work without leaving the Rails ecosystem.

It's not meant to replace Sidekiq in every case—there are scenarios where Sidekiq’s advanced capabilities and performance might still be preferable—but for the vast majority of Rails applications, SolidQueue is now the most natural and native way to process background jobs.