What Is a Monorepo? Benefits, Drawbacks, and Examples

The monorepo vs polyrepo debate shapes how teams from startups to tech giants handle code every day. We cut through the hype to show why Google and Facebook bet on monorepos and whether that approach fits your team.

Google’s monorepo spans over 2 billion lines of code; Facebook uses a monorepo for its main apps; tools like Nx, Bazel, Lerna manage monorepos.

What is a Monorepo? The Core Definition

A monorepo (short for “monolithic repository”) is a single version-controlled repository that contains multiple distinct projects, applications, or libraries. Instead of splitting code into separate repos for each service or app, a monorepo keeps everything together—often including related tooling, shared libraries, and configuration files. The opposite approach, a polyrepo, uses separate repositories for each project, which many teams find easier to manage when projects have different release cycles or teams.

For example, Google operates one of the largest monorepos in existence, with over 2 billion lines of code and more than 1 billion files housed in a single repository. This scale allows thousands of engineers to work on shared code simultaneously, though it requires specialized tooling to manage effectively.

The pattern: Centralizing code in a monorepo forces teams to invest in tooling and governance, but the payoff is seamless cross-project collaboration.

What is a monorepo used for?

Monorepos are primarily used to share code across related projects, enable atomic commits that update multiple projects at once, and unify versioning and CI/CD pipelines. Large tech companies like Google and Facebook adopt them to manage massive codebases with thousands of engineers.

“A monorepo is a single repository containing multiple distinct projects, with well-defined relationships.” — Sourcegraph

Monorepo vs. Polyrepo: Key Differences at a Glance

Choosing between these two approaches isn’t just about personal preference—it shapes your team’s workflow, tooling, and scalability. Here’s how the main differences stack up in practice.

The trade-offs are real: while monorepos streamline cross-project collaboration, they demand more infrastructure overhead. Teams that prize simplicity and autonomy often find polyrepos more manageable, even if it means more coordination when changes span multiple projects.

“Monorepos require advanced build and CI tooling to stay performant at scale.” — Graphite

What is the difference between a monorepo and a repository?

A repository is any version-controlled storage location, while a monorepo is a specific type that holds multiple projects in one repo. The key difference is that a standard repository typically hosts a single project, whereas a monorepo intentionally groups related projects together to encourage sharing and atomic changes.

Why Tech Giants Choose Monorepos: The Scaling Strategy

Google, Facebook, and Microsoft didn’t adopt monorepos by accident—they did it because it solved concrete scaling problems. Let’s look at how these companies leverage a single repository to manage massive codebases.

• Google’s monorepo: Over 2 billion lines of code and 1 billion files, used by 25,000+ engineers daily.
• Facebook’s monorepo: Primary codebase for mobile (Android, iOS) and web apps, enabling synchronized releases across platforms.
• Microsoft’s approach: Windows and Office development use a large monorepo-like structure for shared components.

Google: Google’s monorepo is the most famous example. With more than 2 billion lines of code, its engineers rely on custom tooling like Bazel to handle builds and test at scale. The monorepo allows atomic commits across all services—a single change can update a shared library and its consumers simultaneously. This eliminates the coordination nightmare of syncing changes across dozens of separate repos.

Facebook: Facebook also maintains a monorepo for its major applications. By keeping its iOS, Android, and web codebases in one repository, the company ensures that code sharing and version control are unified. When a developer makes a change, it can instantly affect all platforms without waiting for separate releases.

Microsoft: While Microsoft uses a mix of repo strategies, its Windows and Office teams have adopted large-scale monorepos for shared components. This approach facilitates reuse of core libraries across product lines and reduces the friction of cross-team collaboration.

What makes this strategy work at massive scale is the ability to make atomic changes across the entire codebase. In a polyrepo, if you need to update a shared library and its consumers, you’d have to coordinate separate commits, tags, and releases—a slow and error-prone process. Monorepos bypass this by giving every developer a unified view.

The catch is that this scale doesn’t come free. As the repository grows, version control operations like cloning, fetching, and diffing can become slower if the tooling isn’t optimized.

The implication: If your team prioritizes cross-project coordination over per-team autonomy, a monorepo’s centralized model can reduce release friction.

Which companies are known to use monorepos?

Google, Facebook, and Microsoft are the most prominent examples. Google operates one of the largest monorepos with over 2 billion lines of code, Facebook uses a monorepo for its main apps, and Microsoft applies a monorepo-like structure for Windows and Office. Other companies like Uber and Airbnb also maintain large-scale monorepos.

When a Polyrepo Makes More Sense

Despite the hype, monorepos aren’t always the best fit. For many teams—especially smaller ones or those with loosely coupled projects—a polyrepo approach offers simplicity and autonomy. Here’s why some teams stay with separate repositories.

Advantages of polyrepos:

• Easy per-project access control—you can grant permissions repository by repository.
• Simpler versioning and release cycles—each project can version independently.
• No need for specialized tooling; standard Git workflows work fine.
• Ownership is clearer—teams have full control over their repository.

Disadvantages of polyrepos:

• Code sharing requires publishing packages and pinning versions, which slows cross-project collaboration.
• Atomic changes across projects are difficult—you need multiple commits and careful coordination.
• Discoverability suffers—finding the right code or tool across many repos is harder.
• Moving code between projects means dealing with history and dependency resolution.

A common polyrepo downside is that code sharing requires publishing and version pinning instead of direct imports. If your team frequently shares code across projects, this overhead can become a significant bottleneck.

When to choose polyrepo: If your projects are largely independent, have different release schedules, or are owned by different teams with minimal overlap, a polyrepo gives you the flexibility to move fast without the overhead of monorepo tooling. For example, open-source libraries are almost always polyrepos because contributors work on them independently.

When to choose monorepo: If you need to share code frequently, make coordinated changes across projects, or want a single source of truth for your entire codebase, a monorepo can be the right call—even if it means adopting new tools like Nx or Bazel.

The pattern: Teams that value autonomy and simplicity often prefer polyrepos, but those requiring frequent cross-project coordination will find monorepos more efficient despite the tooling overhead.

What are the disadvantages of using a monorepo?

Monorepos can suffer from slower clone, fetch, and diff operations if not optimized. They also require specialized tooling like Nx or Bazel, and access control becomes harder when many teams share one repository. For small teams or tightly scoped projects, the overhead may outweigh the benefits.

Confirmed Facts: What the Research Actually Shows

To put the monorepo vs. polyrepo debate into perspective, here are the key facts you should know, straight from sources like Sourcegraph and Graphite. These aren’t opinions—they’re observable patterns from companies that have scaled their codebases.

The implication: Despite the scale of Google and Facebook, the lack of comparative data means teams should evaluate their own needs rather than blindly following big tech’s lead.

Frequently Asked Questions

Your team’s choice between monorepo and polyrepo will shape your workflow and tooling—prioritize code sharing if you opt for a monorepo, or autonomy if you choose a polyrepo.

Related Reading

• 16 Billion Passwords Leaked
• Play Chess Against Computer: Free Games & Practice Tips
• Sourcegraph’s guide to monorepo vs. polyrepo
• Graphite’s breakdown of pros, cons, and tools