Scale Performance with View Support for MongoDB Atlas Search and Vector Search

Amy Jian and Miranda Barrigas
August 7, 2025 | Updated: August 13, 2025

We are thrilled to announce the general availability (GA) of View Support for MongoDB Atlas Search and Atlas Vector Search, available on MongoDB versions 8.0+. This new feature allows you to perform powerful pre-indexing optimizations—including Partial Indexing to filter your collections, and Document Transformation to reshape your data for peak performance.

View Support for MongoDB Atlas Search helps you build more efficient, performant, and cost-effective search experiences by giving you precise control over your search strategy. Let's look at how it works.

How it works in 3 simple steps

At its core, View Support is powered by MongoDB views, queryable objects whose contents are defined by an aggregation pipeline on other collections or views.

Getting started is straightforward:

  1. Create a view: Define a standard view using an aggregation pipeline to filter or transform your source collection. This feature is designed to support views that contain the stages $match with an $expr operator, $addFields, and $set.

    Note: Views with multi-collection stages like $lookup are not supported for search indexing at this time.

  2. Index the view: Build your MongoDB Atlas Search or Atlas Vector Search index directly on the view you just created.

  3. Query the view: This is the best part. You run your $search, $searchMeta, or $vectorSearch queries directly against the view itself to get results from your perfectly curated data.

With this simple workflow, you can now fine-tune exactly what and how your data is indexed. The two key capabilities you can use today are Partial Indexing and Document Transformation.

Figure 1. High-level architectural diagram of search index replication on a view.
This diagram is titled Search Index on a View. On the left of the diagram is a large box labeled disk storage, which contains collection and search index, an arrow goes between the two labeled initial sync plus changestream. Next to the arrow is another box labeled view pipeline.
Search indexes perform initial sync on the collection and apply the view pipeline before saving the search index to disk storage.

Index only what you need with partial indexing

Often, only a subset of your data is truly relevant for search. Imagine an e-commerce catalog where only "in-stock" products should be searchable or a RAG system where only documents containing vector embeddings will be retrieved.

With Partial Indexing, you can use a $match stage in your view to create a highly-focused index that:

  • Reduces index size: Dramatically shrink the footprint of your search indexes, leading to cost savings and faster operations.

  • Improves performance: Smaller indexes mean faster queries and index build times.

Optimize your data model with document transformation

Beyond filtering, you can also reshape documents for optimal search performance. Using $addFields or $set in your view, you can create a search-optimized version of your data without altering your original collection.

This is perfect for:

  • Pre-computing values: Combine a firstName and lastName into a fullName field for easier searching, or pre-calculate the number of items in an array.

  • Supporting all data types: Convert incompatible data types, like Decimal128, into search-compatible types like Double. You can also convert booleans or ObjectIDs to strings to enable faceting.

  • Flattening your schema: Promote important fields from deeply nested documents to the top level, simplifying queries and improving performance over expensive $elemMatch operations.

  • Testing different vector dimensionalities: Splice large MRL Embeddings from Voyage into smaller ones to evaluate the tradeoffs between accuracy and performance.

For example, consider a vacation home rental company with a listings collection storing reviews as an array of objects. To enable end-users to filter for listings with > N reviews, they create a view called listingsSearchView. The view pipeline of listingsSearchView uses an $addFields stage to add the numReviews field, which is computed based on the size of the reviews array.

By creating a search index on listingsSearchView, they can run efficient $search queries on numReviews without compromising data integrity in the source collection.

Figure 2. High-level architectural diagram of running search queries on a view.
This diagram starts on the left with a image representing search queries from client. From here, the path goes to view and then to a box titled disk storage which contains search index. Next, the data goes to mongod, and then through idLookup it goes to collection documents. Then, via the view pipeline the client is able to view documents.
After the search index identifies documents to return, mongod applies the view pipeline to return the view documents.

Why these optimizations are critical for scaling

As your application and data volume grow, search efficiency can become a bottleneck. View Support for MongoDB Atlas Search provides the critical tools you need to maintain blazing-fast performance and control costs at scale by giving you granular control over your indexes.

We are incredibly excited to see how you use these new capabilities to build the next generation of powerful search experiences on MongoDB Atlas.

Ready to get started? Dive into the documentation to learn more: Atlas Search, Atlas Vector Search.

Note: We plan to add compatibility for more types of Views in the future. If there’s a stage that you want to see, please let us know.

← Previous

Lower-Cost Vector Retrieval with Voyage AI’s Model Options

Vector search is often the first step in retrieval augmented generation (RAG) systems. In a previous post, we discussed the future of AI-powered search at MongoDB . At MongoDB, we’re making it easier to select an embedding model so your search solution can scale. At scale, the choice of vector representations and dimensionality can have a significant impact on the cost and performance of a vector search system. In this blog post, we discuss options to reduce the storage and compute costs of your vector search solution. The cost of dimensionality Many MongoDB customers use vector indexes on the order of hundreds of gigabytes. An index’s size is determined by the number of documents and the dimensionality (or count of floating-point numbers) of the vector representation that encodes a document’s semantics. For example, it would require ~500 GB to store 41M documents if the embedding model uses 3072 dimensions to represent a document. At query time, each vector similarity computation will require 3072 floating-point operations. However, if these documents could be represented by a 512-dimensional vector, a similar index would only require 84GB of storage—a six-fold reduction in storage costs, as well as less computation at query time. In sum, the dimensionality of a document’s vector representation will directly affect the storage and retrieval costs of the system. Smaller vectors are cheaper to store, index, and query since they are represented with fewer floating-point numbers, but this may come with a tradeoff in accuracy. Put simply, an embedding model converts an input into a vector of fixed dimensions. The model was trained to ensure that vectors from similar documents are close to one another in the embedding space. The amount of storage and compute required for a vector search query is directly proportional to the dimensionality of the vector. If we can reduce the vector representation without compromising retrieval accuracy, our system can more quickly answer queries while using less storage space. Matroyshka representation learning So, how do we shrink vectors without losing meaning? One answer is Matroyshka Representation Learning (MRL) representations. Instead of reducing the vector size through quantization , MRL structures the embedding vector like a stacking doll, in which smaller representations are packed inside the full vector and appear very similar to the larger representation. This means we can select the level of fidelity we would like to use within our system because the similarity between lower-dimensional vectors approximates the similarity of their full-fidelity representations. With MRL representations, we can find the right balance of storage, compute, and accuracy. Figure 1. Visualization of Matroyshka Representation Learning. To use MRL, we must first select an embedding model that was trained for it. When training with MRL, an additional term is added to the loss function that ensures the similarity between lower-dimensional representations approximates the similarities of the full-fidelity counterparts. Voyage AI’s latest text embedding models— voyage-3-large , voyage-3.5 , and voyage-3.5-lite —are trained with MRL terms and allow the user to specify an output dimension of 256, 512, 1024, and 2048. We can use the output_dimension parameter to specify which representation we want to consider. Let’s see how the similarities among shorter vectors can approximate the similarities among full-fidelity vectors with voyage-3.5 : def cosine_similarity(v1,v2): magnitude_v1 = 0.0 magnitude_v2 = 0.0 dot_product = 0.0 for i,v in enumerate(v1): dot_product += v1[i]*v2[i] magnitude_v1 += v1[i]**2 magnitude_v2 += v2[i]**2 return dot_product/(math.sqrt(magnitude_v1)*math.sqrt(magnitude_v2)) # Calculating cosine similarities for MRL representations cosine_similarity(query[:256],relevant_doc[:256]) cosine_similarity(query[:256],non_relevant_doc[:256]) cosine_similarity(query[:512],relevant_doc[:512]) cosine_similarity(query[:512],non_relevant_doc[:512]) cosine_similarity(query[:1024],relevant_doc[:1024]) cosine_similarity(query[:1024],non_relevant_doc[:1024]) cosine_similarity(query,relevant_doc) cosine_similarity(query,non_relevant_doc]) We’ll use three MRL vectors, a query, a relevant document vector, and a non-relevant document vector. We expect the cosine similarity between the query and the relevant document vector to be larger than the similarity between the query and a non-relevant document vector. Cosine similarity measures the alignment between two vectors, where a high score indicates that the vectors point in the same direction in the embedding space. A score of 1.0 means the query and document vectors are identical, and a score of 0.0 means the vectors are orthogonal. Let’s see if that’s the case: Table 1. Similarity scores under several MRL sub-dimensions. The full-fidelity similarity scores can be approximated well with the 256, 512, and 1024 dimension vectors, so using all 2048 dimensions may not be necessary. For example, the full fidelity scores, 0.702 and 0.340, are close to the cosine similarities of the 512-dimensional representations, 0.704 and 0.346. This suggests that indexes built using the shorter vectors will have similar performance to indexes that use the 2048-dimensional vectors. MongoDB vector search collections. We will generate four vector search indexes, each with a different MRL configuration, and measure the retrieval performance on the dataset’s queries for each index (for existing vectors, we can build MRL indexes with Views ). We will examine the normalized discounted cumulative gain (NDCG) and the mean reciprocal rank (MRR). The results are below: table, th, td { border: 1px solid black; border-collapse: collapse; } th, td { padding: 5px; } Dimensions NDCG@10 MRR@10 Relative Performance Storage for 100M Vectors 256 0.703 0.653 0.963 102GB 512 0.721 0.672 0.987 205GB 1024 0.729 0.681 0.998 410GB 2048 0.730 0.682 1.000 820GB We can then analyze the plot of relative accuracy versus storage costs: Figure 2. Retrieval accuracy versus storage costs. The results indicate that for this corpus, we can represent documents with vectors of 512 dimensions, as the system provides retrieval accuracies comparable to those of higher-dimensional vectors, while achieving a significant reduction in storage and compute costs. This choice dramatically cuts the amount of storage and compute required for vector retrieval, so our system will provide the best retrieval quality for each dollar spent on storage, achieving ~99% relative performance at a quarter of the storage and compute cost. Faster and cheaper search This blog post demonstrates that we can easily assess shorter vector representations to reduce the cost of our vector search systems using MRL parameters exposed in VoyageAI’s models. Using retrieval quality analysis tools, we discover that a vector 25% the length of the full fidelity representation is suitable for our use case, so our system will be less expensive and faster. MRL options enable our customers to select the optimal representation for their data. Evaluating new vector search options can lead to improved overall system performance. We’re continuing to make it easy to tune vector search solutions and will be releasing additional features to tune and measure search system performance. For more information about Voyage AI's models, check out the Voyage AI documentation page . Join our MongoDB Community to learn about upcoming events, hear stories from MongoDB users, and connect with community members from around the world.

August 6, 2025
Next →

Streamlining Editorial Operations with Gen AI and MongoDB

Are you overwhelmed by the sheer volume of information and the constant pressure to produce content that truly resonates? Audiences constantly demand engaging and timely topics. As the daily influx of information grows massively, it’s becoming increasingly tough to identify what’s interesting and relevant. Consequently, teams are spending more time researching trends, verifying sources, and managing tools than actually creating compelling stories. This is where artificial intelligence enters the media landscape to offer newer possibilities. Tapping into AI capabilities calls for a flexible data infrastructure in order to streamline content workflows, provide real-time insights, and help teams stay focused on what matters most. In this blog, we will explore how combining gen AI with modern databases, such as MongoDB, can efficiently improve editorial operations. Why are your content ideas running dry? Creative fatigue significantly impacts content production. Content leads face constant pressure to generate fresh ideas under tight deadlines, leading to creative blocks. In fact, a recent report from Hubspot, 16% of content marketers struggle with finding compelling new content ideas . This pressure often compromises work quality due to time constraints, leaving little room for delivering authentic content. Another main hurdle is identifying credible and trending topics quickly. In order to find reliable pieces of information, a lot of time is spent on researching and discovery rather than actual creation. This leads to missed opportunities in identifying what’s trending and reduces the audience engagement as well. This presents a clear opportunity for AI, leveraged with modern databases, to deliver a transformative solution. Using MongoDB to streamline content operations MongoDB provides a flexible, unified storage solution through its collections for modern editorial workflows. The need for a flexible data infrastructure Developing an AI-driven publishing tool necessitates a system that can ingest, process, and structure a high volume of diverse content from multiple sources.. Traditional databases often struggle with this complexity. Such a system demands the ability to ingest data from many sources, dynamically categorize content by industry, and perform advanced AI-enabled searches to scale applications. Combining flexible document-oriented databases with embedding techniques transforms varied content into structured, easily retrievable insights. Figure 1 below illustrates this integrated workflow, from raw data ingestion to semantic retrieval and AI-driven topic suggestions. Figure 1. High-level architectural diagram of the Content Lab solution, showing the flow from the front-end through microservices, backend services, and MongoDB Atlas to AI-driven topic suggestions. Raw data into actionable insights We store a diverse mix of unstructured and semi-structured content in dedicated MongoDB collections such as news, Reddit posts, suggestions, userProfiles, and drafts, organized by topic, vertical (e.g., business, health), and source metadata for efficient retrieval and categorization. These collections are continuously updated from external APIs like NewsAPI and Reddit, alongside AI services (e.g., AWS Bedrock, Anthropic Claude) integrated via backend endpoints. By leveraging embedding models, we transform raw content into organised, meaningful data, stored in their specific categories (e.g., business, health) in the form of vectors. MongoDB Atlas Vector Search and Aggregation Pipeline enables fast semantic retrieval, allowing users to query abstract ideas or keywords and get back the most relevant, trending topics ranked by a similarity score. Generative AI services then draw upon these results to automate the early stages of content development, suggesting topics and drafting initial articles to substantially reduce creative fatigue. From a blank page to first draft – With gen AI and MongoDB Once a user chooses a topic, they’re taken to a draft page, as depicted in the third step of Figure 2. Users are then guided by a large language model (LLM)-based writing assistant and supported by Tavily’s search agent, which pulls in additional contextual information. MongoDB continues to handle all associated metadata and draft state, ensuring the user’s entire journey stays connected and fast. Figure 2. Customer flow pipeline & behind-the-scenes. We also maintain a dedicated userProfiles collection, linked to both the drafts and chatbot systems. This enables dynamic personalization so, for example, a Gen Z user receives writing suggestions aligned with their tone and preferences. This level of contextual adaptation improves user engagement and supports editorial consistency. User-generated drafts are stored as new entries in a dedicated drafts collection. This facilitates persistent storage, version control, and later reuse which is essential for editorial workflows. MongoDB’s flexible schema lets us evolve the data model as we add new content types or fields without migrating data. Solving the content credibility challenge Robust data management directly addresses the content credibility. When we generate topic suggestions, we capture and store the source URLs within MongoDB, embedding these links directly into the suggestion cards shown in the UI. This allows users to quickly verify each topic’s origin and reliability. Additionally, by integrating Tavily, we retrieve related contextual information along with their URLs, further enriching each suggestion. MongoDB’s efficient handling of complex metadata and relational data ensures that editorial teams can consistently and confidently vet content sources, delivering trustworthy, high-quality drafts. By combining Atlas Vector Search, flexible collections, and real-time queries, MongoDB assists greatly in building an end-to-end content system that’s agile, adaptable and intelligent. The next section shows how this translates into a working editorial experience. From raw ideas to ready stories: Our system in action With our current solution, the editorial teams can rapidly transition from scattered ideas to structured, AI-assisted drafts, all within a smart, connected system. The combination of generative AI, semantic search, and flexible data handling enables the workflow to become faster, more spontaneous and less dependent on manual effort. Consequently, the system focuses back on creativity as it becomes convenient to discover relevant topics from verified sources and produce personalised drafts. Adaptability and scalability become the essential factors in developing intelligent systems that can produce great results within the content scope. As editorial demands grow constantly, it necessitates an infrastructure that can ingest diverse data, produce insights, and assist in real-time collaboration. This system illustrates how AI coupled with a flexible, document-oriented backend can assist teams to reduce fatigue, enhance quality and accelerate the production without increasing difficulty. It’s not just about automation; it’s about providing a more focused, efficient, and reliable path from idea to publication. Here are a few next steps to help you explore the tools and techniques behind AI-powered editorial systems: Dive Deeper with Atlas Vector Search : Explore our comprehensive tutorial to understand how Atlas Vector Search empowers semantic search and enables real-time insights from your data. Discover Real-World Applications: Learn more about how MongoDB is transforming media operations by reading the AI-Powered Media article. Check out the MongoDB for Media and Entertainment page to learn more about how we meet the dynamic needs of modern media workflows.

August 26, 2025