Atlas Search for substring matching
Parent: MongoDB Query Shape Optimization: Sort, Pagination, Operators and Sharded Targeting · Published reference · snapshot 2026-10-21 · skill ranked-b37a4eca
↓ Facts as markdownall context files
Source-anchored research for Atlas Search for substring matching. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- MongoDB Search autocomplete fields expose edgeGram, rightEdgeGram, and nGram tokenization. MongoDB describes edgeGrams as left-to-right autocomplete and positions nGrams for character autocomplete in languages without whitespace. For arbitrary interior substrings, MongoDB's developer guide shows a custom nGram analyzer with the text operator; Elastic's analyzer documentation explains why nGram emits interior fragments while edge n-grams emit only token beginnings. Do not assume an autocomplete mapping with default settings provides general contains semantics. (high confidence) [source]
- Atlas Search regex uses Lucene's limited regular-expression syntax, not full PCRE; anchors such as ^ and $ are unsupported, and a regex must match the whole indexed term. Use .*fragment.* for a contains-style regex, and escape reserved characters according to the Lucene regex rules. (high confidence) [source]
How-to and procedures
- Use a MongoDB Search autocomplete mapping with tokenization set to nGram and the autocomplete operator for in-word partial matches; use edgeGram when only prefixes should match. The operator requires an autocomplete-mapped field. nGram emits character grams from within tokens, while edgeGram emits grams from the token's left edge. (high confidence) [source]
Problems, failure modes and limitations
- Leading-wildcard patterns such as *needle* are flexible but can be expensive: MongoDB classifies wildcard and regex queries as resource-intensive, Lucene warns that leading * wildcards can be extremely slow, and Elastic recommends n-grams as an alternative while noting their index-size cost. For frequent arbitrary-substring queries, compare the approaches using realistic data and query lengths. (high confidence) [source]
- A Reddit report says a *248* Atlas Search wildcard query took up to 20 seconds on a collection of 800,000 documents; the author also reported that an initial autocomplete+nGram attempt was similarly slow or slower. Replies pointed to using autocomplete on an autocomplete-mapped field with explicit gram bounds. Treat this as a workload-specific anecdote, not a general performance result, and benchmark the actual index and query pairing. (medium confidence) (verified as of 2026-10-21) [source]
- MongoDB Search wildcard and regex are term-level operators, so their query patterns are not analyzed. For a contains pattern across spaces, index the field with the keyword analyzer so the full value remains one term: wildcard uses a pattern such as *Star Trek*, while regex uses .*Star Trek.*. A standard analyzer splits the phrase into separate terms and cannot match that multiword pattern as one term. (high confidence) [source]
Comparisons and alternatives
- Atlas Search autocomplete minGrams and maxGrams control the lengths of generated substrings. Indexing autocomplete fields with nGram, edgeGram, or rightEdgeGram uses more computation and storage than a plain string field, and increasing maxGrams can increase index size. Choose bounds from expected query lengths; MongoDB's worked seven-character plate example produces 27 n-gram terms versus 7 right-edge grams. (high confidence) [source]
- Atlas Search wildcard and regex are term-level operators, so they do not analyze the query string. The regex operator must match the entire indexed term, uses Lucene's limited regex syntax rather than general PCRE, and does not support ^ or $ anchors. Index intact values with lucene.keyword when patterns must include the original string and punctuation; allowAnalyzedField can query tokenized fields, but MongoDB warns that results may be unexpected. (high confidence) [source]
- N-gram indexing shifts work to index time and can increase token volume, index size, and index-build work. MongoDB advises avoiding nGram autocomplete tokenization when the extra tokens are not needed; its substring guide shows a constrained license-plate example with 27 n-gram terms versus 7 right-edge-gram terms, a workload-specific illustration rather than a general ratio. Use nGrams when arbitrary interior-fragment lookup justifies that cost. (high confidence) [source]
Facts and statements
- MongoDB documents autocomplete, wildcard, and regex as partial-string query operators. Its tutorial demonstrates autocomplete for prefixes and wildcard or regex patterns for character matching; autocomplete requires the field to be indexed with the autocomplete type. (high confidence) [source]
- A keyword analyzer preserves capitalization, so wildcard and regex matching against keyword-indexed values is case-sensitive. For case-insensitive wildcard or regex matching, MongoDB recommends a custom analyzer using a keyword tokenizer and lowercase token filter so indexed values and query text use the same normalization. (high confidence) [source]
Children
- No children recorded.