Monorepo vs Polyrepo: Which Should Your Team Use?
One big repository or many small ones? Here's the real trade-off between monorepos and polyrepos — and how to pick based on your team, not the hype.
A monorepo keeps all your projects in one git repository. A polyrepo gives each project its own. The internet has strong opinions, but the right answer depends on your team's size and how tightly your projects are coupled.
The case for a monorepo
- One source of truth. Shared code, one place. A change and the code that uses it update together in a single commit.
- Easier refactors. Rename something everywhere atomically.
- Shared tooling. One lint config, one CI setup, consistent everything.
The cost: repos get big, and naive tooling slows down. You'll want smart build systems that only rebuild what changed, or it crawls.
The case for polyrepos
- Clear ownership. Each team owns its repo, its releases, its access.
- Independent deploys. Ship one service without touching others.
- Simple tooling per repo. Each stays small and fast on its own.
The cost: sharing code means versioned packages and dependency juggling, and a cross-cutting change becomes many coordinated pull requests.
Monorepos optimise for working together; polyrepos optimise for working independently.
How to actually decide
| Lean monorepo if… | Lean polyrepo if… |
|---|---|
| Projects share lots of code | Services are truly independent |
| Small-to-mid team, tight collaboration | Many teams with clear boundaries |
| You'll invest in build tooling | You want simple per-repo setups |
For most small teams, a monorepo is the lower-friction start — fewer moving parts, easy shared git workflow. Reach for polyrepos when independent ownership and deploys matter more than shared code.
Key takeaways
- Monorepo = one repo for everything; polyrepo = one per project.
- Monorepos ease sharing and refactors but need smart build tooling.
- Polyrepos give clean ownership and independent deploys.
- Small, tightly-coupled teams usually start happier in a monorepo.
Frequently asked questions
Do big tech companies use monorepos?
Several famously do (Google, Meta) — but with heavy custom tooling to make a giant repo fast. Don't copy the structure without copying the tooling investment.
Can I switch later?
Yes, but it's work. Splitting a monorepo or merging polyrepos means rewriting CI, dependency and release processes. Choose deliberately, but it's not a one-way door.