{"id":5362,"date":"2026-09-23T17:38:34","date_gmt":"2026-09-23T09:38:34","guid":{"rendered":"https:\/\/arc.dev\/employer-blog\/?p=5362"},"modified":"2026-09-23T17:39:45","modified_gmt":"2026-09-23T09:39:45","slug":"ruby-on-rails-scalability","status":"publish","type":"post","link":"https:\/\/arc.dev\/employer-blog\/ruby-on-rails-scalability\/","title":{"rendered":"Ruby on Rails scalability: how Rails handles growth from MVP to millions of users"},"content":{"rendered":"\n

Written for Ruby on Rails 8.1.3.1 (July 29, 2026).<\/p>\n\n\n\n

“Rails doesn’t scale.” “Rails is fine for an MVP, but you’ll rewrite it once you grow.” “Twitter left Rails because it couldn’t handle scale.” If you’re deciding whether to build on Rails or keep investing in the Rails app you already have, you’ve heard all three.<\/p>\n\n\n\n

Those claims deserve a real answer, not a defensive one. Rails scales through a well-known sequence of fixes applied in order: eager loading, background job offloading, caching, horizontal web scaling, read replicas, and eventually sharding, <\/strong>and the companies running Rails at the largest scale today use exactly those mechanisms rather than a secret framework. <\/p>\n\n\n\n

During BFCM 2025, Shopify’s app servers peaked at more than 117 million requests per minute, with 489 million per minute at the edge and 14.8 trillion database queries across the weekend (Shopify<\/a>). A year earlier, the peaks were 80 million on app servers and 284 million at the edge (Shopify Engineering<\/a>). That’s about 46% more app-server traffic and 72% more edge traffic year over year, and Shopify got there by sharding Rails’ database layer rather than leaving Rails.<\/p>\n\n\n\n

What follows walks through the growth curve: which bottleneck hits first, which fix belongs at which traffic stage, where Ruby’s per-process throughput becomes a real cost, and when a rewrite is the wrong response to a caching problem.<\/p>\n\n\n\n

In this guide:<\/strong><\/p>\n\n\n\n

    \n
  1. Does Rails scale for high-traffic products?<\/li>\n\n\n\n
  2. When do Rails applications need a new scaling strategy?<\/li>\n\n\n\n
  3. How to scale the request and job layers<\/li>\n\n\n\n
  4. How to keep the database from becoming the bottleneck<\/li>\n\n\n\n
  5. What senior Rails expertise changes during growth<\/li>\n\n\n\n
  6. Frequently asked questions<\/li>\n\n\n\n
  7. Building a Rails system that grows deliberately<\/li>\n<\/ol>\n\n\n\n

    Does Rails scale for high-traffic products?<\/strong><\/h2>\n\n\n\n

    Rails scales to millions of users, and the framework rarely breaks. The database, the job queue, and missing caching break first, in roughly that order.<\/p>\n\n\n\n

    The short answer: what Rails can and cannot solve<\/strong><\/h3>\n\n\n\n

    Rails solves the parts of scaling that are about structure: connection pooling through Active Record, background work through Active Job, fragment and low-level caching through the cache store, read\/write splitting through multiple database configurations, and horizontal sharding through Active Record’s connects_to API.<\/p>\n\n\n\n

    Rails cannot solve raw per-process throughput. Ruby executes fewer requests per second per CPU core than Go or the JVM for the same CPU-bound work. That gap is real, and you pay for it in server count.<\/p>\n\n\n\n

    The tradeoff is straightforward. You spend more on compute and less on engineering time. For a team of 10 to 100 people shipping product features, that trade favors Rails. For a service parsing binary protocols at single-digit millisecond latency budgets, it does not. <\/p>\n\n\n\n

    As teams grow past a single squad, the tradeoff shifts again; our guide to <\/strong>Rails and agile delivery at scale<\/strong><\/a> covers the modular-monolith patterns<\/strong> (engines, service objects, enforced module boundaries) that keep multiple teams shipping to the same Rails app without stepping on each other.<\/p>\n\n\n\n

    YJIT, Ruby’s just-in-time compiler, narrows the gap. Shopify’s Ruby & Rails infrastructure team built it, and it shipped upstream in Ruby 3.1. There’s nothing to configure: Rails 7.2 and later, including Rails 8, turn YJIT on by default<\/a> when your app runs on Ruby 3.3 or newer.<\/p>\n\n\n\n

    Ruby 4.0<\/a>, released December 25, 2025, adds a second JIT called ZJIT<\/a>, built by the same Shopify compiler team behind YJIT. ZJIT is experimental. The Ruby core team says it’s faster than the interpreter but not yet as fast as YJIT, and advises holding off on production use.\u00a0<\/p>\n\n\n\n

    Their goal is to make it faster than YJIT and production-ready in Ruby 4.1. Until then, keep YJIT on in production and wait for 4.1 before testing ZJIT on real traffic.<\/p>\n\n\n\n

    Claim vs. reality: why scaling problems are often architectural<\/strong><\/h3>\n\n\n\n

    Most “Rails is slow” incidents trace back to code, not the framework.<\/p>\n\n\n\n

    Common claim<\/strong><\/td>What’s usually happening<\/strong><\/td>The named fix<\/strong><\/td><\/tr>
    “Rails can’t handle our traffic”<\/td>N+1 queries multiplying under concurrency<\/td>includes \/ preload eager loading, caught by the Bullet gem<\/td><\/tr>
    “The database keeps falling over”<\/td>Every request hits the primary; no cache layer<\/td>Solid Cache or Redis for hot paths, plus a read replica<\/td><\/tr>
    “Response times spike at peak”<\/td>Slow third-party API calls inside the request cycle<\/td>Move to Active Job with Solid Queue or Sidekiq<\/td><\/tr>
    “We’ve maxed out our server”<\/td>Single Puma instance, no horizontal layer<\/td>Multiple stateless app containers behind a load balancer<\/td><\/tr>
    “We need microservices”<\/td>One fat model and no query indexes<\/td>Add indexes, extract service objects, keep the monolith<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Rails scales when the architecture underneath it scales. Every “Rails can’t handle it” claim in the table above traces back to a fixable pattern, not a hard ceiling in the framework itself.<\/p>\n\n\n\n

    Scale is one part of the case for Rails. For adoption data, download numbers, and the companies still running it in production, see our look at whether Ruby on Rails is still relevant in 2026<\/a>.<\/p>\n\n\n\n

    What “millions of users” actually means for throughput, data, and concurrency<\/strong><\/h3>\n\n\n\n

    “Millions of users” is a vanity number. Three figures decide your architecture:<\/p>\n\n\n\n

      \n
    1. Peak requests per second.<\/strong> A million monthly users with a weekly-check-in usage pattern might peak at 200 requests per second. A million users on a real-time chat product might peak at 20,000. The second app needs a fundamentally different topology.<\/li>\n\n\n\n
    2. Working data set size versus RAM.<\/strong> Postgres stays fast as long as hot rows fit in memory. Once your active table exceeds available RAM, query times jump, and you need partitioning, archival, or a bigger instance.<\/li>\n\n\n\n
    3. Concurrent open connections.<\/strong> A request\/response app releases its connection in 80 milliseconds. A WebSocket app holds thousands of connections open at once, which is where Action Cable’s adapter choice matters.<\/li>\n<\/ol>\n\n\n\n

      Measure all three before you buy infrastructure.<\/p>\n\n\n\n

      When do Rails applications need a new scaling strategy?<\/strong><\/h2>\n\n\n\n

      You need a new strategy when the current bottleneck no longer responds to the current fix. Adding a bigger server to an N+1 problem buys you a week; adding eager loading fixes it permanently.<\/p>\n\n\n\n

      Scaling stages: from MVP traffic to sustained growth<\/strong><\/h3>\n\n\n\n

      Bottlenecks arrive in a predictable order because fixing one unmasks the next.<\/p>\n\n\n\n

      \"\"<\/figure>\n\n\n\n

      First: N+1 queries surface under load.<\/strong> In development with 20 seed records, a loop firing 21 queries feels fine. At 500 concurrent users, those queries saturate the connection pool and requests start queuing on the database.<\/p>\n\n\n\n

      Second: the connection pool runs out.<\/strong> Puma with 4 workers and 5 threads each wants 20 connections. Add background job workers, and you’ll quickly exceed the default managed Postgres connection limit. You’ll see ActiveRecord::ConnectionTimeoutError in the logs before you see slow queries.<\/p>\n\n\n\n

      Third: the background job queue backs up.<\/strong> Emails, webhook deliveries, and PDF generation pile up. Jobs that ran in 2 seconds now sit in the queue for 40 minutes, and users notice because their receipt never arrives.<\/p>\n\n\n\n

      Fourth: the single server hits its memory or CPU ceiling.<\/strong> Ruby processes are memory-hungry. Four Puma workers on a 2 GB instance will start getting OOM-killed, and you cannot thread your way out of it.<\/p>\n\n\n\n

      Fifth: cache and session invalidation get messy.<\/strong> Once you’re running multiple app servers, in-process caching and cookie-based session assumptions break. Stale fragments and logged-out users become the new bug class.<\/p>\n\n\n\n

      How monitoring reveals the real bottleneck<\/strong><\/h3>\n\n\n\n

      You cannot fix what you haven’t measured, and Rails gives you the instrumentation for free through Active Support notifications.<\/p>\n\n\n\n

      Wire up an APM that reads those events. AppSignal, Datadog, New Relic, and Skylight all break request time into database, view rendering, and external HTTP segments. That breakdown alone is usually enough to point to the bottleneck, often within the same day you set up the alert.<\/p>\n\n\n\n

      For production visibility across services, instrumenting requests with OpenTelemetry’s Ruby SDK<\/a> alongside Puma worker and thread tuning gives you the trace data needed to hold a latency SLO under load.<\/p>\n\n\n\n

      Add rack-mini-profiler in staging. It shows per-request SQL inline, which makes N+1 patterns obvious without reading logs.<\/p>\n\n\n\n

      Latency, Error Rate, Queue Depth, and Database Saturation Signals<\/strong><\/h3>\n\n\n\n

      Four numbers tell you which fix to reach for.<\/p>\n\n\n\n

        \n
      1. p95 request latency climbing while p50 stays flat.<\/strong> A subset of requests is doing heavy work. Look for uncached expensive queries or a slow external API call on one endpoint.<\/li>\n\n\n\n
      2. ActiveRecord::ConnectionTimeoutError in your error tracker.<\/strong> Your pool is exhausted. Resize the pool or reduce concurrency per process before you scale out.<\/li>\n\n\n\n
      3. Job queue depth trending up instead of oscillating.<\/strong> Your workers cannot keep pace with the enqueue rate. Add dedicated worker processes per queue, and split latency-sensitive queues from bulk ones.<\/li>\n\n\n\n
      4. Database CPU above 70% sustained, or replica lag over a few seconds.<\/strong> You’re saturating the primary. Move read-heavy endpoints to a replica, or cache them.<\/li>\n<\/ol>\n\n\n\n

        Set alerts on all four. Discovering queue depth at 400,000 jobs during a launch is avoidable.<\/p>\n\n\n\n

        How to scale the request and job layers<\/strong><\/h2>\n\n\n\n

        Scaling the request layer means making every web process stateless so you can run many of them, and scaling the job layer means moving anything slow out of the request cycle entirely.<\/p>\n\n\n\n

        Horizontal scaling, load balancing, and web-process concurrency<\/strong><\/h3>\n\n\n\n

        Rails apps scale horizontally when web processes hold no state. Sessions go to a shared store (encrypted cookies, Redis, or the database), uploaded files go to object storage through Active Storage, and cache goes to Solid Cache or Redis. Then any request can hit any process.<\/p>\n\n\n\n

        Inside each process, Puma handles concurrency with workers and threads. Workers are separate OS processes with their own memory. Threads share memory inside a worker. A common starting point is workers equal to CPU cores, with 3 to 5 threads per worker, then tuned against real latency data.<\/p>\n\n\n\n

        Above that, three deployment patterns dominate real Rails production today:<\/p>\n\n\n\n