Monorepos vs. Polyrepos

As a company grows, a real architectural question emerges: one giant repository holding everything, or many small repositories, one per project or service? Both are legitimate, widely-used approaches with real trade-offs.

A monorepo holds multiple projects/services in a single repository. Google and Meta famously run enormous monorepos. Advantages: atomic cross-project changes (one commit can update a shared library and every consumer of it together), simpler dependency management (no version-mismatch problem between repos), and a single place to search/browse everything.

A polyrepo (many small, focused repositories) is the more common default for smaller teams. Advantages: clear ownership boundaries (a team owns its repository outright), independent versioning and release cycles, and — practically — Git and most tooling perform better on smaller repositories without extra configuration.

Monorepos need extra tooling at real scale. Plain Git wasn't originally designed for repositories with millions of files — companies running large monorepos typically add tools like sparse-checkout (only download the subset of the repo you're actually working on) or dedicated build systems (Bazel, and others) designed for monorepo-scale performance.

There's no universally correct choice — it depends on team size, how tightly coupled your projects genuinely are, and existing tooling. A small company with a handful of loosely related projects usually doesn't need monorepo complexity; a company with many services sharing extensive common code may find a monorepo's atomic-change benefit genuinely worth the added tooling investment.

Why this matters for you

Recognizing which model a codebase you're joining uses — and why — helps you understand its existing structure and tooling choices, rather than assuming your prior experience with the other model is how things "should" work here.

▶️ Before the next lesson

Think about (or look at) a codebase you work with regularly — is it structured as one repository per project, or several projects sharing one repository? Consider which trade-offs from this lesson actually apply to it.