Every few months someone declares Rails dead. Then Shopify reports another record Black Friday. In 2025, Shopify's Rails monolith handled 489 million requests per minute at peak with over 53 million database queries per second. That's not a framework that fails to scale Ruby on Rails.

But the "Rails can't scale" myth keeps coming back because the Ruby on Rails scalability issues people hit in production are real. They just aren't framework problems. They're architecture and discipline problems. Here's what we kept hitting in our own apps and what actually worked.

N+1 Queries Quietly Kill Your Database

This one shows up early and silently. You loop through 100 posts and call post.author.name, and ActiveRecord fires 101 queries. The page feels fine in dev with 5 records. In production with 50,000, it falls over. Slow queries are the most common Ruby on Rails scalability issues we see when auditing older codebases.
ruby
Slow: 1 + N queries
posts = Post.all
posts.each { |p| puts p.author.name }

Fast: 2 queries
posts = Post.includes(:author)
posts.each { |p| puts p.author.name }

We added the Bullet gem in development to flag every N+1 before it shipped. After cleaning the worst offenders across our top 10 endpoints, P95 response time dropped roughly 40%.

Memory Bloat and Ruby's Garbage Collector

Long-running Rails workers eat memory. Default malloc fragments quickly under heavy allocation, and worker RSS drifts up until restarts kick in. Memory pressure is one of the most expensive Ruby on Rails scalability issues to ignore.

Two fixes that paid off fast:

• Switch the system allocator to jemalloc. Most teams report 20-40% lower RSS per worker.
• Enable YJIT on Ruby 3.3+. Shopify reported a 15% speedup just by enabling YJIT on Ruby 3.3 in production storefront code. Rails at Scale

For batch jobs, swap Model.all.each for find_each(batch_size: 1000). That single change has saved us more outages than any monitoring tool.

Concurrency: Puma, Sidekiq, and Knowing What Blocks

Out of the box, a Puma worker on default settings handles a handful of concurrent requests. Fine for an MVP. Brutal for production traffic.

What worked for us:

• Tuned Puma to 5 threads × 2 to 4 workers per dyno based on actual CPU and memory headroom, not defaults.
• Moved every blocking task (PDF generation, third-party API calls, email, image processing) to Sidekiq.
• Split Sidekiq into queues by latency tolerance: critical, default, low. A bulk export shouldn't starve a webhook.

These three Ruby on Rails scalability issues account for maybe 80% of the production fires we've seen.

The Real Lesson About Scaling Rails

Rails scales when the architecture scales. The framework gives you the rails. You still have to lay them right. Profile before you optimize, eager-load before you cache, and move slow work off the request cycle.

If you're stuck on these walls and need help refactoring without burning a quarter, hire ruby on rails developers who've shipped through them. Most Ruby on Rails scalability issues are old problems with well-known fixes. The trick is figuring out which one's biting you today.