Every developer who has ever waited on grep -r through a monorepo knows the pain: linear scans over millions of files, repeated for every query, with no memory of what came before. Ripgrep famously made scanning faster with clever parallelism and better regex engines, but it's still fundamentally a scan-every-time tool. Microsoft's Tgrep takes a different bet: build a trigram index once, then answer queries in near-constant time.

The idea itself is not new — Russ Cox's classic 2012 essay "Regular Expression Matching with a Trigram Index" laid out how Google Code Search worked, and Zoekt has been carrying that torch for years. What makes Tgrep interesting is that it's coming from Microsoft, likely aimed at the kind of massive internal codebases where Windows, Office, and Azure engineers live. A trigram index breaks every file into overlapping three-character substrings and stores a posting list of which files contain which trigrams. A regex query gets decomposed into a boolean expression over trigrams (e.g., foo.*bar requires files containing both foo and bar), which prunes the candidate set to something small enough to scan with a real regex engine.

Why a technical audience should care:

• Scale matters. If you've ever tried to grep a repository with tens of millions of lines, you know that even ripgrep starts to feel sluggish. Indexed search shifts the cost to a one-time build plus incremental updates.
• The tradeoffs are educational. Trigram indexes are fast for common queries but degrade for short patterns (a.*b is nearly useless as a filter) and require careful engineering around Unicode, case folding, and file updates. Reading Microsoft's implementation choices is a masterclass in real-world text-indexing design.
• Agent-era relevance. Coding agents like Claude Code and Cursor lean heavily on repeated codebase search. A local trigram index could dramatically cut the latency and cost of grounding LLM queries in code — much cheaper than embedding-based semantic search for exact-string lookups.
• Open source from Microsoft. When a large company open-sources internal tooling for their own codebase scale, the engineering quality is usually a step above weekend projects.

The fact that this has one upvote and zero comments is a small tragedy. Developer-tooling infrastructure rarely goes viral on HN unless it comes with a slick landing page, but this is exactly the kind of foundational utility that quietly ends up in a lot of pipelines.