Key takeaway: Monorepos make cross-project changes easy and builds hard. Polyrepos make builds easy and cross-project changes hard. You are choosing which problem to invest tooling in.
What Each Structure Actually Changes
A monorepo holds all projects in one repository with one commit history. A change spanning three services is one atomic commit, reviewed once, landing everywhere simultaneously.
A polyrepo gives each project its own repository. Independent versioning, independent CI, independent access control.
The tempting framing is that one is modern and one is legacy. The accurate framing is that both move the same coordination cost to a different place.
The Symmetric Trade-Off
| Concern | Monorepo | Polyrepo |
|---|---|---|
| Cross-project change | One atomic PR | N coordinated PRs |
| Dependency version drift | Impossible | Constant background work |
| CI complexity | High — needs affected-target detection | Low per repo |
| Clone and tooling performance | Degrades with scale | Fine |
| Fine-grained access control | Hard | Native |
| Discovering all consumers of an API | Trivial grep | Requires a registry |
| Independent release cadence | Requires discipline | Native |
The monorepo advantage that matters most in practice is refactoring confidence. Renaming a function and finding every caller is a search rather than an archaeology project. Breaking-change migrations happen in one commit instead of a quarter-long campaign chasing repositories.
The polyrepo advantage that matters most is that everything works out of the box. Standard CI on a small repository is fast without any custom infrastructure.
The Tooling Prerequisite
A monorepo without build tooling is worse than a polyrepo, and this is where most failed adoptions go wrong. Running the full test suite on every commit becomes untenable within months.
What a monorepo requires:
- Affected-target detection so CI tests only what the change can influence
- Remote build caching so unchanged artefacts are never rebuilt
- Ownership rules mapping directories to reviewers
- Partial clone or virtual filesystem once history grows large
Bazel, Nx, Turborepo and Pants exist to provide this. Adopting a monorepo without adopting one of them means the build time grows with total repository size rather than with change size, which is the failure mode people cite when they say monorepos do not scale.
Polyrepos need investment too, just elsewhere: a dependency registry, automated update pull requests, and a genuine contract-testing discipline. The work does not disappear; it changes shape.
Choosing
Favour a monorepo when projects share code heavily, cross-cutting changes are frequent, teams are aligned on tooling, and someone will own build infrastructure. Favour polyrepos when projects are genuinely independent, release cadences differ substantially, external contributors need scoped access, or nobody has capacity to own a build system.
The Bottom Line
Decide based on where your pain currently is. If it is version drift and multi-repo refactors, a monorepo helps — provided you fund the build tooling. If it is CI complexity and coupled releases, polyrepos help. Migrating without addressing the tooling implication just relocates the problem.
