Ruby on Rails scalability: how GitHub, Shopify and GitLab scaled Rails (5 case studies)
GitHub.com, GitLab.com and Shopify's Shop app are all Ruby on Rails apps in the write-ups we track, and all five posts focus on the database and background jobs behind the Rails app. GitHub defined schema domains and linted cross-domain queries so it could move table groups onto separate MySQL clusters. GitLab.com split its CI tables into their own Postgres database to relieve its main database. Shopify sharded the Shop app's Rails backend with Vitess. GitLab also traced replica stalls to Postgres subtransaction overflow and removed subtransactions from its code, and GitHub broke one huge push-processing job into smaller, independently retried jobs driven by Kafka events.
5 of the 94 engineering write-ups in our database mention Ruby on Rails in their stack. They come from 3 companies (GitHub, GitLab and Shopify) and were published between 2021 and 2024. Techniques that show up most often alongside Ruby on Rails: vertical partitioning (2). It's often paired with MySQL (2), PostgreSQL (2) and Vitess (2). Each card below links to our short summary and the original post.
Ruby on Rails scalability issues in these stories
Splitting the main database: GitHub and GitLab both moved table groups into separate databases (vertical partitioning). Sharding: Shopify adopted Vitess to shard the Shop app's Rails backend, and its post covers keyspace design and the migration plan (Vitess case studies). Read replica stalls: GitLab found Postgres subtransaction overflow behind them. Oversized background jobs: GitHub split push processing into smaller jobs that can be retried on their own.
How we improved push processing on GitHub
GitHub broke one huge push-processing job into smaller, independently retried jobs driven by Kafka events.
Horizontally scaling the Rails backend of Shop app with Vitess
Shopify's Shop app adopted Vitess to shard its Rails backend, covering keyspace design and the migration plan.
We are splitting our database into Main and CI
GitLab.com split CI tables into their own Postgres database to relieve its main database.
Why we spent the last month eliminating PostgreSQL subtransactions
GitLab traced replica stalls to Postgres subtransaction overflow and removed subtransactions from its code.
Partitioning GitHub's relational databases to handle scale
GitHub defined schema domains and linted cross-domain queries so it could move table groups onto separate MySQL clusters.
FAQ
Does Ruby on Rails scale?
GitHub.com, GitLab.com and Shopify's Shop app run on Ruby on Rails in the write-ups we track. Their scaling posts are about the databases and background jobs behind the app: separate MySQL clusters by schema domain at GitHub, a separate CI database at GitLab, and Vitess sharding at Shopify.
How do you scale a Ruby on Rails app's database?
The approaches in our database are vertical partitioning (GitHub moved table groups onto separate MySQL clusters, GitLab split CI tables into their own Postgres database) and horizontal sharding (Shopify sharded the Shop app's Rails backend with Vitess).
What are common Ruby on Rails scalability issues?
In these five posts: a main database carrying too many tables (GitHub, GitLab), read replica stalls caused by Postgres subtransaction overflow (GitLab), and one huge background job (GitHub's push processing), which GitHub broke into smaller, independently retried jobs driven by Kafka events.