MongoDB Atlas Vector Search lets you find documents based on meaning, not just keywords.

Let’s see it in action. Imagine you have a collection of product descriptions, and you want to find "cozy sweaters" even if the exact phrase isn’t there.

// Sample documents in a MongoDB collection
[
  {
    _id: 1,
    name: "Wool Blend Pullover",
    description: "A warm and comfortable sweater perfect for chilly evenings. Made from a soft wool blend.",
    $vector: [0.1, 0.2, 0.3, 0.4, 0.5] // Example vector embedding
  },
  {
    _id: 2,
    name: "Fleece Lined Hoodie",
    description: "Stay snug with this ultra-soft fleece hoodie. Ideal for casual wear and outdoor adventures.",
    $vector: [0.5, 0.4, 0.3, 0.2, 0.1]
  },
  {
    _id: 3,
    name: "Lightweight Cardigan",
    description: "A versatile cardigan for layering. Features a breathable cotton knit.",
    $vector: [0.2, 0.3, 0.4, 0.5, 0.1]
  }
]

To perform a semantic search for "cozy sweaters," you’d use an aggregation pipeline that includes a $vectorSearch stage. First, you need to generate a vector embedding for your search query ("cozy sweaters") using an external embedding model. Let’s say that embedding is [0.15, 0.25, 0.35, 0.45, 0.55].

db.products.aggregate([
  {
    $vectorSearch: {
      queryVector: [0.15, 0.25, 0.35, 0.45, 0.55], // Embedding for "cozy sweaters"
      path: "$vector", // The field containing document embeddings
      index: "vector_index", // The name of your Atlas Vector Search index
      numCandidates: 10, // Number of nearest neighbors to consider
      limit: 5 // Maximum number of results to return
    }
  }
])

This query will return documents whose vector embeddings are closest to the query vector in a high-dimensional space, effectively finding items semantically related to "cozy sweaters." The $vectorSearch stage uses Approximate Nearest Neighbor (ANN) algorithms, typically HNSW (Hierarchical Navigable Small Worlds), to efficiently find these closest vectors without comparing your query to every single document.

The core problem Vector Search solves is moving beyond exact string matching. Traditional keyword searches might miss "warm jumper" if you search for "cozy sweater." Vector Search, by representing words and phrases as numerical vectors (embeddings) that capture semantic meaning, allows for similarity comparisons. Documents with similar meanings will have vectors that are "close" to each other in the vector space.

Internally, MongoDB Atlas Vector Search relies on an indexed vector field. You create a search index on a field containing your pre-generated vector embeddings. Atlas then uses efficient ANN algorithms to query this index. The path parameter in $vectorSearch points to the field holding your document’s embedding. The queryVector is the embedding of your search term. index specifies which vector index to use. numCandidates influences the trade-off between accuracy and performance: a higher number means more potential matches are examined, potentially leading to more accurate results but slower queries. limit simply restricts the number of top results returned.

The real power comes from integrating with embedding models. You’ll typically use a service like OpenAI, Cohere, or a self-hosted model to convert your text data into these vector embeddings before storing them in MongoDB. When a user searches, their query is also embedded, and that embedding is used to query the Atlas Vector Search index.

Many people assume that the numCandidates parameter is just a performance knob. While it is a performance knob, it’s also a crucial accuracy knob. If numCandidates is set too low, you might not even retrieve the actual nearest neighbor, especially if the vector space is dense or your limit is small. For instance, if you set limit: 1 but numCandidates: 1, and the true nearest neighbor is the second-closest vector, you’ll miss it. You need numCandidates to be at least equal to limit for guaranteed retrieval of the top limit results, and often significantly higher to account for the approximate nature of ANN.

The next step is to explore hybrid search, combining vector search with traditional text search for even more robust results.

Want structured learning?

Take the full Mongodb course →