Performance Gains After a Rails Upgrade from 7 to 8

Between deprecation warnings, gem compatibility checks, and the inevitable late-night debugging session, the process can feel like a lot of effort for an uncertain payoff. Having recently taken a mid-sized Rails application from version 7 to version 8, I wanted to share what actually changed on the performance side, because the gains were more concrete than we expected. Faster Boot Times One of the first things I noticed was a noticeably quicker boot process, both in development and in CI. Rails 8's continued investment in Zeitwerk autoloading refinements and leaner default middleware stacks shaved real seconds off cold starts. For a test suite that runs hundreds of times a day across a team, this adds up to meaningful time saved. Solid Queue, Solid Cache, and Solid Cable The biggest architectural shift in Rails 8 is the "Solid" trio: Solid Queue, Solid Cache, and Solid Cable. These let you run background jobs, caching, and Action Cable using your existing database instead of standing up Redis or Sidekiq separately. After migrating our background job processing to Solid Queue, we saw a drop in operational complexity and, surprisingly, an improvement in job throughput for our workload. Fewer moving parts meant fewer network hops between services, and our infrastructure costs dropped since we could retire a dedicated Redis instance. Improved Asset Pipeline Defaults Rails 8 leans further into import maps and Propshaft as sensible defaults, avoiding the overhead of Node-based bundling for teams that don't need it. Our asset compile times during deployment dropped significantly, and the simplified pipeline reduced flakiness in our CI builds. Kamal 2 and Deployment Speed While not strictly a "Rails performance" feature, the tighter integration with Kamal 2 for deployments meant our release cycle got faster and more reliable. Zero-downtime deploys became easier to configure out of the box, which indirectly improved perceived performance for users during releases. Database and Query Improvements Active Record continues to benefit from incremental query optimizations, and we noticed lower query times on some of our heavier reporting endpoints after the upgrade, likely a combination of Rails-level improvements and the chance to clean up N+1 queries we found while testing. The Real-World Impact In our internal benchmarks: Average response time dropped by roughly 18% Background job throughput increased by about 25% Infrastructure costs fell due to Redis retirement CI pipeline time decreased by nearly 15% Was It Worth It? Yes. The Rails upgrade required real effort, particularly around adapting to Solid Queue and auditing deprecated APIs, but the performance and operational simplicity gains justified the investment. If you're running Rails 7 and wondering whether Rails 8 is worth the migration effort, our experience suggests it is, especially if you're currently juggling Redis, Sidekiq, and a separate WebSocket service that could be consolidated. If you're planning your own upgrade, budget time for testing background jobs thoroughly, since that's where the biggest architectural shift lives. The payoff, in both speed and simplicity, is worth it.