For years the received wisdom was to split your code into many small repositories — one per service, per library, per team. Then some of the largest engineering organizations on earth made the opposite choice and put nearly everything in a single repository. The monorepo comeback was not nostalgia; it was a response to real pain that "many repos" quietly created.
What a monorepo is
A monorepo is one version-controlled repository holding many projects — multiple services, shared libraries, tools, sometimes an entire company's code. It is not a return to one giant tangled program; the projects stay logically separate. What changes is that they share a single source of truth, a single history, and a single place where changes happen.
The pain it fixes
The trouble with many repositories shows up at the seams. Change a shared library and you must version it, publish it, then update every consumer one by one, coordinating across repos and pull requests. A change that touches three services becomes three reviews that can land out of order and break things in between. Dependency versions drift, so different services run different versions of the same internal library, and "works in repo A" stops meaning "works in repo B." The coordination tax grows with every new repo.
What a monorepo buys
In a monorepo, a change that spans the library and all its consumers is a single, atomic commit — reviewed together, landing together, never leaving the codebase in a broken in-between state. Everyone builds against the same version of shared code, so an entire class of integration drift disappears. Refactoring across project boundaries becomes tractable, code is easy to discover and reuse, and continuous integration can test the real combination of code that will actually run together.
Why now and not before
Monorepos used to collapse under their own weight — version control and build tools choked at scale. The comeback was enabled by tooling. Build systems like Bazel and developer tools like Nx and Turborepo made it possible to build and test only what a change actually affects, rather than the whole repo, so a giant codebase stays fast to work in. The idea was always appealing; the tooling is what made it practical for teams that are not the size of a tech giant.
The trade-offs
Monorepos are not free. They demand investment in build tooling and CI to stay fast, access control gets more nuanced when everything lives together, and the repository itself can grow large enough to need special handling. For a small team with a couple of services, the overhead may not pay off. The monorepo wins specifically when many projects share code and change together — exactly the situation that makes many repos painful.
Why it matters
The monorepo revival is a reminder that architecture decisions are trade-offs, not laws. "Split everything into small repos" sounded like obviously good hygiene, but it pushed complexity into the spaces between repositories, where it is hardest to see and manage. Choosing between mono and many is really a choice about where you want your coordination cost to live — and increasingly, teams are deciding they would rather pay it in tooling than in endless cross-repo coordination.
Analysis by GenZTech.