How Cursor bypassed Git's scalability limits

Cursor, the AI-powered code editor, had to solve a real Git scalability issue to function properly on very large codebases. Here’s what they did—and why it matters to every senior dev.

The Real-World Case

Imagine a codebase of several million lines—the kind found in large tech companies, mature open-source projects, or fast-growing startup monorepos. Git starts to struggle: git status takes seconds, common operations become frustrating. Now add an AI tool (like Cursor) that needs to understand the repo’s state in real time to contextualize its suggestions. The problem becomes critical.

This is exactly what Cursor encountered—and The Register details how they worked around Git’s scalability limits.

The Root Problem: Git Wasn’t Built for AI

Git was designed by Linus Torvalds in 2005 to manage the Linux kernel—a large but human-driven codebase: developers committing, branching, merging. Git wasn’t built for an AI tool that reads the repo’s state dozens or hundreds of times per minute to power real-time suggestions.

The bottlenecks are well-known:

• Git Index: The .git/index file is fully re-read on every status operation, even for a single modified file.
• Object Store: Fetching objects by hash isn’t optimized for massive, repeated reads.
• Filesystem Hooks: On Windows and macOS, filesystem watchers add latency.

What Cursor Did: S3 as the Source of Truth, NVMe Local for Latency

Cursor’s approach, revealed by The Register, relies on a two-tier architecture: S3 (cloud object storage) as the source of truth for the repository, and local NVMe (high-performance SSD) repos for latency-sensitive operations.

Concretely, instead of having AI work directly on the local Git repo with its scalability limitations, Cursor maintains a canonical copy in S3 and uses local NVMe caches for operations that demand fast responses. Synchronization between the two tiers is optimized to minimize full reads of the Git index.

This is the kind of problem senior devs know well: standard abstractions hold up to a point, then you have to go lower—here, completely rethinking the storage model rather than marginally optimizing git calls.

Why This Matters to Everyone

Cursor’s solution has implications beyond their tool:

• Monorepos: Any team working on a large monorepo faces these issues. The S3 + local NVMe architecture is transferable.
• Git LFS: Solves the problem of large binary files, not index scalability. It’s an open problem Cursor bypassed another way.
• AI Tools on Codebases: All static analysis tools, AI-assisted code reviews, or code generation tools will hit this problem as they scale.