TL;DR:

  • Monorepos solve code sharing and atomic changes; polyrepos solve team autonomy and independent deployment cadences
  • Nx and Turborepo are mature enough in 2026 that monorepo tooling is no longer a significant blocker for mid-sized teams
  • The migration decision should be driven by specific pain (code sharing friction, dependency drift) not by what large tech companies do

Monorepo vs polyrepo is one of the most debated architectural decisions in software engineering — and one of the most context-dependent. The right answer for a 10-person startup is different from the right answer for a 500-person engineering organisation, and different again for an open source project with external contributors.

What Each Model Is

A monorepo (monolithic repository) stores multiple projects or services in a single git repository. All code — frontend, backend, shared libraries, infrastructure — is versioned together. A single commit can touch all of them.

A polyrepo (multiple repositories) gives each service or library its own repository. Teams own their repo independently. Releases and deployments are decoupled.

Neither is inherently better. They optimise for different things.

The Core Tradeoffs

Monorepo advantages: atomic changes (update a shared library and every consumer in a single commit — no coordination across repos, no version bumping, no broken consumers in the gap between publish and update), code sharing without npm (shared utilities live in packages inside the monorepo, no publishing or versioning needed), unified tooling (one CI pipeline, one linting configuration, one testing setup), and visible dependencies (you can see every place a function is called across the entire codebase, making confident refactoring possible).

Monorepo disadvantages: CI/CD complexity (running all tests on every change doesn’t scale — you need tooling to run only what’s affected), team coupling (when multiple teams share a repository, someone’s failing tests block everyone’s merge), and repository size (a monorepo at scale is a large git repository; clone times and tooling performance degrade without investment).

Polyrepo advantages: team autonomy (teams own their repository, their CI pipeline, their deployment cadence — no coordination required), independent deployment (a failure in Service B doesn’t affect Service A’s release), and simpler individual repos (each repository is focused and comprehensible on its own).

Polyrepo disadvantages: dependency drift (over time, different repos use different versions of the same library; the organisation accumulates multiple versions of the same security vulnerability — a significant concern for teams who need to respond quickly to CVE disclosures), cross-repo changes are painful (updating a shared interface requires coordinated PRs across multiple repositories), and duplicated tooling (each repository has its own linting config, CI setup, and testing infrastructure).

Monorepo Tooling in 2026

The primary objection to monorepos has historically been tooling: naive CI runs everything on every change, which doesn’t scale. In 2026, the tooling problem is solved.

Turborepo (Vercel) is the simplest entry point for JavaScript/TypeScript monorepos. It adds build caching and affected-task detection with minimal configuration. If you’re running npm run build across packages, Turborepo cuts those times significantly by caching outputs and detecting which packages actually changed.

// turbo.json
{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["build"]
    }
  }
}

Nx (Nrwl) is more opinionated and feature-complete. It includes code generation, dependency graph visualisation, affected-test detection, and distributed task execution. The learning curve is steeper but the capabilities are broader — particularly for large teams that want enforcement of module boundaries between packages.

Bazel (Google’s build system) is the right choice only for very large engineering organisations where compile-time dependency analysis and distributed caching matter at scale. The configuration overhead is significant; it’s not appropriate for teams under a few hundred engineers.

Which Fits Different Team Sizes

Startup or small team (1–15 engineers): Monorepo is almost always the right default. The coordination overhead of polyrepo is high relative to team size. Code sharing is simple. Atomic changes across frontend and backend matter daily.

Mid-size team (15–100 engineers): Depends on organisational structure. If multiple teams own distinct services with independent deployment needs, polyrepo makes sense. If the product is an interconnected application, monorepo with Nx or Turborepo scales here without significant pain.

Large team (100+ engineers): Both work, but polyrepo is harder to manage without significant investment in internal tooling for dependency management and cross-repo changes. Many large companies (Google, Meta, Microsoft) run massive monorepos. Many others run polyrepos with tooling.

When to Migrate

Migrate to monorepo when: teams are spending significant time coordinating cross-repo changes, shared library consumers are routinely out of sync, or code duplication across repos is creating maintenance burden.

Migrate to polyrepo when: a monorepo’s CI pipeline is consistently blocking unrelated teams, different services have fundamentally different deployment cadences (mobile app vs. web service vs. data pipeline), or regulatory requirements mean different parts of the codebase need different access controls.

Don’t migrate because Google uses a monorepo or Netflix uses polyrepo. What works at their scale and org structure has limited transferable signal to most teams. Pick based on your actual friction, not architecture fashion.

The Bottom Line

Monorepos are a better default for teams that share code and make cross-service changes regularly. Polyrepos are better for teams that operate autonomously with well-defined service boundaries. The tooling gap has closed — Turborepo and Nx mean that “CI won’t scale” is no longer a reason to avoid monorepos. Make the decision based on where your actual friction is.