Rails 8.2 shipped Wednesday and completes a project that started with the Solid trio in Rails 8.0: new applications now default to database-backed background jobs, caching, and websocket pubsub, with no Redis in the generated configuration at all. Solid Queue becomes the default Active Job adapter, joining Solid Cache and Solid Cable which took their defaults in previous releases. The rationale, which David Heinemeier Hansson has argued repeatedly, is that a modern Postgres or MySQL instance on modern hardware handles these workloads fine for the overwhelming majority of applications, and that a second datastore is operational complexity most teams do not need.
What Solid Queue actually does
Jobs live in database tables with a polling worker that uses row-level locking to claim work. That sounds like it should be slow and, at the scales most applications operate, it is not. Benchmarks published with the release show a Postgres 17 instance on modest hardware sustaining about 12,000 job enqueues per second and 8,400 completions per second across sixteen worker processes, with p99 pickup latency under 90 milliseconds.
export async function handler(request: Request): Promise<Response> { const started = Date.now(); const upstream = await fetch(request); const headers = new Headers(upstream.headers); headers.set("x-skarvonix-ms", String(Date.now() - started)); return new Response(upstream.body, { status: upstream.status, headers, });}Redis-backed Sidekiq is faster, roughly three times on the same hardware in the same benchmark, and Sidekiq's Pro and Enterprise tiers add capabilities Solid Queue lacks. The argument is not that Solid Queue wins on throughput. It is that an application processing 200 jobs per second does not care about the difference and does care about running one datastore instead of two, with one backup strategy and one failure mode.
Where the database approach breaks
Queue tables are write-heavy with a high delete rate, which produces table bloat in Postgres and requires vacuum tuning that most teams have never thought about. Rails 8.2 ships recommended settings and a maintenance task, and teams that ignore both will eventually see a queue table with more dead tuples than live ones and mysteriously degraded performance.
The other limit is connection pressure. Every worker holds a database connection, and a deployment with 40 workers plus web processes can exhaust the connection limit on a managed Postgres instance with a modest plan. The recommended configuration uses a separate database for queues, which Rails supports through multiple database configuration and which reintroduces some of the operational complexity the approach was meant to remove, though a second Postgres database is easier to run than a Redis cluster.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
The broader position this represents
Rails has been arguing against infrastructure complexity for several years, alongside Hansson's public campaign about leaving the cloud, which 37signals completed with claimed savings above $2 million annually. Kamal, the deployment tool the company built, ships with Rails and targets deployment onto plain servers rather than a managed platform. The Solid defaults fit that: fewer services, more things the framework handles.
The counterargument is that this optimizes for a specific scale and a specific team shape, namely small teams running applications that will never need to scale a queue independently. That describes a lot of Rails applications and not all of them. Companies running Rails at large scale, Shopify and GitHub most visibly, run architectures that look nothing like the defaults and always have.
The rest of 8.2
Active Record gained a composite primary key improvement that makes multi-tenant schemas less awkward, and a query annotation feature that tags queries with the controller and action that generated them, which shows up in database slow logs and makes attribution trivial. That second one is small and will save many hours of investigation.
The asset pipeline story continues its long simplification with Propshaft improvements and better handling of import maps. Turbo 9 ships alongside with a morphing implementation that preserves scroll position and form state more reliably. And the framework's authentication generator, added in 8.0, gained passkey support, which means a new Rails application can ship passwordless authentication without a gem.
Upgrading
Existing applications keep their current configuration; the defaults apply to newly generated applications. Migrating an existing Sidekiq deployment to Solid Queue is a real project involving job compatibility, monitoring changes, and a cutover plan for in-flight work. Rails ships a guide and there is no urgency, since nothing about Sidekiq stops working.
The teams that should consider it are the ones running Redis solely for jobs and paying for a managed instance to do it. That is a meaningful monthly cost for a small application and eliminating it is straightforward. Teams running Redis for caching, rate limiting, and session storage as well have less to gain and should probably stay where they are.
For anyone starting fresh, the defaults are the right choice and the reason is not performance. A new application with one datastore has one thing to back up, one thing to monitor, one connection configuration, and one set of failure modes to learn. That simplicity compounds over the first two years of a project in ways that are hard to quantify and easy to feel. If the application later outgrows database-backed queues, moving to Sidekiq is a well-trodden path with good documentation, and doing it at that point costs less than carrying Redis from day one for a workload that never needed it.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Open Source
