Monorepo vs Multi-repo: An Honest Take After Operating Both

This debate has been running for a decade without a clean answer — because there isn't one. Here's the real tradeoffs from someone who has operated both approaches at scale, and when each actually makes sense.

The question that never gets a clean answer

Monorepo vs multi-repo is one of those debates that's been running in the industry for a decade and shows no sign of resolution — because there genuinely isn't a universally correct answer. What there are is a set of tradeoffs that favour one approach over the other depending on your team size, deployment patterns, and tooling investment. Here's the honest breakdown from someone who has operated both at scale.

What monorepo actually means

A monorepo is a single repository containing multiple projects or services. It doesn't mean all code is in one giant file or that everything deploys together — those are implementation mistakes, not properties of the pattern. The key property is that cross-service changes happen in a single commit and are reviewed in a single PR.

Google, Meta, and Uber operate at monorepo scale. So do many 20-person startups. The pattern works across a huge range of organisational sizes with very different tooling requirements at each end.

The real advantages of monorepo

Atomic cross-service changes

This is the strongest argument for monorepo and it's underrated. When a shared library changes its interface, all consumers can be updated in a single PR. In a multi-repo setup, updating an interface means: update the library, publish a new version, open PRs in each consuming repo, coordinate merges so nothing breaks in the interim. In a monorepo: one PR, one review, one merge.

# Monorepo: one PR touches the library and all consumers
git diff HEAD~1 --name-only
libs/auth/client.go          # interface change
services/api/auth.go         # updated to new interface
services/worker/auth.go      # updated to new interface
services/gateway/auth.go     # updated to new interface

# Multi-repo: 4 separate PRs, coordination overhead, version drift risk

Unified tooling and standards

One linting config, one CI/CD template, one security scanning setup. Changes to engineering standards apply everywhere simultaneously. In multi-repo, updating a shared CI template means opening PRs in every repo — and some repos will lag for months.

Easier code discovery and reuse

Engineers can search the entire codebase with one tool, find existing implementations before writing new ones, and understand how other teams solved similar problems. In multi-repo organisations, the same utility function gets written 8 times across 8 repos because nobody knew the others existed.

The real advantages of multi-repo

Independent deployment and release cycles

Each service owns its own release process. The payments team can deploy 10 times a day without coordinating with the reporting team. In a monorepo with poor tooling, a broken change in one service can block CI for everyone.

Cleaner access controls

In multi-repo, giving a contractor access to one service without seeing others is straightforward — repo-level permissions. In monorepo, CODEOWNERS and path-based permissions can achieve this but require ongoing maintenance and are easier to misconfigure.

Simpler tooling at small scale

A 5-person team with 3 services doesn't need Nx, Bazel, or Turborepo. Multi-repo with standard GitHub Actions is simpler to set up and reason about. Monorepo tooling has a real learning curve and operational cost that isn't worth it below a certain scale.

Where each approach breaks down

Monorepo at scale without investment in tooling: CI times balloon because every PR runs the full test suite. Build times become the primary bottleneck to developer productivity. This is fixable with affected-only builds (Nx, Turborepo, Bazel) but that tooling investment is non-trivial.

# Nx: only test affected services on each PR
npx nx affected --target=test --base=main
npx nx affected --target=build --base=main

# Turborepo: same concept for JS/TS monorepos
turbo run test --filter=...[HEAD^1]

Multi-repo without a shared platform team: Each repo diverges. Security patches that should apply everywhere take months to propagate. New engineers have to understand 12 different CI setups. Dependency versions drift. This is the slow entropy death of multi-repo without active standardisation.

My honest take

For most teams under 50 engineers with fewer than 20 services: start with multi-repo. The operational simplicity is worth more than the coordination benefits of monorepo at that scale.

For teams over 50 engineers with frequent cross-service changes: monorepo with proper affected-builds tooling is worth the investment. The coordination overhead of multi-repo at that scale costs more than the tooling investment.

The migration question: If you're currently on multi-repo and considering migrating to monorepo — don't do it as a big-bang migration. Pilot it with 2-3 closely-coupled services first. The tooling, CI changes, and cultural shift are significant enough that you want to learn on a subset before committing.

The engineers who are most dogmatic about either approach usually have strong experience with one and limited experience with the other. Both work. The decision should be driven by your team's specific coordination patterns, not industry fashion.