Rails 8 includes a number of built-in tools that make applications production-ready by default. In this video, I want to introduce a few key ones, starting with the Solid gems suite.

Introducing the Solid Gems Suite

If we look at the Gemfile, we can see three essential Solid gems:

1. Solid Cache – A database-backed caching system for Rails.
2. Solid Queue – A background job processing system.
3. Solid Cable – A database-backed ActionCable adapter.

For this video, we’ll focus on Solid Queue and how it is set up to handle background job processing efficiently.

Understanding Solid Queue’s Schema

Looking at the database schema, we notice that Solid Queue creates multiple tables.

The reason for so many tables is that Rails applications process thousands—or even millions—of jobs daily.

For example, 37signals processes over 20 million jobs per day in a single Rails application, making efficiency crucial.

Let’s now check out the database.yml file to see how the queue system is structured.

How Solid Queue Uses Separate Databases for Performance

In the production environment, we see that Rails is using four separate SQLite databases, each dedicated to a specific purpose:

1. Primary Database → Stores standard Active Record models.
2. Cache Database → Manages cached data for improved performance.
3. Queue Database → Handles background jobs processed via Solid Queue.
4. ActionCable Database → Manages real-time WebSocket messages.

Why is this separation important?

• SQLite allows only one write operation at a time per database file.
• But if we separate concerns into multiple databases, writes can happen simultaneously across them.
• This ensures that queue jobs don’t block other database operations, allowing maximum performance and parallel execution of background jobs.

For example, Rails can be writing to the primary database at the same time that Solid Queue processes jobs in a separate database. This setup helps avoid concurrency contention and keeps applications running smoothly.

Configuring Solid Queue

Next, let’s explore how Solid Queue is configured in our Rails 8 app.

The solid_queue.yml file sets up dispatchers and workers:

• Dispatchers → Processes that schedule jobs to be executed.
• Workers → Processes that execute queued jobs inside Rails.

The recurring.yml file allows us to schedule recurring background jobs. For example, we could set up a job to clean up soft-deleted records at regular intervals. We’ll use recurring jobs later when setting up our automated backup system after the app is built.

Why Solid Queue is a Powerful Default for Rails 8

• Full-featured background job system.
• Supports concurrency controls, job priorities, and scheduled jobs.
• Seamlessly integrates with SQLite while avoiding write conflicts.
• Handles recurring jobs efficiently for maintenance and automation.

In the next videos, we’ll explore other Solid gems before diving into building our Rails 8 application! 🚀