tgrep trades one full scan for a maintained index
tgrep addresses a specific problem: repeated regex searches become expensive when a repository contains 100,000 or more files. A conventional tool such as ripgrep walks and scans the relevant files for every query. tgrep instead extracts trigrams, stores an index, and narrows each search to files that could contain the pattern. That trade is sensible only when the same working tree is searched often enough to repay the initial indexing cost.
The project packages that index behind a local TCP server using newline-delimited JSON-RPC 2.0. A client sends the pattern to tgrep serve, while a file watcher updates an in-memory overlay as the checkout changes. The pitch is therefore not simply "grep, but faster." It is a persistent local search service with a grep-shaped command line, and users should judge the extra process and disk state alongside the speed claims.
Our clean-room run passed every test
We cloned commit 10c7388 into an unprivileged Debian sandbox with 3 CPUs and 12 GB of RAM. Installation succeeded in 19 seconds and installed 83 packages. The repository occupied about 1.9 MB, contained 95 files, and had roughly 45,965 lines of source. Those figures describe our box and checkout, not a general performance promise.
The build then succeeded in 29 seconds. cargo test completed in 71 seconds with 1,618 passed and 0 failed. That is an excellent first-contact result: no undocumented system dependency stopped the build, and no test needed secrets or privileged access. We also found 16 CI workflow files, no Dockerfile, and no separate tests directory, so much of the coverage appears to live within the Rust project structure rather than a top-level integration suite.
Our run did not reproduce the project's search benchmarks, so its reported speedups should remain labeled as project results. The README reports wins in 17 of 18 measured cells, ranging from 3.81x for Chromium on Linux to 51.9x for Gecko on macOS arm64. It also discloses the exception, Kubernetes on Linux at 0.93x, which makes the performance presentation more credible than a single best-case chart.
The architecture is unusually explicit for v1.0.4
The strongest design detail is the hybrid index. An mmap-backed IndexReader handles stable on-disk postings, while LiveIndex holds newly changed or still-indexing files in memory. HybridIndex merges them with the overlay taking precedence. Background work runs in parallel batches of 500 files, and queries can use partial data before the complete build finishes, which reduces the operational pain of starting on a large tree.
Memory management is also treated as a first-class constraint. tgrep flushes after 50,000 files or 5 minutes, swaps the reader, and keeps the overlay bounded. The README distinguishes private memory from file-backed working set and gives a 64 MiB default file-size cap, removable with --no-max-filesize. These details matter because an indexing tool can otherwise move latency out of sight while quietly consuming unreasonable RAM.
File selection shows similar care. More than 50 binary formats are rejected by extension, an 8 KB content check catches additional binaries, and ignore handling accounts for Git's core.ignorecase behavior. For directories without .git, tgrep warns that .gitignore is inactive and offers --no-require-git. That is the sort of rough edge many tools leave users to diagnose through an unexpectedly huge index.
The costs are state, scope, and a young ecosystem
The main weakness is operational, not algorithmic. Users must create an index, run a server, keep a local TCP endpoint available, and trust the watcher to reflect ongoing edits. The 50,000-file or 5-minute flush policy is reasonable, but it is still state that ordinary ripgrep does not have. Teams with ephemeral containers, locked-down desktops, or many short-lived checkouts may spend more effort managing the index than they recover in query time.
Indexed search also cannot eliminate every cost. The project itself says queries returning tens of thousands of matches spend substantial time delivering results, and its own table includes a 0.93x loss. Trigrams are most useful for selective patterns over very large corpora, not as a universal guarantee. The 64 MiB cap can exclude unusually large sources unless consciously disabled, while disabling it changes the resource profile users originally accepted.
Current activity is healthy, but history is short
The repository had 1,815 stars and only 5 open issues in the supplied snapshot. Its latest release, v1.0.4, arrived on September 7, 2026, and the last push was September 8, 2026. Taken together, the fresh push, fresh release, small issue queue, and 16 workflow files point to active maintenance rather than a project coasting on an old tag.
Still, popularity is not the same as a long compatibility record. v1.0.4 is early enough that cautious organizations should pin the version and test index behavior on their own largest repositories. Integration into GitHub Copilot CLI is meaningful real-world validation, but the evidence provided does not tell us how quickly maintainers answer issues or whether the TCP protocol has stability guarantees for third-party clients.
It belongs beside developer checkouts, not at the center of a platform
In a practical stack, tgrep fits on a developer workstation or persistent coding environment where one huge checkout receives dozens of searches per hour. Let Git remain the source of truth, run tgrep serve beside the working tree, and retain ripgrep as the stateless fallback. For shared web search across many repositories, livegrep or Zoekt is a more natural service boundary; for a 16,000-file project, ordinary ripgrep may already feel instant.
The decision is ultimately easy to test with real work. If repeated scans of a 100,000-file tree interrupt thought, tgrep's maintained index and immediate partial serving are worth trying. If searches are sporadic, results are enormous, or background services are unwelcome, the simpler tool wins. Our 29-second build and 1,618 clean tests make experimentation low-risk, while the architecture gives serious users enough detail to understand the trade they are making.