Video Transcript (English)

You've confirmed it: the index is bigger than available RAM, and queries are hitting disk. You bring the findings to your manager, and they ask, "Can't we just add more memory to the existing servers?" It's a reasonable question, but dedicated search nodes are a stronger alternative.

In this video, we'll look at the two deployment architectures for MongoDB Search: co-located nodes and dedicated Search Nodes. We'll explain how your choice directly affects how much RAM is available to your vector indexes, and touch on how sharding lets you scale beyond what a single cluster can hold.

Let's start with the two options.

In the default setup, MongoDB runs `mongod` and `mongot` on the same nodes. This is called a co-located, or coupled, architecture. Your application operational data workload and your search workload share the same hardware, which means they also share the same pool of RAM and CPU.

The alternative is dedicated Search Nodes. In this model, `mongot` runs on completely separate, isolated nodes. Your operational cluster handles reads and writes, and your Search Nodes handle all your search needs. The two workloads no longer compete for the same resources.

So what does resource competition actually look like in practice?

On a co-located node, mongod requires a large share of available memory for its storage engine, connections, and runtime operations -- after taking the memory required for the OS filesystem cache, the memory left for the mongot is significantly less than the hardware spec sheet suggests.

CPU is also shared. On co-located nodes, mongot's search operations compete with mongod for processing time, which limits how much processing capacity is available for query execution.

On co-located nodes there's also a cold-start problem. After a database restart, `mongot` must reload the HNSW graph from disk one page at a time as queries arrive.

This causes a latency spike while the cache warms up, because the first queries to arrive are the ones paying the cost of loading data from disk. The cold-start problem can happen whenever mongot restarts or the underlying machine reboots, which are normal outcomes of upgrades, failovers, and maintenance windows.

So back to the question: can't we just add more memory to the existing servers?

Adding RAM to a co-located node does raise the ceiling. WiredTiger will still use the same percentage of memory, and `mongot` will benefit from the additional memory available for the OS filesystem cache to keep its data files in memory. But the contention problem doesn't go away — it just moves to a higher threshold.

The most reliable way to give `mongot` a predictable memory budget for your vector indexes is to move it onto dedicated Search Nodes, where it isn't competing for resources.

So what do you actually get when you move to dedicated Search Nodes?

The most immediate benefit is memory. On a dedicated Search Node, `mongot` isn't competing with WiredTiger for RAM. Atlas Search Nodes allocate approximately 90% of node RAM to index data, with the remainder used by the JVM.

The cold-start problem is also much less of a concern. `mongot` on dedicated Search Nodes has a cache warmer that preloads vector data at startup, so warm-up is confined to Search Node lifecycle events — not triggered by every database restart.

Dedicated Search Nodes also unlock concurrent segment search.

A Lucene index is divided into segments, and by default mongot searches them serially, one after another. Concurrent segment search parallelizes that work, searching multiple segments simultaneously and reducing the time each individual query spends waiting.

For $vectorSearch queries on dedicated Search Nodes, this is on by default with no query changes required. For $search queries, you can opt in per-query using the concurrent option.

Either way, the more CPUs available on your Search Node tier, the more parallelism you get, which is why CPU provisioning matters as much as RAM when sizing your search infrastructure.

You also gain the ability to size and scale your search infrastructure independently. Need more query throughput? Add more Search Nodes. Need lower latency? Upgrade to a higher search tier. You're no longer forced to over-provision your database nodes just to give `mongot` enough breathing room.

With all of that said, co-located nodes are not always the wrong choice. If your index is small and query volume is low, co-location is fine. If your index comfortably fits within the memory available to `mongot` on your dev tier, you won't see the contention problems we've been describing.

The signal to move to dedicated Search Nodes is when those conditions stop being true. If your index has grown to several gigabytes, if you're running under sustained query load, if you have production latency requirements that can't tolerate unpredictable spikes, or if the number of indexes has grown significantly, dedicated Search Nodes are the right choice. The contention, cold-start, and sizing problems we've covered don't get better as your workload scales — they get worse.

Nice work. Let's recap what we covered.

The default co-located architecture runs `mongod` and `mongot` on the same nodes, which means vector search competes with WiredTiger for RAM and CPU.

Dedicated Search Nodes solve the contention problem by giving `mongot` its own isolated resources — a predictable memory budget, cache warm-up at the Search Node level, and the ability to scale search independently from your database.