The monorepo vs. polyrepo debate is misguided.
It’s one of the most famous developer debates and has been around for over a decade. It’s as controversial as tabs vs. spaces or Vim vs. Emacs.
Notably, it’s not a debate about infrastructure. For example, monorepos can still be used to deploy a microservices architecture. It’s more about organization—how code is stored, maintained, and shared across projects.
Monorepo supporters argue it reduces redundancies, simplifies onboarding, and aligns releases. Polyrepo advocates say it improves organization, speeds up deployments, and minimizes conflicts. Both have strengths, but the real question is: Which scales better? The answer is neither.
Without proper tooling, monorepos become slow and conflict-ridden, while polyrepos grow disconnected and redundant. The solution lies in tooling, not the repo structure itself.
Let’s dive deeper into why.
Let’s start with a quick disclosure. We use polyrepos at Lago.
A single repo just wasn’t the right fit for us. We’re at a stage where a monorepo would likely introduce more conflicts than benefits. With our growing codebase, putting everything in one place could slow down development and increase the likelihood of merge conflicts.
There’s also a practical reason for using polyrepos: We’re an open-source product, and keeping repositories separate allows our users to download only what they need. Most users just want the client, not the entire backend. If we had everything in one repository—like other open-source projects such as PostHog and Airbyte—it would result in massive repos that are cumbersome to clone, slowing down developer contributions. We wanted to avoid that.
That said, we believe in consolidation where it makes sense. For instance, while we currently maintain separate repositories for our SDKs, we’re actually planning to consolidate them into one. Our SDKs are handwritten—after we moved away from OpenAPI-generated code due to cleanliness concerns—so grouping them into a single repo is part of our long-term vision.
We’re aware that polyrepos come with a host of challenges, especially as you scale.
One of the biggest hurdles is onboarding new engineers. Instead of learning one centralized codebase, new engineers have to familiarize themselves with multiple repos, which can slow down the ramp-up process. Debugging becomes more frustrating too; tracking down issues that span across different repos can be time-consuming and tedious.
Setting up test environments is another pain point. With polyrepos, configuring reliable and consistent CI/CD pipelines becomes trickier. Continuous integration and deployment often require extra effort to ensure that all the moving parts across repos are working in harmony. This complexity not only increases setup time but also raises the likelihood of breaking things.
Code duplication becomes more of a risk in polyrepos. Without a centralized repo, it’s easier for teams to unintentionally repeat code, leading to maintainability issues down the road.
While polyrepos offer flexibility, they also introduce complications—particularly when it comes to testing, debugging, and keeping the codebase streamlined.
Monorepos come with their own scaling challenges.
Cloning a large monorepo can take forever, especially as a project grows. Developers often find themselves waiting a long time just to instantiate the repo on their machine. Once you have the repo, build times can also be incredibly slow, making the development cycle sluggish and frustrating.