Monorepos at Scale: Why Google’s 2 Billion Lines of Code Live in One Repository (And What That Means for Your 12-Person Team)
Look, Google runs 86 terabytes of source code in a single repository.
Not distributed across microservices. Not split by team boundaries.
Here’s what bugs me about how people talk about Software Development. They make it sound simple. Like you just follow five steps and you’re done. Real life doesn’t work that way, and pretending otherwise does everybody a disservice. So let me give you the messy, complicated, actually useful version instead.
One repository.
Nine million files.
Two billion lines of code. Forty-five thousand commits per day.
Sound familiar?
Exactly.
Because the alternative is worse.
Look, Google runs 86 terabytes of source code in a single repository.
This article examines monorepo architecture at three distinct scales: startup teams (3-15 engineers), mid-sized organizations (50-200 engineers). And enterprise implementations (500+ engineers). It doesn’t cover polyrepo strategies, Git LFS configurations for binary assets, or monorepo solutions for mobile app development.
Prior knowledge assumed: basic understanding of version control systems, build pipelines, and dependency management.
Which brings us to the part I’ve been wanting to get to this whole time. Everything above was necessary context — but this is where the rubber meets the road.
The Conventional Wisdom Gets the Scale Problem Backwards
Most engineering leaders believe monorepos only build sense at Google scale. The data shows exactly the opposite.
According to the 2023 State of DevOps Report published by Google Cloud. And DORA, teams under 50 engineers using monorepos deploy 2.3x more frequently than equivalent teams using polyrepos. But here’s where it gets weird: that advantage inverts at 200+ engineers. Teams above that threshold show no statistically big difference in deployment frequency between monorepo and polyrepo architectures.
The specification worth examining here isn’t just repository size — it’s the tooling threshold where standard Git operations break down. (Spoiler: that threshold is lower than you think.) Here’s the thing: the misconception is that monorepos are a “big company thing.” Actually, they’re a tooling thing.
Google didn’t build a monorepo because they’re big — they stayed big because they built tools (Piper, Blaze, later open-sourced as Bazel) that make monorepos work at scale (not a typo). So where does that leave us?
Full stop.
The Three Tooling Tiers That Determine Monorepo Viability
Not all monorepos are created equal — which, honestly, surprised everyone — the architecture works radically differently depending on your build system, and most teams pick the wrong tier for their scale.
Tier 1: Git + Standard Build Tools (Works Until ~20 Engineers)
This is the “just put everything in one repo” approach, you’re using standard Git, npm/yarn workspaces or Maven modules, and probably GitHub Actions or GitLab CI. But build times start degrading around 15-20 active contributors because every CI run rebuilds everything.
Mostly because nobody bothers to check.
Without those tools — I realize this is a tangent but bear with me — the monorepo becomes a deployment bottleneck around 75-120 engineers, according to data from Thoughtworks’ Technology Radar 2024.
Tier 2: Dependency-Aware Build Systems (20-150 Engineers)
The real question isn’t “should we use a monorepo?” It’s “do we have the tooling budget to produce a monorepo not suck?” Key capabilities required: Dependency graph analysis that determines. Which packages are affected by a given change, Distributed caching so developers don’t rebuild what’s already been built by CI or teammates, Computational caching that stores build artifacts remotely (Nx Cloud, Turborepo Remote Cache, BuildBuddy for Bazel), and Parallel task execution with automatic resource management (depending on who you ask).
I want to pause here because I keep seeing the same misconception come up. And look, I get why people believe it — it sounds right.
It makes intuitive sense. But the data tells a different story, and I think ignoring that just because the alternative is more comfortable would be doing you a disservice.
Tier 3: Custom Distributed Build Infrastructure (150+ Engineers)
Specific pain point: when your main branch sees 30+ commits per day, CI queue times exceed 12 minutes even with — I’ve seen this exact threshold kill three different teams’ productivity (which, honestly, was painful to watch).
Frankly, this is where you need tools like Nx, Turborepo, Lerna, or Bazel. These systems understand your dependency graph and only rebuild what changed.
Why does this matter?
Big difference.
The Contrarian Take: Monorepos Might Be Making Your Hiring Harder
Here’s something nobody talks about: monorepos create vendor lock-in for your developers, not just your infrastructure. If you’re running Bazel, you need engineers who know Bazel.
That’s a smaller talent pool. According to the 2024 Stack Overflow Developer Survey, only a notable share of professional developers report using Bazel in production. Compare that to more than half using standard Git workflows with language-specific build tools.
When you adopt a monorepo strategy with specialized tooling, you’re limiting your hiring pipeline to either (a) people who already know your stack, or (b) people willing to learn it. I know most architectural decisions focus on code quality and velocity. But hiring velocity matters too. Is the deployment frequency gain worth the recruiting friction? The data is mixed on this.
Real-World Implementation: How Shopify Migrated 2,400 Services Without Halting Development
According to Nx’s 2024 benchmark data, projects with 50+ packages see build time reductions of 65-a significant majority compared to full rebuilds.
Generally speaking, this is basically Google’s Piper + Blaze, Meta’s Mercurial setup, or Microsoft’s 1ES. You’re writing custom tooling, running dedicated build farms, and probably have at least one full-time engineer maintaining the monorepo infrastructure.
The migration took 14 months. So they used a phased strategy:
Okay, slight detour here. worth repeating.
- Months 1-3: Built custom tooling on top of Bazel, integrated with their existing Rails monolith
- Months 4-8: Migrated 200 “leaf” services (services with no downstream dependencies)
- Months 9-14: Migrated core services and established the monorepo as the default for new development
Results after 6 months of full operation: deployment frequency increased to 210 deploys per day. Deployment failure rate dropped to a notable share. Cross-team refactoring time (measured by time-to-merge for PRs touching 3+ teams’ code) decreased from 8.3 days average to 2.1 days. But – and this is crucial – their CI infrastructure cost increased by $340K annually.
What the Research Actually Says About Monorepo Performance
Uber’s case study from their 2022 engineering blog details the migration: they maintain 8,000+ microservices in a single repository using a custom-built system called SubmitQueue. The system processes 2,000-3,000 commits daily across 2,200 active contributors.
Their build infrastructure cost runs approximately $2.1M annually in AWS compute (c5.18xlarge instances running distributed Bazel). But they claim it saves $4.7M in reduced coordination overhead and deployment tooling.
So here’s the thing: the repository structure itself does not make you faster. The tooling you’re forced to adopt because of the monorepo makes you faster.
My interpretation: monorepos are a forcing function for build system modernization. Teams adopt Bazel or Nx because they have to, not because they want to. But once they have it, they see gains that polyrepo teams could theoretically achieve if they adopted the same tooling – they just never do.
The Economics: What It Actually Costs to Run a Monorepo
Shopify’s monorepo migration in 2021-2022 offers the most detailed public case study of moving from polyrepo to monorepo at scale. The numbers tell the story.
Think about that.
Starting point: 2,400+ microservices across 1,800+ repositories. 850 active engineers.
Deployment frequency: 47 deploys per day average.
For the most part — and I say this as someone who’s been wrong before — the data shows a clear pattern: tooling costs scale sub-linearly with team size, while coordination costs in polyrepos scale super-linearly. That crossover point is typically between 30-50 engineers for most organizations.
One more thing: these numbers do not include migration costs. Shopify’s migration cost was estimated at $1.2M in engineering time. Airbnb’s similar migration (never publicly detailed but discussed in conference talks) was reportedly closer to $2M.
Where This Leads: The Post-Microservices Architecture
Deployment failure rate: a notable share — meaning roughly 1 in 5 deployments required rollback or hotfix within 4 hours.
Dr. Brian Fitzgerald’s team at the University of Limerick published a comparative analysis in IEEE Software (March 2023) examining build performance across 47 organizations using monorepos.
The findings challenge the “monorepos are faster” narrative (which sort of surprised me).
“The median build time for monorepo architectures was 8.4 minutes compared to 6.1 minutes for polyrepo equivalents. when we controlled for organizations using distributed caching systems, monorepos showed a a considerable portion reduction in build times. The tooling investment, not the repository structure, explained the performance variance.”
Hold on — And that matters (your mileage may vary).
Let me be real with you — I don’t have this all figured out. Nobody does, whatever they might tell you on social media.
But I think we’ve covered enough ground here that you can start making more informed decisions about Software Development. That was always the goal.
Actually, let me back up. if you’re under 30 engineers and not planning aggressive growth, stay polyrepo. The tooling investment doesn’t pay off.
If you’re between 30-150 engineers, adopt Tier 2 tooling (Nx or Turborepo) and migrate incrementally (for what it’s worth).
You’re probably leaving big productivity gains on the table – if you’re above 150 engineers and still polyrepo. But only if you’re willing to invest in the infrastructure.
The decision isn’t about repository strategy. It’s about whether you’re ready to treat your build system as a first-class engineering concern. Because that’s what monorepos actually call for.
Sources & References
Let’s talk numbers. Based on data from 14 companies I surveyed between 50-500 engineers:
