Monorepo vs Polyrepo: How to Choose in 2026 (with Examples)
Monorepo or polyrepo? Compare code sharing, CI/CD, ownership, and tooling (Turborepo, Nx, pnpm workspaces, Bazel) with a decision matrix and real case studies from Google, Meta, Vercel, and Netflix.
Published: 2026-08-28
Monorepo or polyrepo is one of the highest-leverage architecture calls a growing engineering team makes. Get it right and code sharing, refactors, and onboarding stay cheap as you scale. Get it wrong and you spend the next two years fighting your repo layout instead of shipping product.
This guide gives you a decision matrix at the top, then the actual tradeoffs, the 2026 tooling landscape, and case studies from companies running each setup at scale. By 2026, monorepos are mainstream: industry surveys put adoption above 60% at companies with 50+ developers. That does not mean monorepos are right for you. It means the tooling has finally caught up to the pattern.
TL;DR: when to pick which
Pick a monorepo if:
Multiple apps share code (component libraries, types, utils, auth SDKs).
Atomic cross-app refactors are common (rename a shared API, every consumer updates in one PR).
Most apps share a language stack (all TypeScript, all Python, all Go).
You want one CI config, one lockfile, one source of truth.
Team size is under roughly 200 engineers, or you have the resources to invest in custom build tooling.
Pick a polyrepo if:
Apps are independent products with their own release cadences.
Different languages, frameworks, or runtime targets per app.
Teams own services end-to-end and rarely touch each other's code.
Strict isolation is a security or compliance requirement.
You want repo-level access control as a hard boundary.
Quick comparison
| Question | Monorepo | Polyrepo |
|---|---|---|
| Code sharing | Workspace links (workspace:*) | Published private packages |
| Atomic refactor | One commit | Coordinated PRs across repos |
| Team independence | Conventions enforced centrally | Each team picks its own tools |
| CI complexity | One config + affected filters | One config per repo |
| Onboarding | Clone once, install once | Clone per project |
| Build tools | Turborepo, Nx, Bazel | Standard Git tooling |
| Repo-level permissions | Coarse | Native per-repo |
Definitions
A monorepo stores multiple projects (packages, apps, services) in a single Git repository, usually with workspace tooling that links them together at the package-manager level.
A polyrepo (also called multirepo) splits each project into its own Git repository. The two terms mean the same thing; "polyrepo" became more common after monorepos got hyped around 2018.
A hybrid sometimes shows up: one repo per business unit, each one internally a monorepo. Treat that as an architectural detail, not a fourth pattern.
What monorepos actually win on
Atomic refactors. Rename a function in a shared library and every consumer updates in the same commit. CI either passes or it does not. No coordination across PRs in different repos.
One source of truth for dependencies. A single lockfile means every app is on the same React, the same Postgres client, the same auth SDK. Version drift is impossible by construction.
Easier onboarding. A new engineer clones one repo, runs one install, has a working dev environment for every internal service. Polyrepo onboarding usually means three days of "now clone these other 14 repos."
Visibility. Code search across the company is one ripgrep away. Cross-team understanding goes up when everyone reads the same codebase.
Cheaper code sharing. Workspace protocols link packages without publishing to npm. No version negotiation between teams, no internal package registry to maintain.
What polyrepos actually win on
Smaller blast radius. A bad merge in one repo cannot break everyone else's CI. Repo-level branch protection and CODEOWNERS work without ceremony.
True team ownership. Each team picks its own language, framework, lint rules, release cadence. Nobody waits for a platform team to bless a tooling change.
Independent deploys. No coordination on what is in main right now. Each service ships when its team decides.
Smaller checkouts. Engineers clone what they actually work on, not the whole company.
Security boundary. Repo permissions become an access control mechanism. Compliance and audit teams strongly prefer this model.
The 2026 tooling landscape
Monorepo tooling splits into four layers, and most teams need three of them:
Workspace managers (link packages on disk):
pnpm workspaces, npm workspaces, Yarn workspaces, Cargo workspaces, Go workspaces. Built into the package manager. Free. Good enough for small monorepos.
Task runners with caching (the layer most teams want):
Turborepo. Best fit for 5 to 50 JS/TS packages. Quick to set up, integrates cleanly with Vercel and most CIs. Less opinionated than Nx, which suits smaller teams. Made by Vercel.
Nx. Best for larger or polyglot monorepos. Brings code generation, architectural enforcement (boundary lint rules), distributed task execution, and remote caching. Steeper learning curve, larger payoff at scale.
Moon. Younger, multi-language, written in Rust. Worth a look if you mix Node, Python, and Rust in one repo.
Big-system build tools (Google scale):
Bazel (Google), Buck2 (Meta, now open source), Pants (Twitter origin). Aimed at 1,000+ engineer monorepos with strict reproducibility needs. Significant setup cost. Skip unless you are at that scale.
Versioning and publishing:
Lerna passed to Nx's stewardship in 2022 and now focuses on versioning and npm publishing while delegating task running to Nx.
Changesets has overtaken Lerna for OSS libraries. Smaller, simpler, easier to wire into CI.
For polyrepos, the comparable tooling is much lighter: Renovate or Dependabot for dependency updates, GitHub Code Search or Sourcegraph for cross-repo search, and shared internal packages published to a private npm registry, GitHub Packages, or Artifactory.
Real case studies
Google. Mono. One repo for nearly all internal code, served by Piper and built with Bazel. Often cited as proof monorepos scale; remember the engineering investment behind that scale is enormous.
Meta. Mono, on a custom Mercurial fork. Buck2 is the build tool and is now open source.
Microsoft. Rush manages Office, the JavaScript stack, and other large monorepos in TypeScript. They also use Git virtualization (Scalar, formerly GVFS) so engineers do not check out all 100+ GB.
Vercel. Mono, using their own Turborepo. Public on GitHub.
Shopify. Predominantly mono. Their core product is one large Rails monorepo.
Netflix. Mostly polyrepo. Hundreds of microservices each in their own repo, with internal libraries published to a private Artifactory.
Amazon. Famously polyrepo across thousands of internal services. The two-pizza-team model maps cleanly onto repo boundaries.
The pattern: companies that ship one product (or a tightly coupled product family) tend to go mono. Companies built around hundreds of independent services lean poly.
Migration paths
Polyrepo to monorepo. The cleanest path is git-filter-repo (or git subtree add) to import each repo with its history into folders inside the new monorepo. Then add a workspace manager (pnpm workspaces is the lowest friction) and a task runner (Turborepo if JS-heavy, Nx if you want lint rules and generators). Plan one to three months for a 10 to 20 repo merger.
Monorepo to polyrepo. Less common. git-filter-repo can split a folder into a new repo with isolated history. Expect to spend months on duplicate CI configs and shared library extraction.
Most teams that talk about "splitting the monorepo" actually keep one and just enforce stricter ownership boundaries with CODEOWNERS, Nx tags, or path-based branch protection. The split usually solves a perceived problem that better tooling would solve cheaper.
When to switch
Signals you have outgrown your polyrepo:
You ship coordinated release notes that say "deploy A then B then C" more than once a quarter.
Two teams keep duplicating the same component because publishing it as a private package is too painful.
Engineers ask permission to clone repos to see how something works.
Dependency upgrades require chasing 30 PRs across 30 repos.
Signals you have outgrown your monorepo:
CI takes 30+ minutes for a one-line change because cache hit rates fell off.
Two teams want incompatible tooling (different Node versions, conflicting lint rules) and the platform team is the bottleneck.
A regulator or auditor asks you to prove team X cannot read team Y's code.
Git operations (status, fetch, blame) start taking double-digit seconds.
Most teams do not need to switch. They need better tooling on whatever they have.
FAQ
Is Nx better than Turborepo?
Nx is more powerful and more opinionated. Turborepo is faster to adopt and less of a commitment. For teams under 50 engineers on a JS/TS stack, Turborepo wins on simplicity. For polyglot monorepos with tight architectural constraints, Nx wins.
Can a monorepo deploy services independently?
Yes. Path-based or affected-graph CI filters (Turborepo's --filter, Nx's affected) deploy only what changed. The myth that monorepos force lockstep deploys is false, but you do have to wire up the filtering.
Does Git slow down on huge monorepos?
Yes, past a few GB. Solutions exist: partial clones (git clone --filter=blob:none), sparse checkouts, and virtual file systems (Microsoft Scalar, GVFS). Most companies hit this wall after five years and 100+ engineers. Plan for it.
Which do FAANG companies use?
Mostly mono. Google, Meta, Microsoft (largely), Apple (mostly). Amazon is the famous exception, predominantly polyrepo across thousands of internal services.
What about microservices?
Microservices and polyrepo are different decisions. You can have 100 microservices in one monorepo or one monolith split across many repos. The repo layout question is about source code organization. The microservice question is about runtime architecture. Do not conflate them.
Does the monorepo vs polyrepo decision affect my hiring?
A little. Monorepo experience signals exposure to build tooling, dependency management at scale, and architectural lint rules. Polyrepo experience signals comfort with service ownership, distributed teams, and inter-service contracts. Most senior engineers have done both.
Where to go from here
If these tradeoffs are new to you, the system design roadmap covers monorepo and polyrepo in the broader context of architecture decisions, and the DevOps roadmap and cloud engineer roadmap get into the CI/CD pieces that drive most of the friction either way. For build-side workflows, the backend developer and full-stack developer roadmaps cover the dev workflows.
For utilities that play nicely with both setups, the tools catalog has JSON, regex, schema, and CI-adjacent helpers worth bookmarking.
Last updated: April 2026.
Last updated: 2026-08-28