Ignore-aware recursive search is the useful default
ripgrep searches a directory tree for text or regular-expression matches. Its strongest product decision is automatic filtering: .gitignore, .ignore, and .rgignore rules apply by default, while hidden files and binary files are skipped. That behavior matches how developers usually search a repository. A query for a function name is less likely to drown in dependencies, generated output, or Git internals before you add any exclusion flags.
The defaults are policy, not magic. rg -uuu disables all automatic filtering when completeness matters. File-type switches can include Python or exclude JavaScript, and users can define new types. The tool supports context lines, multiple patterns, replacement output, Unicode, several text encodings, multiline matches, compressed-file search, and arbitrary preprocessors. Those options cover much of everyday grep use while retaining a short basic command.
PCRE2 is available, but the default engine is stricter
ripgrep's normal regex engine does not support look-around or backreferences. Those constructs require a binary built with PCRE2 and either -P or an automatic engine selection. This distinction is healthy because the default Rust regex engine avoids pattern behavior that can become difficult to bound, but copied expressions from another tool may fail until the engine is changed. Check rg --version on packaged builds before making PCRE2 part of a team script.
Version 15.2.0 has a current report involving that advanced path. Issue 3508 describes a multiline PCRE2 pattern where an anchor inside a lookaround suppresses an unrelated match. Another open report, issue 3503, concerns column numbers for multiline patterns in a lookahead. These are narrow cases rather than reasons to reject the tool, but they show why a search used for automated rewriting needs fixture tests beyond a few interactive examples.
What happened when we ran it
Our sandbox cloned commit 3fce3b5 and installed 42 Rust packages in 9 seconds. The build succeeded in 19 seconds. cargo test then finished in 11 seconds with 450 passed and 0 failed out of 450. That is unusually clean evidence for a command-line tool: setup was short, compilation worked, and the complete test result reported by our harness was green.
The repository itself was 3.3 MB, with 236 files and about 56,658 lines of source. We found a tests directory and 2 CI workflow files, but no Dockerfile. That layout makes sense because ripgrep is distributed as a native executable, not run as a long-lived service. The README links precompiled archives for Windows, macOS, and Linux, along with package-manager instructions for each platform.
Our run did not benchmark search speed, and we will not substitute the README's hardware-specific tables for measurements on our box. Search time changes with corpus shape, match volume, regex structure, storage, and output. The project documentation openly warns about performance cliffs when patterns offer few literal optimizations or return huge numbers of matches. Test the query and data that drive your decision rather than repeating a headline ratio.
Portability is the main reason to keep grep
The README gives a direct reason to walk away: ripgrep is not POSIX and is not installed everywhere. A shell script shipped across minimal containers, recovery systems, network appliances, and old Unix hosts should usually use grep if its pattern fits. Adding a binary download to a deployment only to save a little typing creates a dependency that an interactive workstation does not mind.
Default filtering can also be wrong for audits and incident response. A secret accidentally placed in an ignored file is still a secret, and a hidden configuration directory may be the exact target. The three u levels progressively re-enable ignored, hidden, and binary content, but users must remember to ask. For compliance searches, encode the intended scope in a wrapper or command record instead of relying on anyone's personal ripgrep configuration.
Index-free search stays simple and has a ceiling
ripgrep walks files rather than maintaining a search database. That removes index setup, stale-state problems, and background services. It is excellent for a working tree, a checkout in CI, or a directory that changes constantly. Search starts with the files as they exist now, and ignore matching happens during traversal. There is no separate update command to remember.
The tradeoff appears in issue 1497, an open RFC for n-gram indexing aimed at search at scale. Its discussion names synchronization and relevance as hard parts. Until an index ships, teams querying enormous, mostly stable corpora repeatedly should compare an indexed code-search system. Issue 3494 also reports occasional segmentation faults with the 15.2.0 x86_64 musl release binary during very large searches, which is a specific reason to stress-test that artifact before standardizing it for such jobs.
Release activity supports a low-risk workstation choice
GitHub recorded 67,618 stars, 182 combined issues and pull requests, and a last push on August 4, 2026. Release 15.2.0 arrived on July 15, adding an aarch64 musl binary, respecting two Git configuration variables, improving large-tree traversal, and fixing ignore matching across multiple directories. The combined open count is not a bug count; recent releases and detailed reproductions provide the more useful maintenance signal.
For most developers, ripgrep earns its place beside Git and an editor. The 9-second dependency install, 19-second build, and 450 passing tests make the source project easy to trust and easy to try. Its sharp edges are documented: filtering changes completeness, PCRE2 changes regex behavior, and portability still belongs to grep. Learn those boundaries once, then rg is usually the fastest route from a question to the relevant line.