Cursor Monorepo Indexing at Enterprise Scale: Where the Limits Show Up

Cursor works well on small-to-medium repositories. The index loads quickly, semantic search responds fast, and the tool gets out of the way. The experience at enterprise monorepo scale — 500,000 files, 8GB of source, 100 engineers — is different. Cursor's published indexing behavior indicates that semantic search is unavailable until at least 80% of the repository is indexed, and in a large codebase that 80% threshold can take hours to reach per developer per clone. The per-developer local indexing model starts bending under its own weight.

What happens at enterprise monorepo scale

The math is simple: a 500,000-file monorepo with hundreds of packages, generated code, test fixtures, and legacy modules requires substantial compute to chunk, embed, and index. On a developer laptop, that process competes with the actual development work. Cursor's incremental indexing handles ongoing changes well, but the initial index and any full re-index are slow:

Enterprise monorepo scale:
  Files:        500,000+
  Total size:   2–8 GB source
  Teams:        30–120 engineers
  Services:     40–200 packages/apps

  Cursor indexing behavior:
  → Semantic search unavailable until 80% indexed
  → First full index: hours on a large repo
  → Per-developer re-index on first clone: repeated for every developer
  → Incremental updates: fast for changed files, slow for large initial load

The 80% threshold is particularly painful: developers opening Cursor for the first time on a large repo cannot use semantic search until the background indexing process reaches that level. On a team where every new developer clones a 500k-file repo and waits for their local index to build, the onboarding cost is non-trivial. This compounds the onboarding problems already described in the monorepo AI coding context problem.

The .cursorignore configuration problem

The standard advice for Cursor on large codebases is to configure a .cursorignore file — excluding generated files, large binary assets, and directories that are not relevant to active development. This reduces index size and improves performance, but every exclusion is a tradeoff between indexing speed and retrieval completeness:

Monorepo .cursorignore tradeoffs:
  Exclude generated files:
    + Faster indexing
    - AI cannot reference generated types or API clients

  Exclude node_modules:
    + Essential (millions of files)
    - AI may miss package-internal patterns

  Exclude test fixtures:
    + Smaller index
    - AI misses usage examples embedded in fixtures

  Exclude legacy packages:
    + Cleaner suggestions
    - AI cannot help with legacy service maintenance

There is no universally correct set of exclusions. What to exclude depends on your team's workflow, which packages are actively maintained, and what questions developers most frequently ask the AI. For a 30-person team, there are effectively 30 different answers to "what should we exclude?" — and the team commits one .cursorignore file that will be right for some and wrong for others.

What breaks at scale

The practical degradation at monorepo scale is not a single failure — it is a gradual increase in friction across multiple dimensions:

What breaks when cursor indexes a 500k-file monorepo:
  Context window: query retrieves from a noisier embedding space
  Relevance:      harder to surface the right package among 200
  Freshness:      100 commits/day = constant partial re-indexing
  Memory:         local Cursor process competes with dev workload
  Cold start:     new developer clones 8GB repo, waits hours for index

The retrieval quality problem is particularly important. When your embedding space includes 500,000 files, the signal-to-noise ratio in semantic search decreases. A query that would cleanly surface 5 relevant chunks in a 50-file service returns 20 chunks from across 200 packages, many of which look semantically related but are not the right place to look. This is the degradation mechanism described in AI coding quietly hitting a retrieval wall.

Why per-developer local indexing is the wrong architecture for this scale

The fundamental issue is that per-developer local indexing requires every developer to independently build and maintain a complete index of the entire monorepo. In a 100-engineer org, that means 100 separate indexing processes, running on 100 developer laptops, all producing slightly different snapshots of the same codebase. The compute is duplicated 100 times. The freshness is different for every developer. The exclusion configuration is a single committed file that cannot be tuned per-developer.

This scales linearly worse as the team grows. The cost is paid per developer, per clone, per machine — not once per repository.

Server-side indexing for large repos

Server-side indexing runs once per merge event against the canonical codebase, not once per developer per clone. The compute runs on server resources, not developer laptops. The result is shared across the team, so freshness does not degrade per-developer:

Server-side managed indexing advantages for large repos:
  → Index runs once per merge, not once per developer
  → Developer machines not burdened with indexing compute
  → Freshness: reflects canonical branch, not local clone
  → Scale: server resources, not laptop resources
  → Exclusion: tuned once, applies to whole team

Kognita's managed indexing infrastructure follows this model. Repositories connect once, the indexing pipeline runs server-side, and every developer queries the same current index without paying the cost of building it locally. On a large monorepo, this eliminates the per-developer cold start and the ongoing compute overhead of maintaining a local vector index on each developer's machine.

Final take

Cursor's local indexing architecture is practical for small-to-medium repositories and solo developers. At enterprise monorepo scale — hundreds of thousands of files, dozens of active packages, high-velocity teams — the per-developer model reaches its practical limits: slow initial indexes, exclusion tradeoffs that cannot satisfy everyone, and compute overhead that grows with every new hire.

Enterprise monorepo indexing should not be a per-developer responsibility. At scale, it is infrastructure — and infrastructure runs server-side, shared, updated once, paid for once.