A practical comparison of monorepo vs polyrepo architectures: the honest pros and cons, tooling costs, what companies like Google and Amazon actually do, and a decision framework for choosing the right one for your team.
The monorepo-versus-polyrepo debate generates more heat than almost any other architectural argument, and most of it is misplaced. Both models work. Google runs one of the largest monorepos on earth, while Amazon and Netflix are widely associated with highly service-oriented, multi-repository environments, and all three ship excellent software at massive scale. The repository layout is rarely what makes or breaks a team.
What actually matters is whether your developers can find, understand, and change code across whatever structure you pick, and that depends far more on tooling than on topology. This guide gives you the honest trade-offs, a decision framework, and the part most comparisons skip: why the choice matters less than the debate suggests.
| Monorepo | Polyrepo | |
|---|---|---|
| Structure | One repository, many projects | One repository per project/service |
| Code sharing | Easy, direct imports | Requires versioned packages |
| Atomic cross-cutting changes | Yes, single commit | Hard, coordinated across repos |
| Team autonomy | Lower, shared conventions | Higher, independent choices |
| Access control | Coarser, repo-wide by default | Fine-grained, per repo |
| CI/build complexity | High, needs scaled tooling | Lower per repo, drift across repos |
| Discoverability | High by default | Low without extra tooling |
| Best fit | Tightly coupled, shared code | Independent services, autonomous teams |
The table above is the fast answer for those looking for a TLDR comparison. The rest of this guide explains when each row actually matters, because the right choice depends entirely on your team size, change patterns, and tooling budget.
A monorepo is a single version-control repository that contains multiple projects, services, or libraries, with all code sharing a single commit history. The defining property isn't size; it's that a single commit can change code across multiple projects atomically. When you update a shared library and every consumer in the same commit, that's the monorepo superpower.
The canonical example is Google, which stores billions of lines of code in a single repository used by tens of thousands of developers. Monorepos are also a natural fit for trunk-based development, where everyone commits to a shared mainline rather than maintaining long-lived branches. The catch is that monorepos at Google's scale require serious build infrastructure to stay fast, which is why purpose-built systems like Bazel exist.
A polyrepo (sometimes "multi-repo") splits the codebase into many independent repositories, typically one per service, library, or team. Each repo has its own history, its own CI pipeline, and often its own access controls and conventions. It's the default you get by accident: every time a team spins up a new service and runs git init, the org drifts further into a polyrepo.
The defining property is autonomy. A team can choose its own tooling, release on its own schedule, and grant access to exactly its repo without exposing anything else. That independence is genuinely valuable, especially for organizations with many loosely-coupled services and teams that don't need to coordinate often. The cost shows up when a change has to cross those boundaries, which, in practice, it does more often than the clean diagram suggests.
"What do the big companies use?" is the most common question in this debate, and the honest answer is: both, often within the same company. Google is the textbook monorepo, with most of its code in one repository. Meta and Microsoft also run very large monorepos for major product lines. Meanwhile, Amazon and Netflix are widely associated with highly service-oriented architectures spread across many independently-deployed repositories.
The useful takeaway isn't "copy Google." It's that the companies operating at the extremes of either model invested heavily in the tooling that model requires. Google's monorepo only works because of the build and code-search infrastructure built around it; Amazon's polyrepo sprawl only works because of heavy investment in service discovery and standardized pipelines. The lesson generalizes: the architecture you can afford is the one whose tooling you're willing to build or buy.
A note on terminology: "polyrepo" and "multi-repo" mean the same thing: many separate repositories. You'll see both terms used interchangeably.
Three questions resolve most decisions.
Small, tightly-coupled teams working on interconnected code benefit most from a monorepo's shared context and atomic changes. Large organizations with many autonomous teams that rarely touch each other's code often find polyrepos fit their org chart better. Conway's Law applies: your repository structure tends to mirror your communication structure, and fighting that is expensive.
Microservices push toward polyrepos, since independent deployability is the whole point, but the push isn't absolute. Plenty of teams run microservices inside a monorepo to get atomic changes and shared tooling while still deploying services independently. The deployment boundary and the repository boundary are separate decisions, and conflating them is a common mistake.
This is the deciding factor for most teams. A monorepo without scaled build tooling becomes slow and painful; a polyrepo without code-search and dependency tooling becomes an undiscoverable sprawl. Be honest about what you're willing to invest. If the answer is "very little," a polyrepo with light tooling is usually the more forgiving default, right up until you need to make your first big cross-repo change.
One more factor worth naming: switching costs. Migrating from polyrepo to monorepo or back is a real project, not a weekend, because it touches CI, access control, release processes, and every developer's mental model at once. Most teams don't migrate; they accumulate. A startup runs one repo, splits services out as it grows, and wakes up a polyrepo by default rather than on a per-decision basis. That drift is fine as long as the tooling keeps pace, and it's a problem precisely when it doesn't, which is why the honest version of this decision is less "monorepo or polyrepo" and more "are we investing in the tooling our actual structure needs?"
What's usually missed is that most of the pain on both sides is the same, but wearing different clothes: developers can't find code, can't understand it, and can't change it safely across boundaries. The monorepo solves discoverability by putting everything in one place, and creates a build problem. The polyrepo solves the build problem and creates a discoverability problem. A code intelligence layer dissolves the specific pain that makes teams want to switch.
For polyrepos, that means monorepo-grade discoverability without the monorepo: Code Search indexes every repository and branch across GitHub, GitLab, Bitbucket, Gerrit, and Perforce, so "where is this implemented" is a query, not a tour of a hundred repos. Cross-repository navigation resolves a symbol's definition and references even when they live in different services. And Batch Changes brings some of the monorepo's cross-repo coordination benefits to a polyrepo by applying a single declarative change across many repositories from a single spec and tracking the resulting pull requests for merge. It doesn't make the change a single atomic commit the way a monorepo would, but the cross-repo change that's a polyrepo's worst pain becomes one reviewed, tracked operation.
For monorepos, the same layer matters at scale: once the single repo holds millions of lines, the in-repo search and navigation that worked at small scale start to strain, and a dedicated code intelligence layer keeps the codebase navigable. Teams like Uber, Lyft, and Stripe run Sourcegraph across exactly these large, mixed environments. (Disclosure: Sourcegraph is our product, so weigh that accordingly; the broader point stands regardless of vendor.) The architecture decision sets your defaults; the tooling decision determines whether you actually feel the downsides.
There's no universal winner in monorepo versus polyrepo. There's a right answer for your team size, your change patterns, and your tooling budget, and the table near the top of this guide is the fastest way to find it. What's universal is the failure mode: choosing either model and then under-investing in the tooling that makes it livable. The monorepo without build infrastructure and the polyrepo without code intelligence both end up in the same place: developers who can't move.
If your team is wrestling with discoverability or cross-repo changes in a polyrepo, see how Code Search gives you monorepo-grade navigation across every repo you own, or book a demo to talk through your specific setup.
Is a monorepo a good idea? It is when your code is tightly coupled, your teams share a lot, and you're willing to invest in build tooling to keep it fast. It's a poor fit for large organizations of autonomous teams that rarely touch each other's code, where the coordination overhead outweighs the sharing benefits.
What is the opposite of monorepo? A polyrepo (or multi-repo): many independent repositories, typically one per service or library, each with its own history, CI, and access controls.
What big companies use monorepo? Google is the best-known example, with most of its code in a single repository, and Meta and Microsoft run large monorepos for major product lines. Other large companies, like Amazon and Netflix, lean polyrepo. Both approaches scale with sufficient tooling investment.
Is Google a monorepo? Yes. Google stores billions of lines of code in one repository accessed by tens of thousands of developers, supported by custom build and code-search infrastructure that makes that scale workable. It's the most-cited monorepo in existence, but the infrastructure behind it is the part teams forget to copy.
With Sourcegraph, the code understanding platform for enterprise.
Schedule a demo