Co-located vs dedicated mongot decision thresholds and failure modes
Parent: Platform Consolidation TCO (Atlas Search/Vector Search vs Separate Search or Vector DB) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Co-located vs dedicated mongot decision thresholds and failure modes. 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.
How it works
- Co-location shares a host between mongod and mongot. MongoDB recommends it for development and small workloads; dedicated infrastructure is the production recommendation when search needs isolation, independent scaling, or high availability. (high confidence) [source]
- Small, low-volume indexes that fit available mongot memory can remain co-located. Move toward dedicated nodes when shared-resource contention or unpredictable latency violates application requirements; adding RAM to shared hosts raises capacity without eliminating competition. (medium confidence) [source]
- For vector workloads, co-located mongot restarts can cause demand-driven HNSW cache warm-up and latency spikes. MongoDB University says dedicated Search Nodes preload vector data at startup, separating search warm-up from database restart events. (low confidence) (verified as of 2026-10-31) [source]
- Dedicated mongot does not fully offload database reads: ordinary search execution still retrieves matching documents through mongod. Atlas stored source can avoid that lookup for selected fields when returnStoredSource is used. (medium confidence) [source]
Measurements and reference values
- MongoDB's sizing article offers approximately 10 QPS per vCPU as an initial estimation baseline and explicitly says query complexity and mappings change actual throughput. Treat this as a benchmark starting point, not a migration threshold or SLA. (low confidence) (verified as of 2025-08-12) [source]
- The vector deployment guide recommends node RAM at least 10% above total vector-search index size and enough CPU for concurrency. This is vector-specific guidance, not a universal memory formula for all full-text indexes. (low confidence) (verified as of 2026-10-14) [source]
- Atlas documents co-location guidelines of fewer than 2 million indexed documents, less than 10 GB indexed data, and fewer than 10,000 queries per seven days, recommending dedicated Search Nodes above these values. These are deployment recommendations, not demonstrated capacity limits. (low confidence) (verified as of 2026-10-27) [source]
- Atlas requires at least two dedicated Search Nodes; its documentation also requires 20% local-SSD storage overhead for index operations. Budget redundancy and operational headroom when comparing deployment cost. (low confidence) (verified as of 2026-10-27) [source]
Problems, failure modes and limitations
- Growing page faults, disk IOPS and CPU IOWait are warning signs that the index working set exceeds available RAM. Excessive memory consumption can crash mongot; workload isolation still requires adequate search-node capacity. (high confidence) [source]
- An original community report describes Atlas search-node OOM crashes causing failed searches. It provides no confirmed root cause or controlled workload measurements, so it cannot establish an OOM frequency or sizing threshold. (low confidence) [source]
- A healthy mongod does not guarantee co-located search availability: during scaling, reboots, mongot updates, or configuration restarts, search queries can fail until mongot is running. (low confidence) [source]
- Percona documents 4 GB RAM as a minimum to run mongot, while warning that large collections, high-dimensional vectors, and multiple search indexes need more. A supported minimum is not a production sizing target. (low confidence) (verified as of 2026-10-31) [source]
Comparisons and alternatives
- Choose the migration point from measured search latency, throughput and resource contention rather than document count alone. The reviewed guidance makes workload isolation the decision criterion and provides no universal document-count cutoff. (medium confidence) [source]
- A separate operator reported substantial remaining query latency and cost after adding Search Nodes. This is anecdotal evidence that dedicated nodes do not guarantee a latency target, rather than a reproducible performance comparison. (low confidence) [source]
- Resource isolation does not prevent undersizing: insufficient RAM increases disk access and latency. Size from actual index footprint and available memory rather than collection bytes or nominal node RAM alone. (medium confidence) [source]
Facts and statements
- Co-located mongod and mongot compete for RAM, CPU and disk I/O. A busier database can reduce search cache capacity, force index reads to disk and increase search latency. (high confidence) [source]
- Dedicated nodes isolate search execution but do not remove the database from the default query path: mongot returns matches and mongod retrieves the corresponding documents. Therefore, dedicated nodes alone do not offload every database read or downstream aggregation. (high confidence) [source]
- Atlas deployment guidance specifies at least two dedicated Search Nodes and M10-or-higher database clusters. The two-node minimum adds a capacity and cost floor to the isolation decision. (low confidence) (verified as of 2026-10-27) [source]
- Self-managed MongoDB's dedicated reference architecture calls for at least three mongod machines, two mongot machines, and application-level load balancing from mongod to mongot. These operational responsibilities should be included in the isolation decision. (low confidence) (verified as of 2026-10-14) [source]
- Percona’s October 29, 2026 overview describes full-text and vector search for Percona Server for MongoDB 8.3 and later. Its dedicated mongot service builds search indexes and processes search queries alongside mongod, which stores the documents and returns matching documents to clients. (low confidence) (verified as of 2026-10-31) [source]
- Co-location shares hardware between mongod and mongot; dedicated hosts isolate search resources and permit independent sizing. MongoDB recommends dedicated infrastructure for production or substantial search workloads. (medium confidence) [source]
- Alibaba Cloud documents two Search Nodes by default with a fixed node count, failover to the healthy node, application retries, and brief Search unavailability during restart. Dedicated infrastructure therefore does not imply uninterrupted service across every operation. (low confidence) (verified as of 2026-10-30) [source]
Children
- No children recorded.