Explainers · the data structure behind instant search · 7 min
What is an inverted index? The map that turns a search into a lookup.
The short version: instead of reading every file to find a word, you build one map ahead of time (from each word to the list of files that contain it) and every search after that is a single lookup. It is how a search engine answers in the time it takes to blink, and how the search box on your own machine can too.
You already rely on one every day. The index at the back of a book is an inverted index: look up a term, get the exact pages, skip the other four hundred. The alternative is grep: read every page, every time you have a question. One scans. One looks up. That gap is the whole difference between seconds and microseconds.
Where the name comes from
It is called inverted because it flips the arrow.
Files are stored the natural way: a file knows the words inside it. That is a forward index: file points to its words. But a search asks the opposite question. You do not have a file and want its words; you have a word and want its files. So you turn every arrow around. Word points to files. That inversion (and nothing more exotic than that) is the entire idea, and the entire name.
Read left to right, the map on the right is now shaped exactly like your question. Ask for dog and the answer (files 2 and 3) is sitting on one row, already assembled. Nothing is searched. You just read the row.
How a lookup replaces a scan
Do the reading once. Answer forever after in one jump.
Building the map costs one full read of everything, but you pay it a single time, in the background, when nobody is waiting. After that the bargain changes completely. A scan's cost is set by the amount of text on the disk: more files, more reading, every query. A lookup's cost is set by the number of matches: the index takes you straight to the word's row and hands back the file list, opening nothing. Here is the whole life of a query in one picture.
Left: three files are read one time to build the word → files map. Right: a search for dog lands on its row and returns the two matching files without opening any of them. Bottom: a scan touches every file on every query; a look-up touches only the matches. That is why one grows with your disk and the other does not.
Same machine · same drive · same questions
Seconds, or microseconds. The difference is the index.
The tools people already use split cleanly into the two strategies. grep and ripgrep scan: they open files and read them on every query, which is exactly the right call for one file or a live pipe. VS Code's find-in-files and Windows Search walk the tree the same way. Point any of them at a whole machine and the reading is the cost. Measured on a real one:
| The tool | How it works | Time | vs the index |
|---|---|---|---|
| Find every file that contains a word | |||
| Interlinked | reads the index | 16 ms | look-up |
| ripgrep | scans every file | 93.8 s | slower |
| Find a file by its name | |||
| Interlinked | reads the index | 85 µs | look-up |
| VS Code Ctrl+P | scans the tree | 35 s | 412,000× slower |
| Windows Search | scans the tree | 67 s | ~480,000× slower |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename look-ups are a 139 µs median across 20 queries (85 µs for a single file, 2 µs best case); the content row is one query (ripgrep 93.8 s versus 16 ms) and across the five-query content set the look-up ran ~7 to 9 ms, 58,625× faster. Full per-tool method in the ripgrep comparison, the VS Code write-up, and the Windows Search breakdown.
The part the textbooks skip
Building it is easy. Keeping it true is the hard part.
An inverted index is only worth anything if it matches reality. The moment you edit a file, the old map is wrong: it points at words that moved and misses words you just wrote. A stale index is worse than none, because it answers confidently and answers wrong. This is where most attempts quietly fall over: they build a beautiful map on Monday and let it rot by Friday, or they rebuild from scratch so often that they are half-scanning anyway.
The real engineering is not the map. It is a live map: one that updates the instant a file changes, so it stays both fast and correct without ever being rebuilt. Get that right and every query is a lookup, forever, on a picture of the disk that is never more than a moment old.
The same idea, pointed at your whole machine
A search engine for one machine. Look up, never scan.
This is the whole principle behind Interlinked. The same move a web search engine makes across billions of pages (and that code-search tools like Sourcegraph and Glean make across a company), Interlinked makes across the disk in front of you: read everything once, keep a live map from words and names to the files that hold them, and answer every query as a lookup. Every repo, plus the ninety percent of the drive that was never in a repo: configs, documents, downloads, the PDF with the answer.
And there is no model in the loop: no embeddings, no guessing, no cloud round-trip. A lookup is a lookup: a word, a row, a list of files. The whole engine sits around 44 MB at rest (less than one browser tab) and the map takes under 1% of the drive, about 24 GB on a 4 TB machine. Everything stays on the machine. Nothing leaves.
Give your machine an index
Stop scanning your disk. Look it up.
Install once. One signed installer wires up 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed and the rest. No JSON to edit.
Let it read the disk once. Filename search works immediately; content fills in behind it. From then on, every search is a lookup instead of a walk, machine-wide, in the microsecond-to-millisecond range.
Keep grep for one file. It stays exactly where it is, still perfect for a single file or a pipe. The index just answers first on the questions that would otherwise cost a full scan.
Let it stay live. Save a file and it's searchable again in about a millisecond. At rest the whole engine sits around 44 MB and the map takes under 1% of the drive.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.