A monorepo (short for "monolithic repository") is a single repository that holds the code for multiple projects, services, or components—often across an entire organization. In contrast, a polyrepo (short for "multiple repositories") strategy separates each project or service into its own independent Git repository.
Both repo strategies are valid and popular, but they come with different tradeoffs depending on team size, infrastructure, and workflows.
Monorepo vs. polyrepo pros and cons
Monorepo benefits
- Centralized versioning: All code shares the same history, making refactoring and dependency updates consistent.
- Atomic changes: Cross-project changes can be made in a single commit and rolled back together.
- Simplified CI/CD pipelines: With the right tooling, you can orchestrate builds and tests more efficiently.
- Shared tooling and libraries: Easier to enforce standards and reuse code.
Monorepo disadvantages
- Scale issues in Git: Large repositories can lead to slower clone, fetch, and diff times without optimization.
- Complex tooling needs: You’ll likely need specialized tools like Nx or Bazel to manage builds, test targeting, and caching.
- Merge conflicts: More developers working in the same repo increases the chance of conflicts.
Polyrepo benefits
- Autonomy and isolation: Teams can operate independently, with full control over their repo, versioning, and release cadence.
- Smaller Git footprint: Each repo is lightweight and easier to manage.
- Granular access control: Security and permissions can be enforced at the repo level.
Polyrepo challenges
- Cross-project coordination is harder: Making changes across services involves more overhead and more pull requests.
- Versioning complexity: Managing multiple package versions can lead to dependency hell.
- Duplicated tooling/config: It’s common to see repeated CI/CD config or linting rules across repos.
When to use a monorepo vs. polyrepo
Use a monorepo if:
- You need tight coordination between projects.
- You have many shared libraries or dependencies.
- You want consistent tooling and development standards.
Use a polyrepo if:
- You have autonomous teams working on loosely coupled services.
- You’re scaling microservices with independent lifecycles.
- Your teams prefer independent deployments and release schedules.
Some large organizations like Google and Meta famously use a monorepo at scale—with custom tooling to support it. Others, like Amazon, prefer a polyrepo approach aligned with independent service ownership.
Graphite for monorepos and polyrepos
Graphite is a code review and management tool that enhances developer workflows in both monorepo and polyrepo environments. Key features include:
Stacked pull requests: Break down large changes into smaller, manageable pieces for incremental review and merging, facilitating continuous integration and reducing complexity.
Merge queue automation: The Graphite Merge Queue automates the merging process to maintain a stable main branch, minimizing merge conflicts and ensuring a "green" build status.
Enhanced Collaboration: Streamlines code review processes, improving coordination and productivity among distributed teams.
These features make Graphite particularly beneficial for teams managing complex codebases, whether centralized in a monorepo or distributed across multiple polyrepos.
Conclusion
The monorepo vs. multiple repos debate isn't about which is universally better—it's about which fits your team's structure, scale, and workflow maturity.Smaller companies might prefer the simplicity of a monorepo to start, while larger ones might lean toward a polyrepo for autonomy. But this isn’t always the case—many large organizations use monorepos effectively, and some small teams choose polyrepos for flexibility. Ultimately, there’s no one-size-fits-all answer. The best approach depends on how your team works, what kind of projects you’re building, and what you want to optimize for.