Monorepo vs Polyrepo

Monorepo (single repository for multiple projects) and polyrepo (one repository per project) represent different philosophies for code organization. Google, Meta, and Microsoft famously use monorepos. Most open-source projects and many companies use polyrepos.

Monorepo Advantages

The monorepo's biggest advantage is atomic changes. When you refactor a shared API, you update the implementation and all consumers in a single commit. No coordinated releases, no version bumps, no waiting for downstream teams to update.

Code sharing is trivial — just import from another directory. Dependency versions are unified, eliminating the diamond dependency problem where different projects require conflicting versions of the same library.

Polyrepo Advantages

Polyrepos give teams autonomy. Each team controls their own CI pipeline, release cadence, tooling, and access permissions. Repositories stay small and fast. There is no need for specialized build tools to determine what changed.

The Tooling Tax

Monorepos at scale require significant tooling investment. You need incremental builds (only rebuild what changed), affected-project detection, and potentially custom VFS for Git performance. Tools like Turborepo, Nx, and Bazel address these needs but add complexity.

For more on team structure and architecture decisions, see our system design interview guide and concepts library. Explore pricing for practice.

The Bottom Line

Use a monorepo when projects are tightly coupled and share significant code. Use polyrepos when teams need autonomy and independence. Many organizations use a hybrid: a monorepo for related frontend/backend packages and separate repos for independent services.