What is the difference between a monorepo and multiple repositories?
Whether all of an organisation's code lives in one version-controlled repository or in many — and the trade-off is between coordination cost and isolation, with tooling determining whether either scales.
Monorepo. One repository containing many projects, services or libraries.
Its advantages:
Atomic cross-project changes. A change affecting a library and every consumer of it is one commit, reviewed and merged together. In a multi-repo setup the same change is several pull requests that must be coordinated, and there is a window where things are inconsistent.
No internal versioning problem. Everyone uses the current code, so you never have several versions of an internal library in use simultaneously — which removes an entire class of dependency work.
Discoverability. Code can be searched, and finding every caller of a function is straightforward.
Consistent tooling and standards applied once.
Easier large-scale refactoring, which is the argument organisations that adopt it cite most.
Its costs:
Scale. Standard tooling struggles beyond a certain size — checkout time, indexing, and builds. Organisations running very large monorepos build substantial custom infrastructure to make it work, and adopting the pattern without that investment produces a slow, painful repository.
Build systems must understand dependencies to avoid rebuilding everything on every change, which requires tools designed for it.
Access control is coarser.
CI must be selective, or every change runs every test.
Multiple repositories.
Advantages: clear ownership boundaries; independent release cycles; smaller and faster checkouts; fine-grained access control; and simple standard tooling.
Costs: cross-cutting changes are genuinely painful; internal dependency versions drift, so teams run different versions of shared libraries; duplicated configuration and tooling; and finding code requires knowing where it is.
What actually decides it. Not the repository layout but organisational coupling. Teams that must change together benefit from being together; genuinely independent components do not. A monorepo does not create a monolith, and separate repositories do not create loosely coupled services — architecture and repository structure are different decisions that are frequently conflated.
Polyrepo with good tooling and monorepo with good tooling both work; either without it does not.