# Atlas Search Anti-Patterns > Source-anchored research for Atlas Search Anti-Patterns. Run status: COMPLETED. Parent: [MongoDB Atlas Search](https://llms-explorer.com/tree/mongodb-atlas-search/) · 4 facets · 14 facts · page: https://llms-explorer.com/tree/atlas-search-anti-patterns/ ## How it works - When a predicate can run inside Atlas Search, applying it only through $match after $search adds avoidable downstream filtering. Use compound.filter; if a post-search $match is necessary, store its required fields and use returnStoredSource to avoid full-document lookup. (high confidence) — [source](https://www.mongodb.com/docs/search/performance/query-performance.md) - Storing unnecessary source fields increases disk usage and can harm indexing and querying. Store the minimum fields needed for downstream stages; returnStoredSource can avoid expensive full-document retrieval, and a later $lookup can retrieve complete documents when needed. (high confidence) — [source](https://www.mongodb.com/docs/search/performance/index-performance.md) ## Problems, failure modes and limitations - Sorting a large search result downstream with $sort can add avoidable work when a search-native sort supports the field. Use the $search sort option and an appropriate following $limit; native sorting can still be slow when it must sort all documents. (high confidence) — [source](https://www.mongodb.com/docs/search/performance/query-performance.md) - Deep offset pagination with $skip after $search can slow large-result queries. Prefer searchAfter or searchBefore tokens; for non-sequential jumps, MongoDB also documents combining a previously obtained searchAfter token with a smaller $skip and $limit. (low confidence) — [source](https://www.mongodb.com/docs/search/performance/query-performance.md) - Dynamic mapping is not intrinsically an anti-pattern: MongoDB recommends it for unknown or frequently changing fields and experimentation, while documenting its size and performance costs. Choose mappings according to schema stability and the fields queries actually need. (high confidence) — [source](https://learn.mongodb.com/learn/course/search-fundamentals/search-fundamentals/creating-an-atlas-search-index-mappings?page=1) ## Comparisons and alternatives - Treat broad wildcard and regex searches as potentially expensive operations. MongoDB identifies these operators as resource-intensive; Lucene warns that wildcard queries iterate many terms and specifically discourages a leading *. This supports benchmarking patterns such as *substring* rather than assuming an inverted index makes them cheap. (high confidence) — [source](https://www.mongodb.com/docs/search/performance/query-performance.md) - When only counts or facet metadata are needed, use Search count/facet collectors and $searchMeta rather than fetching matches solely to run $count or basic $group aggregations. (low confidence) — [source](https://www.mongodb.com/docs/search/performance/query-performance.md) - Dynamic mappings over documents with arbitrary keys can cause mapping explosions: each key becomes a field, memory consumption grows, and the search process can run out of memory or crash. MongoDB recommends static mappings or more capacity, and a tuple-like schema rather than unbounded key-value field names for wildcard-path searches. (low confidence) — [source](https://www.mongodb.com/docs/search/performance/index-performance.md) ## Facts and statements - Putting eligibility constraints into scoring clauses and generating redundant nested compound clauses wastes scoring work. Put non-scoring equals, range, and in constraints into compound.filter; Mongoose demonstrates this separation with a year range filter. (high confidence) — [source](https://www.mongodb.com/docs/search/performance/query-performance.md) - In a write-up explicitly dated November 16, 2022, Inflearn reported roughly two seconds for a search-and-sort query, rising to four or five seconds with total-count work. These are workload-specific historical observations, not a general latency estimate. (low confidence) — [source](https://note.com/inflab/n/n1d58d3fa036d?hl=en) - Indexing every dynamically supported field can inflate search indexes. Prefer static mappings for known search fields, while retaining dynamic mappings where schemas are unknown, frequently changing, or exploratory. (high confidence) — [source](https://www.mongodb.com/docs/search/performance/index-performance.md) - Assuming deterministic order among equal search scores is unsafe. Add a genuinely unique secondary sort field; equal scores or equal sort values otherwise have arbitrary ordering. (low confidence) — [source](https://www.mongodb.com/docs/search/query/sort.md) - Using Search results as immediate confirmation of a write risks stale observations. Search indexes are eventually consistent, so workflows requiring immediate read-after-write visibility need an appropriate database read path. (medium confidence) — [source](https://www.mongodb.com/docs/search/performance/query-performance.md) - Copying historical score-function or near-based sorting workarounds without checking current options adds unnecessary complexity. Current guidance offers native $search sort; Inflearn's older near example also requires careful origin bounds and pivot selection. (medium confidence) — [source](https://www.mongodb.com/docs/search/query/sort.md)