The Monorepo vs Polyrepo Debate (2026)

Monorepo: all code in one repository. Polyrepo: separate repositories per service/package. Google uses a monorepo. Netflix uses polyrepos. Which is right for you?

What Each Means

Monorepo:

my-company/
├── apps/web/
├── apps/api/
├── apps/mobile/
├── packages/ui/
├── packages/utils/
└── packages/db/

One repo, multiple projects. Shared code via local packages.

Polyrepo:

my-company/web        → github.com/company/web
my-company/api        → github.com/company/api
my-company/mobile     → github.com/company/mobile
my-company/ui-lib     → github.com/company/ui-lib

Separate repos. Shared code via published npm packages.

The Honest Comparison

	Monorepo	Polyrepo
Code sharing	✅ Instant (local imports)	⚠️ Publish and install
Atomic changes	✅ One PR across packages	❌ Multiple PRs, coordinated deploys
CI complexity	⚠️ Need smart filtering	✅ Simple (one project per repo)
Team independence	❌ Shared CI, shared deps	✅ Full independence
Dependency management	✅ One lockfile	⚠️ Version conflicts between repos
Onboarding	⚠️ Large repo to clone	✅ Clone only what you need
Repo size	⚠️ Gets large over time	✅ Small, focused repos
Refactoring	✅ Find-and-replace across everything	❌ Coordinate across repos
Access control	⚠️ Everyone sees everything	✅ Per-repo permissions
Tooling required	Turborepo/Nx	Standard git

When to Use a Monorepo

• Shared code between projects (UI library used by web + mobile)
• Small to medium team (1-30 developers)
• Full-stack TypeScript (frontend + backend + shared types)
• Atomic changes matter (change API + client in one PR)
• Startup moving fast (minimize overhead)

When to Use Polyrepos

• Independent teams (each team owns their service)
• Different tech stacks (Python backend, React frontend)
• Large organization (50+ developers)
• Security/access control (restrict who sees what)
• Open source packages (each package is its own project)

Monorepo Tooling (2026)

Tool	Best For
Turborepo	Simple, fast, Vercel integration
Nx	Feature-rich, distributed caching, generators
pnpm workspaces	Package management (use with Turbo or Nx)
Changesets	Version management and changelog

Turborepo Setup

npx create-turbo@latest

// turbo.json
{
  "tasks": {
    "build": { "dependsOn": ["^build"], "outputs": ["dist/**", ".next/**"] },
    "dev": { "cache": false, "persistent": true },
    "lint": {},
    "test": {}
  }
}

turbo build              # Build everything
turbo build --filter=web # Build only web app
turbo build --filter=...[HEAD^1]  # Build only changed packages

The Real Answer (2026)

Default to monorepo unless you have a specific reason not to. Here's why:

1. Turborepo made it easy — the tooling is mature and simple
2. TypeScript benefits — shared types across frontend/backend
3. Atomic changes — change shared code and all consumers in one PR
4. pnpm workspaces — dependency management is solved

Switch to polyrepo when:

• Teams need true independence (different deploy cycles, different languages)
• Repo becomes too large (>10GB, >1000 packages)
• Access control is required (contractor can't see billing code)

Common Mistakes

Monorepo Mistakes

1. Not using Turborepo/Nx — manual dependency management is painful
2. Coupling everything — packages should have clear boundaries
3. Slow CI — need --filter to only build what changed
4. One giant package.json — use workspaces, not one flat project

Polyrepo Mistakes

1. Diamond dependency problems — package A and B depend on different versions of C
2. Cross-repo changes are painful — update shared lib → update every consumer
3. Drift — teams diverge on tooling, linting, patterns
4. Publishing overhead — every shared change requires publish + install

FAQ

Can I migrate from polyrepo to monorepo?

Yes. Move repos into subdirectories, set up pnpm workspaces and Turborepo. Keep git history with git subtree add.

Does Google really use one monorepo?

Yes. 86TB+ of code in one repo (with custom tooling). This doesn't mean you should — Google built their own version control and build system. Use Turborepo.

What about microservices?

Microservices can live in a monorepo or polyrepo. The decision is about code organization, not architecture.

Monorepo with different languages?

Works but Turborepo/Nx are JavaScript-focused. For mixed languages (Go + Python + TypeScript), polyrepo or Nx (which supports any language) may be better.

Bottom Line

Monorepo with Turborepo is the default for TypeScript teams in 2026. It's the simplest way to share code, make atomic changes, and keep consistency. Switch to polyrepo when team independence or access control requires it. The tooling debate is over — Turborepo makes monorepos easy.