Monorepo vs Polyrepo Code Search Tradeoffs

Whether you go monorepo or polyrepo, you're not picking a winner. You're picking where the pain shows up. Monorepos push complexity into the codebase itself. Polyrepos push it into the coordination layer between repos. Both setups have shipped plenty of great software, so the honest answer is that this is mostly an org design decision wearing a technical costume. Switching later is a slog. That's exactly why it's worth thinking through now instead of inheriting whatever the third hire set up back in 2019.

What monorepos make easy and what they make hard

Monorepos are good at collapsing distance. One pull request can touch an API and every service that calls it, so nobody's juggling five PRs across five repos hoping they land in the right order. Dependency versions live in one place too, which cuts out most of the "wait, which version of this package are we even on" back-and-forth.

Code discovery gets easier here as well. In a big monorepo, an engineer can grep around and actually find the thing that already does what they need, instead of reinventing it three teams over. Onboarding follows the same logic: one linter, one formatter, one test runner, one build pipeline. New hires orient around a single map instead of forty little ones.

The costs are real, though. CI complexity climbs with repo size. Cloning a large Git monorepo can be slow, and build times stretch toward hours if nobody's invested in build tooling to keep it in check. Per Nx's own documentation, the technical side of running a big repo is largely solved by modern tooling now, but the organizational side isn't automatic. Teams still have to agree on branching rules, ownership boundaries, folder structure, deployment approach. Nx's guidance is blunt about this: teams that can't align on that governance are likely better served by separate repos.

Here's a staffing reality nobody puts on the recruiting page: once the repo hits a few hundred developers, someone needs to own the platform full time. Shared tooling doesn't fix itself while everyone's heads-down shipping features.

What polyrepos make easy and what they make hard

Polyrepos hand teams the steering wheel. Each team picks its own workflow, its own conventions, its own release cadence, and nobody has to sign off on it in a company-wide meeting. That autonomy is real, and for some orgs it's non-negotiable: repo-level access control lets a team lock down a repo in ways that per-folder permissions inside a monorepo often can't match. Under strict regulatory rules, that gap matters a lot.

Deploy schedules stay independent too. One service can push to production five times a day while another sits untouched for months, and neither one has to ask the other for permission. If a build breaks somewhere, it stays contained. Nobody else's Tuesday gets ruined.

The costs show up in repetition, plain and simple. Every dependency bump, every CI tweak, every security scanner rollout has to happen once per repo, not once total. There's no single PR that fixes a problem company-wide, because there's no single anything. Sharing code means publishing versioned packages to an internal registry, not just importing a file down the hall. Left alone, version drift becomes the default state, and each team quietly builds its own slightly different CI/CD setup. That's how "let's standardize security scanning" turns into a multi-quarter slog nobody signed up for.

Per Nx, polyrepo is the right call when strict access control is a hard requirement, or when teams share little code and nothing should force them into lockstep. Those are real reasons, not just habit. A useful scorecard signal, per codeintelligently.com's decision guidance: if more than 30% of pull requests cross team boundaries, a monorepo probably cuts friction. Under 10%, and polyrepos are likely enforcing a healthy separation rather than getting in the way.

How repo structure changes where engineers spend time finding code

Ask an engineer at a 140-service polyrepo shop where a piece of logic lives, and the honest answer is usually a shrug followed by "let me ask Dave." Ownership in a polyrepo tends to live in people's heads, not in the folder structure. That's tribal knowledge, and tribal knowledge quits when the person carrying it does.

Per codeintelligently.com's research, engineers in a polyrepo spend an average of 47 minutes finding the right code before making a single change. In the monorepo, that dropped to 11 minutes. That gap alone should settle most of the debate. The best repo strategy is whichever one shrinks the time between "I need to change this" and "I actually understand what I'm changing."

Polyrepo search problems tend to stack on top of each other. Finding which repo owns a given behavior often means knowing who to ask, or maintaining some separate internal registry just to track ownership. Mapping the dependency graph between services requires extra tooling the repo structure doesn't hand you for free. And understanding the full blast radius of a change can mean hopping across several repos where the connections between them stay invisible unless someone built a system to show them.

Monorepos don't dodge the search problem so much as relocate it. The question stops being "which repo is this in?" and becomes "how do I search efficiently inside one enormous repo?" That's a real engineering challenge too, just a different shape of the same one.

Here's the wrinkle worth sitting with. PR cycle time data tracked by Faros AI found a median PR cycle time of 19 hours in monorepos versus 2 hours in polyrepos. Monorepo PRs tend to run bigger, so even though engineers find the code faster, the review cycle slows down. Discovery speed and review speed pull in opposite directions depending on structure, and teams need to be honest about which bottleneck they're actually trying to fix. Optimizing for one can quietly make the other worse.

What enterprise-scale monorepos reveal about the tooling requirement

Google's central repository is the go-to example here, and the numbers are genuinely wild. A January 2015 snapshot, described in a 2016 CACM paper by Rachel Potvin and Josh Levenberg, put it at roughly 2 billion lines of code across about 9 million files, totaling around 86 terabytes, with a commit history near 35 million changes. Something like 95% of Google's engineers worked out of it.

None of that runs on goodwill. It runs on Piper, a custom version control system (originally built on Bigtable, later moved to Spanner), paired with CitC, a cloud workspace that overlays just the files someone's touched onto the full tree, no traditional clone required. Add Blaze (Bazel's ancestor) for rebuilding only what a change actually affects, Critique for review, TAP for testing, and Rosie for splitting up massive refactors, and the picture gets clear fast: this isn't a repo, it's an entire operating system for code. Even Google keeps Android and Chrome out of the main repo, for open source reasons and external partner work. Even the company most associated with monorepos isn't fully monorepo about it, which says something about how settled this debate actually is.

One large tech company runs its own giant unified repo on a homegrown system descended from an earlier open-source version control tool, one that evolved into a system it open-sourced in 2022, paired with a virtual filesystem so no developer machine has to hold the entire repo locally. Only the files someone actually touches get materialized on disk.

Other large-scale names show up too, per monorepovspolyrepo.com. Twitter/X (birthplace of the Pants build tool). Microsoft (Rush Stack, depending on the product). Uber (Go backend). Airbnb (JS migration work). Cash App/Block, which consolidated something like 450 JVM services into one place. Every single one needed custom or heavily adapted tooling to make the scale work, a part most "just go monorepo" advice skips right over.

Adopting Bazel without also building something like CitC, and expecting the results a large tech company got, is how teams hit a wall that company never had to hit, which is the part worth taking a hard line on. The search and navigation benefits of a monorepo aren't baked into the structure. They're unlocked by the infrastructure sitting underneath it, and that infrastructure costs real engineering time to build and keep running. Skip that investment and a monorepo just becomes one giant, slow, tangled repo instead of five small tangled ones.

For smaller shops, the calculus is simpler. Somewhere between 1 and 10 engineers, monorepo tooling overhead usually outweighs the benefit, full stop. In the 5 to 15 engineer range, on a JS or TS-only stack with fewer than five deployable services, something lighter like Turborepo is a reasonable low-friction starting point. Monorepo code-search advantages are real, but they're rented, not owned, and the rent is tooling investment that scales right alongside the repo.

How AI coding agents make repo structure a context problem

AI coding assistants are quietly rewriting one of the oldest arguments for polyrepos: that isolated services are simply easier for a human to hold in their head. Once context windows get big enough, that argument starts to wobble, and honestly, it's already lost most of its force.

GitHub Copilot currently works with a 64,000 token context window. Cursor's model options push even further, large enough to hold the core logic of several services in one shot. Inside a monorepo, that means an agent debugging an authentication bug can look at the auth service, the API gateway, and the client-side code all at once. It reasons across the actual dependency chain, not a guess based on code that merely looks similar.

Polyrepos don't offer that view by default. Per Nx's documentation, an agent working inside one repo of a multi-repo setup can't see who's consuming the code it's about to change, so cross-repo edits need extra coordination the tooling doesn't provide on its own.

The real gain from agents in a monorepo lies elsewhere, not really in faster code generation. It's better awareness of what already exists. An agent that can actually read the codebase can answer "where else do we handle this?" honestly, instead of pattern-matching against whatever looks vaguely similar.

Polyrepo teams aren't stuck, though. Nx has built something called Polygraph, a meta-harness meant to give agents visibility across repositories along with persistent memory across sessions in multi-repo setups. Its existence is itself an admission: the visibility gap between agents and polyrepos is real enough that it needed dedicated tooling to close.

That creates a slow-building pressure. As teams lean harder into AI-assisted development, repo structure starts shaping agent output quality, not just human developer experience. A polyrepo setup that made total sense before anyone cared about AI agents can turn into a liability as agent use grows, simply because an agent is only ever as sharp as the context it's allowed to see.

Code search tools built for multi-repo and cross-repo environments

No matter which structure a team runs, purpose-built search tooling stops being optional past a certain scale. Which tool actually fits depends on what a team is trying to do, and the options split into pretty different lanes.

Zoekt is open-source (Apache-2.0), written in Go, and built around trigram-based substring and regex search. It indexed a shallow clone of kubernetes/kubernetes, 31,300 files, on a laptop in 6.03 seconds, and answered a filtered regex query across that whole index in 193 milliseconds. It also handles large corpora with symbol-aware ranking and both a web UI and JSON/gRPC APIs. It's fast, genuinely fast, but it's a search component, not a full platform. No built-in AI context layer, no cross-repo navigation baked in.

OpenGrok continues to ship releases and is well suited to cross-referencing legacy, on-prem codebases. It's mature software, but it's built for the environments of a decade ago, not modern polyrepo setups or AI-assisted workflows.

Livegrep offers interactive regex search across gigabyte-scale repositories. Running it means standing up both the codesearch backend and the Livegrep web interface separately, which is more setup than some teams want, but it's a solid fit for teams that just need fast regex at scale without a whole platform wrapped around it.

Greptile runs $30 per seat and centers on AI-powered PR review along with codebase chat and query. It's a strong review tool. It's a strong review tool, though, not a full search platform.

One caveat applies no matter which tool a team picks: any system that has to search across every repo to resolve a single symbol reference sees query latency climb as the repo count climbs. The tooling tradeoff ends up mirroring the architectural one it's trying to solve.

One more note on the landscape. A code search engine built in a systems programming language that picked up 9,500 GitHub stars was archived on January 2, 2025, and its team later announced a full shutdown. Any writeup still listing it as a live option is working from an outdated map.

How to decide which structure fits your team's actual situation

The decision comes down to one question: does the complexity you're choosing match the complexity you actually have? Cross-boundary PR frequency is the cleanest signal available. North of 30%, a monorepo probably reduces the daily friction. South of 10%, a polyrepo is likely enforcing separation that's genuinely healthy, not just bureaucratic drag.

Team size and stack matter just as much. A 1 to 10 person team adopting full monorepo tooling is usually solving a problem it doesn't have yet: teams copy Google's playbook years before they have Google's problem. A 5 to 15 person team on a JS/TS stack with a handful of deployable services can get real mileage out of something lightweight like Turborepo without needing the kind of platform investment a large tech company would make.

Regulatory and access requirements can override all of it. If a team needs hard repo-level access boundaries for compliance reasons, that's a structural requirement, not a tooling gap to engineer around, and polyrepo is very likely the answer regardless of what the numbers on cross-project changes say.

AI agent adoption adds a new variable to the math, and it tilts the scale further than most teams currently give it credit for. Teams leaning hard into AI-assisted development get real, measurable benefits from monorepo context visibility, benefits that are much harder to replicate in a polyrepo without extra tooling layered on top, like Nx's Polygraph, built specifically to close that gap.

This is fundamentally an org design decision dressed up as a hard engineering problem. The teams that treat it that way, choosing on purpose instead of drifting into whatever setup the first ten engineers happened to land on, are the ones who skip the expensive, disruptive migration a few years down the line.