Atlas Search nodes in sharded clusters
Parent: Independent shard scaling and per-shard tiering · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Atlas Search nodes in sharded clusters. 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.
Problems, failure modes and limitations
- For sharded collections, the documented co-located architecture sends search queries through mongos to shard-local mongot processes as scatter-gather operations; users cannot target an arbitrary particular shard with an Atlas Search query. (low confidence) (verified as of 2026-10-14) [source]
- MongoDB’s search implementation overview says explain does not execute the merge phase of a sharded search query. Inference: explain execution statistics alone cannot establish the complete end-to-end cost of a distributed search request. (low confidence) (verified as of 2026-10-30) [source]
Facts and statements
- Dedicated Search Nodes are supported for both sharded and unsharded dedicated Atlas clusters at M10 or higher; MongoDB recommends them for production workload isolation. The M10 threshold describes dedicated Search Node deployment, not a requirement for all uses of Atlas Search. (medium confidence) (verified as of 2026-10-27) [source]
- Dedicated Search Nodes run mongot separately from mongod, isolating search compute and allowing separate resource sizing. Search still communicates with database processes over the network, so isolation alone does not remove database-side query work. (high confidence) [source]
- The documented scatter-gather rule has a placement qualification: if zones confine a sharded collection to a subset of cluster shards, Search routes that collection’s queries only to the shards where it is located. This is collection-placement scoping, not general shard-key targeting of each search predicate. (low confidence) (verified as of 2026-10-14) [source]
- Ordinary search execution returns matching document IDs and metadata from mongot, then mongod retrieves full documents. Stored source can avoid that full-document lookup for requested stored fields. Cost planning must therefore account for database retrieval work as well as search execution. (high confidence) [source]
- Sharding a collection with an existing Search index, or adding a shard to an already sharded indexed collection, can temporarily yield incomplete Search results until index synchronization finishes on the affected shards. (low confidence) (verified as of 2026-10-30) [source]
Children
- No children recorded.