Comparisons · measured July 2026
A search index lives in one of two places. A server you send code to, or the machine it's already on.
Sourcegraph indexes your repositories on a server and answers code queries across them. Glean does the same for your work (Drive, Slack, tickets, wikis) crawled into one searchable place. Both are genuinely good, and both make the same architectural choice: the index lives on a server, and your content travels to it. That one choice sets three things: privacy, cost, and freshness. Here is the picture, then exactly where a server wins and where a local index does.
TL;DR · key takeaways
The two shapes of search
Cloud index vs local index, drawn to scale.
The only real difference between these two designs is where the index box sits relative to the edge of your machine. Put it on a server and your code has to leave the machine to be indexed, and every query round-trips the network. Put it beside the files and nothing crosses the line. Everything else (privacy, price, how fresh the answers are) follows from that.
The two famous server-side answers
What Sourcegraph and Glean are genuinely great at.
This is not a teardown. Both are the correct tool for the job they were built for: a team. The company's knowledge is shared, so its index should be too: one server everyone queries, kept consistent, permission-aware. The trade-offs that follow are not flaws. They are the cost of that shape.
Point it at your organisation's repositories and it builds a cross-repo index: go-to-definition, find-references, and search that spans every repo your team works in, from one place. It runs as a deployment, cloud or self-hosted, and it indexes the committed, pushed state.
Connectors crawl your company's apps (Drive, Slack, tickets, wikis, repos) into one permission-aware index on Glean's servers. Anyone can ask a plain question and get an answer drawn from everything the company has written down, respecting who is allowed to see what.
One thing both share by design: they see what has been pushed or synced to the server, not the working copy on your disk this second, and never the files that were never in git or in a SaaS app to begin with. That gap is the whole story below.
The sharpest gap: freshness
A server is only as fresh as its last crawl.
You edit files continuously. A server index refreshes in bursts (when you push, or when its crawler next comes around), so between those moments it drifts out of date, and a query can return the version from an hour ago. A local index rides the live disk instead: change a file and it is searchable again in about a millisecond, under 30 milliseconds in the worst case.
Every trade-off, row by row
Same question from both sides.
This is not “who is faster”: a server index and a local index answer for different scopes. It is a map of what each one costs you: where it lives, what it can see, and who gets to query it.
| The trade-off | Server-side · Sourcegraph · Glean | Local · Interlinked |
|---|---|---|
| Where the index lives | a server: their cloud, or one you host | on the machine, on your disk |
| What it can see | the pushed / synced state | the live working copy + the non-git files |
| Freshness | the last push or crawl cycle | ~1 ms after a save · under 30 ms worst case |
| Privacy | content is copied off the machine to index | nothing leaves the machine, works offline |
| Cost shape | per seat, per month, plus servers kept warm | free forever, no seats, no server to run |
| Footprint | a deployment to scale and maintain | ~44 MB at rest · under 1% of the drive |
| Who can query it | the org, through its own surfaces | every agent on the machine: 19 clients |
| Best for | shared, org-wide knowledge | your machine, right now, and your agents |
Where each one wins
It comes down to one question. Whose answer is it?
If the answer has to be the same for everyone, it belongs on a server. If the answer lives on your disk and has to be right this second, the index belongs on your disk too.
the question is “what does the company know?”
the question is “what's on this machine, right now?”
Glean for the org's cloud. Interlinked for the local machine. Same idea (search everything) pointed at the one place a server can't reach: the computer in front of you. Not a competition; different layers of the same stack.
The local index, concretely
Everything a server can't reach, indexed where it already is.
Interlinked keeps an always-fresh index of every file on the machine (names and contents) across every repo and the non-git 90%, and hands it to whatever agent you use through one connector. It never leaves the machine, and there is no model anywhere in the box: every result is an index lookup, not a guess. Here is what that costs and delivers, measured.
A single filename lands in 85 µs; Windows Search takes 67 seconds median on the same machine, about 480,000× slower. And the vault seeds a fact no server-side index can represent: that a folder of separate repos actually ships together. Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files. Full write-ups: the ripgrep comparison and how the vault seeds itself.
GLEAN FOR THE ORG'S CLOUD. INTERLINKED FOR THE LOCAL MACHINE: LIVE, PRIVATE, AND FOR EVERY AGENT.
Common questions
The questions people ask, answered straight.
Index the machine a server can't reach
Keep Sourcegraph. Keep Glean. Add the machine in front of you.
One signed installer indexes every file on your machine (names and contents, every repo plus the non-git 90%) and wires up the 19 AI clients you already use. No cloud account, no keys, no JSON editing, and nothing ever leaves the disk. Your team's server index keeps doing its job; every agent on your machine gets a fast, live, private search alongside it.
Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows · One repo vs the whole machine · Why finding files is the bottleneck