Resource Sizing for Self-Hosted Code Indexing at Enterprise Scale

Resource sizing for self-hosted code indexing isn't guesswork. It follows patterns tied to three things: how many repositories you're indexing, how big your codebase is, and what indexing strategy you pick. Get any of those wrong and it costs real money, real time, or both.

A 50,000-line side project and a 50-million-line production monorepo are not the same problem wearing different clothes. A 50,000-line side project and a 50-million-line production monorepo are different infrastructure problems. In Stack Overflow's 2024 Developer Survey, which pulled in more than 65,000 responses, 61% of developers spend over 30 minutes a day just searching for answers. That's what happens when code search infrastructure is missing or badly sized, not a training gap. That's what happens when code search infrastructure is missing or badly sized.

Enterprise codebases sprawl across hundreds, sometimes thousands, of repositories. Tools built for a single repo on a laptop hit a wall at that scale, and no amount of config tweaking gets you past it. Limitations persist at enterprise scale once a codebase crosses roughly 100,000 files, a threshold where tools built for smaller repos consistently hit architectural ceilings. It's just what happens when an architecture built for one thing gets asked to do another, not a knock on either product. It's just what happens when an architecture built for one thing gets asked to do another.

Missing the sizing call in either direction means someone pays for it. Under-provision, and engineers sit there waiting on a spinner. Over-provision, and the platform turns into a budget line item that finance kills before it ever proves its worth.

The three variables that drive resource requirements

Repository count: every repository added to the index brings its own storage footprint, its own background sync job, and its own slice of query overhead. A setup that hums along fine with ten repos starts groaning under three hundred, revealing an architecture problem rather than a tuning one. The whole deployment model has to change.

Codebase size covers both file count and raw bytes. File count drives how long the index takes to build and how much RAM it needs to sit in memory once built. Raw size drives storage and I/O, and the difference isn't small: a 1.5GB repo behaves nothing like a 4GB one. Even lightweight tools like Gitea start showing real slowdown once you cross that line. Language mix piles on top of that. A codebase juggling five languages needs five sets of parsers and cross-references, and that multiplies CPU cost during the initial build.

Indexing strategy is the one teams most often get wrong, mostly because they don't think of it as a choice.

• Trigram or substring indexing (Zoekt is the reference example) builds fast, runs light on RAM, and answers queries in milliseconds. Trigram indexing locates where the characters appear but does not determine what your code means.

Vector or embedding indexing gives you semantic relevance, understanding intent rather than just string matches. That costs more RAM, often a GPU, and it can drift stale if updates fall behind.

• Code-graph or symbol indexing gives precise call graphs and cross-references. It's demanding on processing power to build and eats storage on large codebases.
• Hybrid setups stack these together, and the resource cost stacks too. Plan for the sum of all three, not just whichever one looks biggest on paper.

Update frequency quietly multiplies all of this. A team merging dozens of times a day needs near-real-time reindexing, which means continuous CPU load in the background, all day, every day. Slowing that cycle down saves CPU, but the search results are stale more often, which just moves the pain somewhere else. Branch-level indexing, where every developer branch gets its own index, can blow up storage and build-queue depth fast enough to catch a platform team off guard.

What trigram search costs at scale, and why it's the efficiency baseline

Zoekt is the trigram search engine sitting behind more than one enterprise platform. It does fast substring and regexp matching, supports boolean queries, and ranks results using code-aware signals, like whether a hit lands on an actual symbol versus a random string.

One data point puts this in perspective: a shallow clone of kubernetes/kubernetes, 31,300 files, indexed in 6.03 seconds on a laptop. A filtered regex query across that whole index came back in 193 milliseconds. That's a laptop, not a benchmark run on a server farm. That's a laptop.

What that tells you about sizing: trigram indexing is a short CPU burst at build time, and after that it's mostly RAM and disk I/O serving queries. No GPU cluster required, no Kubernetes fleet needed, at least not until repository count climbs into the hundreds. A large portfolio eventually outgrows a single node, so distributed deployments become the practical path forward rather than scaling up one big machine.

There's a ceiling here. Trigram search answers "where does this string show up?" in well under a second, across code bases running into the billions of lines. It cannot answer "what does this function do?" Teams that need that kind of semantic or AI-assisted answer end up bolting an embedding index on top, and that's the point where the resource math changes completely.

Where resource requirements spike: embedding indexes, AI context layers, and real-time sync

Cursor's indexing setup is a documented, publicly known failure mode once you push it into enterprise-scale monorepos. Production deployments have reported RAM usage exceeding 64GB, to the point where restarts become routine just to keep things usable.

The root cause is architectural. It's architectural. Periodic sync cycles compound in repositories with frequent commits, and the slowdown builds gradually until it's unmanageable. Throwing more RAM at it buys time. It doesn't fix anything.

A few things drive that spike specifically:

• Embedding model inference needs a GPU, or at minimum a high-core-count CPU. A custom inference stack capable of keeping up with high-commit repositories needs infrastructure most teams simply don't have sitting around by default.
• Per-developer branch indexes multiply storage and build-queue depth. "What's your codebase?" turns into "which branch, whose branch, at what commit?" and the index has to track all of it.
• Real-time update goals, meaning updates within seconds of a file change, mean continuous background load. Not a one-time cost. A permanent tax on the CPU.

Pre-indexing time is its own line item. Platforms doing vector pre-indexing on large repos report 24 to 48 hours before search results are even meaningful. One reviewer clocked a 2GB monorepo at 3 hours to index on a self-hosted setup. The planning takeaway: don't run your first index build during peak CI hours, and size the build nodes separately from the nodes serving live queries.

Elasticsearch offers a useful outside lesson here. Most Elastic clusters end up over-provisioned by 30 to 50%, because teams size for peak indexing throughput instead of steady-state query load. Code indexing teams make the exact same mistake. Splitting build nodes from query-serving nodes and sizing each one for what it actually does, not for the worst hour of the month, avoids this problem.

Minimum viable hardware for a self-hosted deployment, by team and codebase size

Small team, modest codebase (under 50 engineers, repos under 1.5GB each). Lightweight platforms document minimums around 2 CPU cores and 1GB RAM just for basic repo operations at this scale. For trigram-only search, a single modest node handles both indexing and query serving comfortably. That kubernetes benchmark, 31,300 files in 6.03 seconds, is a reasonable upper bound for what one machine can chew through. Adding an AI chat layer means you'll want a local model server. One large GPU instance can comfortably serve 20 or more concurrent chat users with a reasonably sized open model.

Mid-size team, multi-repo (dozens of repos, mixed sizes). Split the build workload from the query-serving workload here, they have genuinely different CPU and memory profiles, and cramming both onto one box just means neither runs well. Platforms shipping self-hosted AI layers publish 16GB RAM as a floor, and that's before adding concurrent users or big repos into the mix. As a cross-reference, GitLab self-managed lists 8 vCPU and 16GB as a starting point for a single node, before CI runners even enter the picture. On storage: budget for raw repo size plus index overhead, and remember trigram indexes stay compact while vector indexes do not.

Enterprise scale (hundreds of repos, 100K+ files, commits flying in constantly). A Kubernetes cluster is the realistic target here. Single-node deployments become a single point of failure, and they can't scale index shards independently, which defeats the point of sharding. GPU allocation for embedding inference stops being optional if the team wants AI query responses under 5 seconds. Budget 24 to 48 hours for the initial large-repo index build, and plan a maintenance window or a shadow-mode build so production queries aren't stuck waiting behind it. Network bandwidth between the indexer and the repo hosts is the bottleneck nobody remembers to check until it's already a problem.

The over-provisioning trap applies at every one of these tiers, not just the biggest one. The 30-to-50% over-provisioning figure observed in Elasticsearch clusters is a useful gut check across the board: size query-serving capacity for P99 concurrency, size build nodes separately, and let the build nodes spin down between rebuild cycles instead of sitting idle and billing you anyway.

How MCP changes the resource equation for AI agents querying the index

MCP, the Model Context Protocol, is now the common language for how AI coding tools talk to code intelligence systems. Claude Code, Cursor, VS Code Copilot, Codex, Windsurf, Zed, Continue.dev, and Cline have all adopted it. That makes it the standard interface agents use to query an index, and it changes the resource math in ways a human user never would.

A human runs a handful of searches per session. An agent doesn't work that way. Each MCP tool call is its own query against the index, and a single agent session can rack up hundreds of them without blinking. Tool definitions and their results also eat into the model's context window, so a poorly scoped MCP server can crowd out the actual code context the model needs to do useful work. Current guidance for 2026 deployments is to scope tool access per sub-agent and per task, loading tools on demand instead of exposing the entire toolset to every session. That cuts latency, and it cuts query load on the index at the same time.

This solves a real failure mode. Claude Code relies on agentic search (grepping, walking directories, reading files), and that approach works best when the agent already has a rough idea where to look. Vague, cross-repository relationships burn through the available context before the agent gets anywhere near useful work. An index that's well-resourced and genuinely current, exposed through MCP, lets the agent ask for what it needs instead of scanning blindly for it. That shifts the cost from context window tokens to index query latency, which is a much cheaper place to pay it. Anthropic has pointed out that more sophisticated engineering orgs are already building MCP servers that expose structured search directly to their agents, letting the agent pull information it couldn't efficiently dig up on its own.

The sizing implication: build the index for agent query volume, not human query volume. Agents don't queue politely behind a rate limit. If a task calls for parallel queries, that's what they'll fire off. And if the deployment sits in a regulated environment, audit logging for every MCP call adds its own storage and I/O overhead, so plan for it up front rather than bolting it on later. The MCP spec now includes Streamable HTTP and OAuth 2.1 for exactly this reason.

Self-hosted platform options and infrastructure demands

Zoekt (standalone) is Apache-2.0 licensed and the trigram engine sitting behind several other platforms. Its resource profile is a short CPU burst at build time followed by light, low-RAM query serving, the same 31,300-file kubernetes index built in 6.03 seconds and answered queries in 193 milliseconds on ordinary hardware. There's no AI layer here and no web UI out of the box, so it suits teams that want the search engine alone and are willing to build or integrate their own interface. Scaling out means sharding across nodes, which takes real operational effort the more turnkey options skip.

One tool, currently at version 1.14.17 as of a late-August 2026 release, is a vendor's compiled-language cross-reference engine under the CDDL 1.0 license, with two decades of history behind it. It needs a servlet container to run and has no AI layer. Its resource footprint is well understood for large on-premises Java and C codebases that need precise cross-references, and the main tuning lever is JVM heap size. It's still shipping actively releases, so calling it abandoned would be wrong, though it's also not moving toward AI-assisted workflows.

Onyx is open-source under MIT, self-hostable via Docker or Kubernetes (air-gapped deployments included), and supports any LLM provider a team wants to plug in. It ships with more than 40 connectors, covering Confluence, Notion, Jira, Linear, Slack, Teams, Drive, SharePoint, and GitHub or GitLab repo knowledge. It also comes with a REST API, an MCP server, an agent SDK, and an embeddable widget. There's a free community tier, with a paid tier running $20 per user.

Beyond these named platforms, a basic self-hosted tier exists at the free end of the spectrum, offering core code search and repository browsing capabilities in a self-contained deployment that keeps the infrastructure footprint small. That kind of setup suits teams that want solid code intelligence without standing up a cluster, and a bring-your-own-model design lets a team pick its own LLM provider and control exactly where its code gets sent, which matters a lot in regulated industries.

Bloop shut down and should not appear on any current comparison list, even though older articles still list it as a live option.