Solid Queue Rails 8: High-Performance Database-Backed Job Queue

Background job processing is a core part of many Rails applications. In Rails 8 Solid Queue is introduced as the default job adapter for Active Job. Unlike Redis-based systems (Sidekiq, Resque) that require an external Redis server, Solid Queue runs directly on your SQL database (PostgreSQL, MySQL, or SQLite) This design eliminates an extra infrastructure component and makes job data transparent in your database. In this post, I explain what Solid Queue is, highlight its key features and benefits, and show how to set it up in a Rails 8 app.

What is Solid Queue in Rails 8?

Solid Queue is a database-backed queuing backend for Rails’ Active Job, enabled by default from Rails 8. It was created by the Rails core team to remove the need for Redis or other external job services. Essentially, Solid Queue stores all job details in database tables and uses standard SQL techniques to enqueue, schedule, and execute jobs. The official Solid Queue README describes it as “designed with simplicity and performance in mind”. In practice, it supports all the features developers expect from a modern background job system:

• Delayed and scheduled jobs: You can queue jobs to run at a specific time or after a delay (e.g. perform_later(wait: 1.hour)), just like other Active Job backends.
• Concurrency controls: Solid Queue lets you limit how many jobs of a given type run simultaneously, preventing job duplication or overload.
• Priority and ordering: You can assign numeric priorities to jobs or specify the order of queues. By default, workers fetch jobs from queues in order, and within a queue they respect the job’s priority value.
• Bulk enqueuing: It supports methods like enqueue_all/perform_all_later to add many jobs in one operation for efficiency.
• Recurring tasks: Similar to cron, you can define periodic jobs in config/recurring.yml that Solid Queue will enqueue automatically at scheduled intervals.

All of these features come built-in without requiring Redis or any extra service. Active Job handles serialization, retries, and error handling as usual. In fact, Solid Queue simply plugs into Rails: in a new Rails 8 app it’s already configured as the :solid_queue adapter.

Also Read : Rails 8: What’s New and Why It Matters

Setting Up Solid Queue in Rails 8

In a brand-new Rails 8 application, Solid Queue is already enabled by default as the production queue backend. You can start writing jobs immediately and they’ll use Solid Queue. If you’re upgrading an older Rails app, you can install it manually:

1. Add the gem: In your project, run:

bundle add solid_queue
bin/rails solid_queue:install

The installer generator will configure config.active_job.queue_adapter = :solid_queue and create the necessary files (e.g. config/queue.yml, config/recurring.yml, and the db/queue_schema.rb migration). It also provides a bin/jobs script to run the worker.

2. Configure the database: By default, Solid Queue uses a separate “queue” database. In config/database.yml, add a section like:

production:
  primary:
    <<: *default
    database: storage/production.sqlite3
  queue:
    <<: *default
    database: storage/production_queue.sqlite3
    migrations_paths: db/queue_migrate

3. Run migrations: Execute bin/rails db:prepare (or db:migrate:queue if you keep a separate queue DB). This will create the Solid Queue tables (solid_queue_ready_executions, solid_queue_scheduled_executions, etc.) in the queue database.
4. Start the workers: On your server, run bin/jobs start (or use bundle exec rake solid_queue:start). This launches the dispatcher and worker processes defined in config/queue.yml. The default configuration runs one dispatcher and one worker, but you can customize it as needed. At this point, Solid Queue will begin processing any queued jobs in your database tables.

That’s it – you’re now using Solid Queue for background jobs

Solid Queue vs Redis-based Queues

Solid Queue’s main appeal is simplicity. It lets you use the database you already have, without maintaining a Redis service. For many apps, this reduces operational overhead: you can deploy Rails apps with just a database and no other dependencies. In contrast, mature Redis-backed tools like Sidekiq or Resque offer very high throughput and rich ecosystems (middlewares, extensions, dashboards), but require separate infrastructure.

Here are some high-level trade-offs:

• Solid Queue (Database): No external services needed, full Active Job integration, easy debugging (jobs in SQL), and built into Rails 8 by default. However, it relies on your database performance and might require tuning for very high loads.
• Redis Queues (Sidekiq/Resque): Designed for extremely high concurrency and distributed systems. Redis provides fast in-memory queues and extra features (pub/sub, real-time stats). You’ll need to run Redis, and configure retries, but you get a large community and tools.

If you're building a small to medium Rails app, Solid Queue is a great choice. It comes built into Rails 8, doesn’t need Redis or any extra setup, and works smoothly with Active Job. You can run background jobs right away without adding new services — it’s simple and ready to go.

For larger apps that need to process thousands of jobs per second or require advanced features like real-time processing and custom retry logic, you may still prefer a Redis-based tool like Sidekiq. It’s proven, fast, and comes with powerful tools like web dashboards and custom plugins.

Still, Rails 8 makes Solid Queue a strong default option. It handles most use cases well and makes background jobs easier to set up and manage — especially if you want to avoid extra infrastructure.

Also Read : Rails 8 Solid Cable: Real-Time Features Without Redis

Final Thoughts

Solid Queue marks a significant evolution in Rails 8 — bringing a powerful, fully integrated background job system that runs entirely on your database. It supports everything you'd expect from a modern job queue: delayed execution, priority handling, concurrency limits, recurring tasks, and more — all without needing Redis or any external services.

By following the setup steps and best practices outlined above, you can take full advantage of Solid Queue in your Rails 8 app. It’s a simple, reliable, and production-ready solution that keeps your stack lightweight while delivering the job processing power most applications need.

Build Real-Time Rails Apps With Sobonix

At Sobonix, we help startups and enterprises build modern, scalable Ruby on Rails applications with real-time features, Turbo, Hotwire, and modern UI.

Let our experts build your next Rails app → Get in touch with Sobonix

Frequently Asked Questions

1. What is Solid Queue, and why is it in Rails 8?
A:- Solid Queue is the new default database-backed Active Job adapter in Rails 8. Rails core introduced it to avoid requiring Redis or similar for background jobs. It lets you use your SQL database for queues while retaining all familiar Active Job features.

2. How do I enable Solid Queue in my Rails app?
A:- In Rails 8, Solid Queue is already set as the production backend. For older apps, add gem 'solid_queue', run rails solid_queue:install, then migrate. Ensure your config/database.yml has a queue database configured, and set config.active_job.queue_adapter = :solid_queue if it isn’t already.

3. Does Solid Queue require Redis?
A:- No – that’s a key point. Solid Queue uses only your application database (PostgreSQL, MySQL, or SQLite) and does not need Redis. This simplifies deployment since you don’t need an extra Redis service.

4. Can I use Solid Queue with SQLite or in development?
A:- Yes, you can run Solid Queue with SQLite (useful for development or small apps). Rails even uses SQLite as the default database in new apps, so Solid Queue fits that. However, for heavy workloads or production, it’s better to use PostgreSQL or MySQL with SKIP LOCKED support. In development, you can start Solid Queue via the Puma plugin or by running bin/jobs manually.

5. How do I monitor or debug jobs?
A:- Since Solid Queue uses database tables, you can directly query the tables to see queued, running, or failed jobs. For a user-friendly interface, use the Mission Control dashboard or another admin tool that supports Solid Queue. You can also review your Rails logs or handle failed jobs with Active Job’s error callbacks as usual.

6. Is Solid Queue production-ready?
A:- Absolutely. It’s the default in Rails 8’s production . It was designed for production use, especially on supported DBs. Many Rails teams are testing and using it in production environments as an alternative to Redis-based queues.