Side-by-Side Comparison
| Aspect | Monorepo | Polyrepo |
|---|---|---|
| Repositories | One repo, multiple projects | One repo per project |
| Shared code changes | One atomic commit updates library + all consumers | Separate commits/releases across repos, must coordinate versions |
| Versioning | Usually unified — everything lives at one commit/version | Independent — each repo has its own version history |
| CI/CD | Needs smart, incremental builds or it gets slow fast | Naturally scoped — each repo builds/tests independently |
| Access control | Coarser by default — usually repo-wide | Finer-grained — per-repo permissions |
| Onboarding | Clone once, see everything | Clone only what you need |
| Used by | Google, Meta, Microsoft (Windows), Twitter | Most independent microservice teams |
Monorepo ≠ Monolith
This is the single most common confusion. A monorepo is about where your source code lives (one repository). A monolith is about how your application is deployed (one runtime unit). You can absolutely run dozens of independently-deployed microservices out of a single monorepo — that is in fact exactly what Google does.
Why Monorepos Appeal to Large Companies
- Atomic cross-project changes: rename a function used by 40 services? One commit, one PR, one CI run — instead of 40 separate releases that must stay in sync.
- Easier code sharing: shared utilities, types, and components live right next to the code that uses them — no publishing an internal package and bumping version numbers everywhere.
- Single source of truth: one set of linting rules, one CI pipeline definition, one way of doing things across the whole codebase.
- Simplified dependency management: no risk of "works with library v2.3 over here but v1.8 over there" drift between projects.
Why Many Teams Prefer Polyrepos
- True team independence: each team owns its release cadence, its own CI pipeline, its own access control — no risk of accidentally breaking someone else's build.
- Smaller, faster clones: you only check out the code your team actually works on.
- Simpler tooling: standard Git workflows work fine without investing in specialised build orchestration.
- Clear ownership boundaries: a repo per service maps naturally to "one team owns one service" organisational structures.
⚠️ Monorepos Need Investment to Stay Fast
Naively running every test and rebuilding everything on every commit becomes unbearably slow as a monorepo grows. Tools like Nx, Turborepo, and Bazel solve this with dependency-graph-aware incremental builds — only rebuilding/retesting what actually changed and its dependents. Without that tooling investment, a growing monorepo's CI time becomes a serious productivity drag.
How Google Scales a Single Repo to Billions of Lines
Google's monorepo is famously enormous — far beyond what standard Git can handle efficiently. They use custom infrastructure: Piper (a proprietary version control system, not Git) and Bazel (a build system designed for massive, incremental, reproducible builds). This is a useful reminder: "monorepo" at Google's scale implies a completely different tooling stack than "monorepo" for a 10-person startup using Nx on top of GitHub.
💡 Practical Guidance
If your projects share a lot of code and move together, a monorepo with proper tooling (Nx/Turborepo) pays off quickly. If your services are genuinely independent, owned by different teams with different release cadences, a polyrepo keeps things simpler without needing extra tooling investment.
How We Research and Update This Guide
We test the underlying formula or workflow, compare outputs with reliable references, and revise examples whenever the page content changes.
- The workflow or formula is tested directly in the tool and compared against independent reference examples.
- Examples are kept practical so readers can verify the result without hidden assumptions.
- Pages are revised whenever the interface, calculation flow, or surrounding guidance materially changes.
Frequently Asked Questions — Monorepo vs Polyrepo
A monorepo is a single version-controlled repository that contains the code for multiple projects, services, or packages — for example, a frontend app, backend API, and shared component library might all live in one repository instead of three separate ones. It is a strategy for organising code, unrelated to whether the underlying applications are themselves monolithic or split into microservices.
A monorepo keeps multiple projects in one repository with one shared history; a polyrepo (multi-repo) gives each project its own separate repository with independent versioning and history. Monorepos make cross-project changes and shared code easier; polyrepos give each team full independence over their own release cycle and access control.
No — these are unrelated concepts. A monorepo is about source control organisation (one repo for many projects); a monolith is about runtime architecture (one deployable application). You can run microservices out of a monorepo (Google does this at huge scale) or run a single monolithic application out of its own dedicated repository.
Google's monorepo contains billions of lines of code and uses custom tooling (Bazel for builds, Piper for version control at scale) designed specifically to handle that scale — standard Git does not perform well with repositories that large. Most companies adopting monorepos at a smaller scale use tools like Nx, Turborepo, or Lerna, which add incremental builds and caching on top of standard Git.
An atomic commit changes everything related to one logical change in a single commit — for example, updating a shared library and every consumer of that library in one commit. In a monorepo, this is straightforward because everything lives in one repository. In a polyrepo, the same change requires coordinating separate commits and releases across multiple repositories, risking a window where consumers are out of sync with the library.
As a monorepo grows, naive tooling (full checkouts, running every test on every change, slow CI) can become painfully slow without investment in incremental build systems and caching. Access control is coarser — by default everyone can see and potentially touch everyone else's code, which is a problem for some security or compliance requirements. These downsides are solvable with the right tooling, but they are real engineering investments, not free.