If your Rails application sends emails, generates PDF invoices, or syncs data with a third-party service, it probably uses background jobs. And if it has been around for a few years, chances are those jobs run on DelayedJob. That was the right call at the time. Today, Rails 8 offers a built-in successor that is simpler and more reliable: Solid Queue. Here is why the switch is worth it, and how it plays out in practice.
What exactly is a "job"?
When a visitor clicks "Place my order," they shouldn't have to wait for the confirmation email to go out, the PDF to be generated, and the accounting to update before their page reloads. Those operations are offloaded: the application drops them into a queue and runs them in the background while the user keeps browsing. That is what a job is — a unit of deferred work.
The typical cases are everywhere: sending emails and notifications, processing images, exporting data, calling external APIs, reports scheduled overnight. Without a job system, these tasks slow down every page or, worse, fail silently. With one, they become reliable and replayable: a job that fails can be retried automatically, with no intervention.
DelayedJob: what has aged
DelayedJob was the default choice for a long time, and it still works. But it is no longer actively supported the way it once was, and its model is showing its age. It relies on a database-locking mechanism that handles large volumes poorly, offers little visibility into what is running, and its failure handling remains rudimentary. Many teams have in fact left it for Sidekiq — powerful, but requiring Redis, and therefore an additional server to install, secure, back up, and pay for.
The real problem isn't technical, it's strategic: every external component is one more moving part. A part that can break down, that needs updates, and that your provider has to understand in order to intervene. The fewer there are, the simpler your application is to maintain over time.
Solid Queue: the new standard, with no dependency
Solid Queue is the background job system shipped by default with Rails 8. Its strength comes down to one sentence: it relies on your existing database (PostgreSQL, MySQL, SQLite), with no Redis or any third-party service. Jobs are stored in tables in your database, alongside your business data.
The benefits are direct. Fewer moving parts: no more Redis to host, one less component that can go down on a Sunday night. Stronger reliability: jobs benefit from your database's transactions and backups, so nothing gets lost between two systems that have fallen out of sync. Long-term support: it is maintained by the Rails team itself, which guarantees updates and long-term compatibility. Solid Queue also handles scheduled tasks (the equivalent of a cron) and priorities natively, without any extra add-on.
For a business owner, the math is simple: one less component to maintain, a lighter hosting bill, and a foundation that any Rails developer will be able to work on tomorrow, because it has become the standard.
What does the migration look like?
The good news is that Rails introduced an abstraction layer, Active Job, which separates your tasks from the tool that runs them. If your application is already written cleanly, your jobs don't even know whether they are running on DelayedJob or on Solid Queue. The work then mostly consists of flipping the switch: installing Solid Queue, creating its tables, and pointing the call sites to the new engine.
In practice, the migration unfolds in a few controlled steps: install Solid Queue and generate its tables, switch over the queue configuration, replace any remaining call sites that invoked DelayedJob directly, then run both in parallel long enough to drain the old queue. No downtime is required. The main risk isn't the switch itself but the old, non-standardized calls inherited from before Active Job — that's where a code audit makes the difference.
For a mid-sized Rails application, the job is measured in hours, not weeks. This is exactly the kind of fixed-price upgrade that we take on: an audit of the call sites, a tested migration, and a switch with no outage. Want to know what it would look like for your application? Take a look at our resources or our pricing, and let's talk.