MongoDB Atlas Vector Search

Vector search as an aggregation stage

MongoDB Atlas puts vector search inside the query language you already use. It is $vectorSearch, and it runs as the first stage of an aggregation pipeline.

That placement is the whole idea. The stage returns nearest neighbours, and everything after it is ordinary MongoDB: $lookup to join, $group to aggregate, $project to shape the response. A retrieval step composes with the rest of your data access instead of sitting beside it.

Supabase Vector makes the same argument for Postgres, and the comparison is useful. There the vector lives in a column and you filter with WHERE. Here it lives in a document and you filter with MQL, then keep piping.

Defining the index, and what you can filter on

The vector index is created separately from standard database indexes, and you declare the embedding dimensions in its definition. Up to 8,192 dimensions is supported, which covers current models with room to spare.

Pre-filter fields must be declared too, and the supported types are boolean, date, objectId, numeric, string and UUID, including arrays of those.

Declaring filter fields up front is the step to get right, for the reason Qdrant gives: a filter you did not index is a filter that either does not work or works slowly. List them before the first write, and expect tenant to be on that list.

Pre-filtering, which is the correctness point

Filters are MQL match expressions and they narrow the search before vector comparison.

That is the property worth confirming in any store you evaluate. Context security describes the tenant-leak shape where a filter applied after retrieval passes every test until the query whose true nearest neighbour belongs to another customer. Pre-filtering removes it, and it also stops the quieter problem of asking for ten results and getting four because six were discarded.

Choosing ANN or ENN deliberately

Atlas exposes both, which most stores do not.

ANN uses Hierarchical Navigable Small Worlds and does not scan every embedding. numCandidates controls the candidate pool and limit the results returned. The relationship is the one indexing embeddings describes: raising the candidate pool raises recall and latency together, and it is your runtime recall dial.

ENN is exhaustive and scans everything indexed. Perfect recall, and it costs what a full scan costs.

Having both in one system pays off. Run ENN over a sample of queries to get the true top-k, then measure what your ANN settings return against it. That is the recall measurement that otherwise requires standing up a second index, and without it "recall is fine" means nobody checked.

What else comes with it

Automated embedding through Voyage AI models, so text can go in without you running an embedding service, the same convenience Pinecone offers and with the same trade: you give up choosing the model.

Hybrid search combines vector and full-text, which catches the exact-term queries Weaviate covers. Quantization reduces storage. Native reranking sits on top of results.

Version requirements are worth checking before you plan: ANN needs MongoDB 6.0.11 or 7.0.2 and later, ENN needs 6.0.16, 7.0.10 or 7.3.2 and later. Self-managed and local deployments are supported through the Atlas CLI.

When it is the right answer

Reach for Atlas Vector Search when your application data is already in MongoDB. The argument is the same one that makes pgvector sensible for Postgres teams: one system to operate, one backup story, one consistency model, and no synchronisation job keeping a separate vector store in step with your documents.

That last point is the one people underestimate. A dedicated store means every write has to reach two systems, and the failure mode is a vector index quietly drifting from the records it describes.

Look elsewhere when you are not on MongoDB already, since none of this is a reason to adopt it, and when you want control over index internals that a managed service keeps for itself.

Further reading

• MongoDB, Atlas Vector Search overview: $vectorSearch, index definition, ANN and ENN, and pre-filtering.
• Supabase Vector: the same argument for Postgres.
• Indexing embeddings: what numCandidates trades, and measuring recall.
• Context security: why pre-filtering matters beyond performance.