Monorepo vs polyrepo in 2026: the tradeoffs nobody admits

The monorepo vs polyrepo debate has been running for over a decade and nobody has won. Google, Meta, and Stripe famously run monorepos. Amazon, Netflix, and most microservices-era startups famously run polyrepos. Both succeeded. Both also paid for the choice in ways that did not show up on the conference talks.

The thing the debate has been missing is that neither choice is structurally better. Both have real, predictable, expensive costs. The discipline is to know which costs your team can absorb and which costs your team will resent for the next three years.

This is a write-up of those costs, organized by where they hit, with notes from teams that have run both and switched.

What monorepo gets right#

The strongest argument for monorepo is atomic refactor. When you want to rename a function used across 40 services, you do it in one PR. The change shows up in code review as one diff. The CI runs against everything that depends on the change. Either the build passes everywhere or it fails somewhere and you fix it before merge. The dependency graph is a known thing because it lives in one place.

The second strongest argument is shared tooling. Lint config, build config, format config, security scanning config, type checking config all live in one repo and apply uniformly. New engineers learn one toolchain. The CI ergonomic for the platform team is much simpler because there is one thing to make fast.

The third argument is observability of the dependency graph. You can run an analysis that tells you which services depend on which other services, which services have not been touched in 6 months, which services are coupled to which libraries. The graph is queryable.

Google, Meta, Uber, and Stripe all chose monorepo and stayed with it because these three benefits compound at their scale. Their public engineering posts on monorepo tooling (Bazel, Buck2, sapling, sl, Stripe's Sorbet) describe systems that cost real engineering effort to maintain and are clearly seen as worth it.

What monorepo costs#

The cost is the tooling investment. The cost is permanent and it scales with the size of the repo.

A monorepo without specialized build tooling becomes painful within the first 50 engineers. The CI runs the full test suite for every commit. The lint takes 30 minutes. The clone takes 10 minutes on a fresh laptop. Engineers start looking for ways around the system. The fix is Bazel, Buck2, Pants, Nx, or Turborepo, and any of those choices is a multi-quarter platform project to deploy correctly. The build graph has to be modeled. The dependency cache has to be sized. The remote execution has to be wired. The IDE integration has to be debugged for every language. The CI runner cost climbs because every PR triggers more compute than it used to.

The teams that ran a monorepo for 18 months and switched all report the same root cause: the platform investment was too expensive to sustain. Linear's CTO has written about this on the Linear blog. Smaller teams that adopted Bazel in 2022-2024 and then unwound the decision report the same conclusion. The tooling exists. The cost of running the tooling is what most teams underweight.

The other cost is permission scope. In a monorepo, every engineer has read access to every line of code. For many companies this is fine. For some, it conflicts with regulatory or organizational structures (financial services with strict data handling, defense contractors, companies with strict need-to-know cultures). CODEOWNERS files can enforce write permissions per directory but cannot enforce read permissions, and there is no clean way to bolt that on after the fact.

What polyrepo gets right#

The strongest argument for polyrepo is independent release cadence. Service A can deploy 12 times a day. Service B can deploy once a quarter. The teams own their own CI, their own deploy pipeline, their own dependencies, their own oncall. The release schedule of one team does not gate the release of another team.

The second argument is bounded blast radius for changes. A change to service A cannot accidentally break service B unless they share an API contract, and the API contract is a clearer line of accountability than a shared function call across a monorepo.

The third argument is permission and audit clarity. Each repo has its own CODEOWNERS, its own access list, its own audit trail. SOC 2 audits are easier because each service has a clear boundary.

Companies that ship many independent services, often with different teams and different acquisition origins, choose polyrepo because the coordination cost would be worse in a monorepo. Most large enterprises with B2B SaaS roots run polyrepo for these reasons.

What polyrepo costs#

The cost is coordination overhead, paid forever. Every cross-cutting change requires multiple PRs in multiple repos with manual coordination on merge order. Renaming a shared function requires updating every consumer in lockstep. The shared tooling problem comes back as a per-repo problem: lint config, format config, security scanning config drift across repos as different teams update them at different rates.

The dependency graph becomes opaque. You can answer "who uses this service" only by grepping across all the repos and trusting that the grep was complete. The shared library upgrade is the canonical pain point: a security CVE in a shared library means every repo has to upgrade independently, with no atomic way to verify that everything upgraded correctly until you ship and watch.

The other cost is the boilerplate tax. Every new repo needs its own CI config, its own lint rules, its own README, its own deployment setup. Templates and cookiecutter tools help, but drift starts on day one and accumulates from there.

The 2026 GitHub State of Octoverse data showed that the median engineering team at companies of 200-1,000 engineers maintains 40 to 80 repositories. The maintenance overhead is real and most of it does not appear in any productivity metric until a security incident or a major shared-library upgrade forces an accounting.

Which to pick#

The choice depends on three concrete inputs. None of them is about technical preference.

Do you have a permanent platform team? A monorepo without a platform team becomes unsustainable within 50 engineers. A platform team is 3-6 engineers paid to maintain the build, test, and dependency graph forever. If you cannot afford that headcount, you cannot afford a monorepo.

Do your services share more than 20% of their code or libraries? If yes, monorepo is structurally easier because the shared code is in one place. If no, the polyrepo coordination cost is lower because the services are genuinely independent.

Do you have regulatory constraints on cross-service read access? If yes, polyrepo is the path of least resistance. Working around it in a monorepo is possible but expensive.

If you can afford the platform team, share code heavily, and have no regulatory constraints, monorepo. Otherwise, polyrepo.

The cost of getting it wrong#

The teams I have talked to that switched from one to the other after 2-4 years all report a 12 to 24 month migration. The technical work is mostly mechanical. The morale cost is much higher than the engineering cost. Engineers who chose the original architecture feel rebuffed. Engineers who pushed for the change feel vindicated and the team's discourse goes through 6 months of "we always knew" and "we were right."

The way to avoid the cost is to make the choice with eyes open the first time. Read the postmortems from teams that ran your size before. Stripe, Linear, Vercel, Turso, Cloudflare, and PlanetScale have all written about their architectural choices and the tradeoffs they hit. Their public posts are linked in sources.

What to do this week#

If you are at the scale where the choice is live (anywhere between 50 and 300 engineers), do not decide based on the architecture talk you watched last quarter. Run the three questions through your team's actual current state. Write down the answers. Put the answers in front of the engineering leadership team. Pick the choice the answers support, not the choice that has better aesthetics.

The wrong answer is expensive. The right answer is sustainable for a decade. Both deserve more than a slide deck.