The eternal debate

A monorepo holds many projects in one repository; multi-repo splits them. Both ship products at scale - Google and Meta favour mono, Amazon and Netflix favour multi. The "right" answer depends on team size, tooling investment, and integration patterns.

What monorepo gives you

• Atomic cross-project commits - rename an API and update every caller in one PR.
• Single source of truth - one version of every shared library at any time.
• Easier large-scale refactoring - linters and codemods run across everything.
• Unified tooling - one CI config, one lint config, one set of conventions.

What monorepo costs you

• Repo size grows without bound - clones, IDEs, and Git operations slow down.
• Tooling investment: Bazel, Nx, Turborepo, or similar to scope builds.
• Permission granularity is harder - everyone has at least read access to everything.
• CI must do affected-only builds or every push runs every test.

What multi-repo gives you

• Independent release cadence - each service ships on its own schedule.
• Smaller, focused repos that any tool can handle.
• Natural permission boundaries.
• Failure isolation - a broken main on one repo does not block others.

What multi-repo costs you

• Cross-repo changes require coordinated PRs - hard to make atomic.
• Shared libraries become "version diamond" problems.
• Tooling drifts - each repo evolves its own quirks.
• Discoverability suffers - "where is the X service?" becomes a real question.

Monorepo tooling essentials

# Sparse checkout to limit working tree
git sparse-checkout set apps/web shared/ui

# Partial clone for size
git clone --filter=blob:none <url>

# Affected-only builds with Nx
npx nx affected:test --base=main

Multi-repo coordination tools

# Manage many repos at once
gh repo list myorg --limit 200
# Bulk operations
for repo in $(gh repo list myorg --json name -q '.[].name'); do
  gh pr list -R myorg/$repo
done

Tools like meta, myrepos, and vcstool orchestrate operations across repo lists.

Hybrid approaches

You do not have to pick one. Common patterns:

• Monorepo for app code, separate repos for infrastructure.
• Monorepo per business domain.
• Multi-repo with a meta-repo of submodules for "the platform".

The honest decision factors

• Below 20 engineers, multi-repo is fine and simple.
• Above 200 engineers, monorepo wins if you invest in tooling.
• Between, it depends on how often code crosses project boundaries.

Migration is possible

Both directions are tractable. git filter-repo extracts subdirectories into new repos. git subtree merges repos into one. Plan it, schedule it, and treat the SHA churn as a one-time cost.