Monorepo vs. Polyrepo: One Repository or Many?
A monorepo is one repository for all projects, like a city; a polyrepo is one per project, like separate towns. Monorepos simplify code sharing and atomic refactors but require complex tooling. Polyrepos offer autonomy but can create dependency hell.
Why it exists
As software systems grow, managing code across multiple projects and teams becomes a major challenge. The core question is how to structure your codebase: do you optimize for cross-team collaboration and consistency, or for team autonomy and decoupling? This choice leads to two main strategies: monorepo or polyrepo.
The mental model
Think of it as a city versus a collection of towns. A monorepo is a single large city. All projects live within its boundaries. It has shared infrastructure (build systems, CI/CD pipelines) and shared laws (linting, code style). Making a change that affects the whole city, like updating a bridge, is one coordinated effort. A polyrepo is a collection of independent towns, each with its own infrastructure and laws. To share anything, one town must build a road and the other must agree to connect to it, often with formal contracts like API versions.
How it works
In a monorepo, all projects—frontend, backend, mobile apps—are directories inside a single version control repository. A single commit can modify code across multiple projects, enabling atomic refactors. This requires specialized, smart build systems that can identify and build only the affected parts of the codebase. In a polyrepo, each project has its own repository. To share code, one project publishes a versioned artifact (like a library or package), and other projects consume it as a dependency, managing versions individually.
When to use it
A monorepo strategy is powerful when you have many tightly coupled projects, require large-scale atomic refactors, and have the engineering resources to invest in the necessary tooling. It simplifies dependency management by ensuring everyone uses the same version of internal libraries. This is why large companies like Google and Meta use them.
When not to use it
A polyrepo is the simpler, often better default. Avoid a monorepo if your projects are largely unrelated, if teams require high autonomy in their tooling and release schedules, or if you cannot afford to maintain the complex build infrastructure. Git itself can also become slow with the massive history and file count of a large monorepo.
One canonical example
Google maintains one of the world's largest monorepos, containing the source code for almost all of its software. This allows an engineer to change a core library and, in the same commit, update every single application that depends on it. This process is managed by their sophisticated, open-source build tool, Bazel, which ensures only the truly affected code is re-tested and re-built.
Interview question
Which scenario would most strongly favor adopting a monorepo strategy over a polyrepo?
- a.A startup with limited engineering resources aiming for the simplest possible initial repository setup.
- b.A development team needing to perform a single, coordinated update across several interdependent services.Correct
- c.A company with many unrelated projects, each managed by independent teams.
- d.An organization prioritizing maximum autonomy for individual project teams regarding tooling.
Why? this is the answer
A monorepo excels when dealing with tightly coupled projects and requiring large-scale atomic refactors, as a single commit can update multiple interdependent services. The other options describe scenarios where a polyrepo's autonomy and simpler default setup would be more advantageous.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
- #monorepo
- #polyrepo
- #version control
- #ci/cd
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles