MongoDB Blog
Announcements, updates, news, and more
Away From the Keyboard: Kyle Lai, Software Engineer 2
In “Away From the Keyboard,” MongoDB developers discuss what they do, how they keep a healthy work-life balance, and their advice for people seeking a more holistic approach to coding. In this article, Kyle Lai describes his role as a Software Engineer 2 at MongoDB; why he’d rather not be like the characters on the TV show, Severance; and how his commute helps set boundaries between his professional and personal lives. Q: What do you do at MongoDB? Kyle: Hi! I’m an engineer on Atlas Growth 1, where we run experiments on Atlas and coordinate closely with marketing, product, design, and analytics to improve the user experience. Atlas Growth 1 is part of the broader Atlas Growth engineering teams, where we own the experimentation platform and experiment software development kit, allowing other teams to run experiments as well! The engineers on Atlas Growth are very involved with the product side of our experiments. We help the analytics team collect metrics and decide if a given experiment was a win. Sometimes, seemingly obvious positive improvements can turn out to be detrimental to the user flow, so our experimentation process allows us to learn greatly about our users, whether the experiment wins or not. Q: What does work-life balance look like for you? Kyle: Work-life balance for me means that I won’t be worrying about responding to messages or needing to open my laptop after work hours. It also means that my teammates equally respect my work-life balance and do not expect me to work during non-work hours. Q: How do you ensure you set boundaries between work and personal life? Kyle: Generally, for me, it’s more difficult to set boundaries between work and personal life when I’m working from home, so I try to come into the office most days. My commute also provides me with time to wind down and signal that work is over for the day. In a way, the drive to and from the train station allows me to transition to getting into the mindset for work or to decompress at the end of the day. Q: Has work-life balance always been a priority for you, or did you develop it later in your career? Kyle: As someone who is early in my career, work-life balance is something that I’ve grown to appreciate and see as a priority in my life. It allows me to enjoy my personal life, and definitely contributes to a healthier me and a healthier team. Q: What benefits has this balance given you in your career? Kyle: Our team has a weekly Friday hangout meeting, where we have a different question posed to us each week. One of the questions was based on the TV show, Severance. Would we choose to be “severed” like the characters in the show? They undergo a procedure that separates their work and personal brains—their work brains have no awareness of their personal lives, and vice versa. As someone who hasn’t seen the show, but has heard about it from the rest of my team, I wouldn’t do it. Balancing my work and personal lives allows me to enjoy each side more. I’m motivated for the end of the week so I can enjoy the weekend, and I’m also excited to come to work with a fresh headspace on Mondays, since I am not overworking during non-work hours. Q: What advice would you give to someone seeking to find a better balance? Kyle: I’ll sometimes have the urge to continue working past work hours, as I’ll feel like I’m about to finish whatever task I’m working on very soon or think I can get even more done if I don’t stop working. That backfires pretty quickly. You have to realize you can be easily fatigued and are not able to give your best work if you constantly keep working. A proper work-life balance will allow you to have a fresh start and a clear mind each day. As for how to better separate work and personal life, I’d suggest changing notification settings on your phone for Slack, so that non-urgent work messages won’t tempt you to open your laptop. Another strategy would be to associate some event with a cutoff for checking work things, such as not reading messages once you’ve left the office or boarded the train. I’ve had teammates tell me they delete Slack from their phones when they’re on vacation, which is a good idea! Thank you to Kyle Lai for sharing these insights! And thanks to all of you for reading. For past articles in this series, check out our interviews with: Staff Engineer, Ariel Hou Senior AI Developer Advocate, Apoorva Joshi Developer Advocate, Anaiya Raisinghani Senior Partner Marketing Manager, Rafa Liou Staff Software Engineer, Everton Agner Interested in learning more about or connecting more with MongoDB? Join our MongoDB Community to meet other community members, hear about inspiring topics, and receive the latest MongoDB news and events. And let us know if you have any questions for our future guests when it comes to building a better work-life balance as developers. Tag us on social media: @/mongodb #LoveYourDevelopers #AwayFromTheKeyboard
Unlocking BI Potential with DataGenie & MongoDB
Business intelligence (BI) plays a pivotal role in strategic decision-making. Enterprises collect massive amounts of data yet struggle to convert it into actionable insights. Conventional BI is reactive, constrained by predefined dashboards, and human-dependent, thus making it error-prone and non-scalable. Businesses today are data-rich but insight-poor. Enter DataGenie, powered by MongoDB—BI reimagined for the modern enterprise. DataGenie autonomously tracks millions of metrics across the entire business datascape. It learns complex trends like seasonality, discovers correlations & causations, detects issues & opportunities, connects the dots across related items, and delivers 5 to 10 prioritized actionable insights as stories in natural language to non-data-savvy business users. This enables business leaders to make bold, data-backed decisions without the need for manual data analysis. With advanced natural language capabilities through Talk to Data, users can query their data conversationally, making analytics truly accessible. The challenges: Why DataGenie needed a change DataGenie processes large volumes of enterprise data on a daily basis for customers, tracking billions of time series metrics and performing anomaly detection autonomously to generate deep, connected insights for business users. The below diagram represents the functional layers of DataGenie. Figure 1. DataGenie’s functional layers. Central to the capability of DataGenie is the metrics store, which stores, rolls up, and serves billions of metrics. At DataGenie, we were using an RDBMS (PostgreSQL) as the metrics store. As we scaled to larger enterprise customers, DataGenie processed significantly higher volumes of data. The complex feature sets we were building also required enormous flexibility and low latency in how we store & retrieve our metrics. DataGenie had multiple components that served different purposes, and all of these had to be scaled independently to meet our sub-second latency requirements. With PostgreSQL as the metrics store for quite some time and tried to squeeze it to the maximum extent possible at the cost of flexibility. Since we over-optimized the structure for performance, we lost the flexibility we required to build our next-gen features, which were extremely demanding We defaulted to PostgreSQL for storing the insights (i.e. stories), again optimized for storage and speed, hurting us on the flexibility part For the vector store, we had been using ChromaDB for storing all our vector embeddings. As the data volumes grew, the most challenging part was maintaining the data sync We had to use a different data store for knowledge store and yet another technology for caching The major problems we had were as follows: Rigid schema that hindered flexibility for evolving data needs. High latency & processing cost due to extensive preprocessing to achieve the desired structure Slow development cycles that hampered rapid innovation How MongoDB gave DataGenie a superpower After extensive experimentation with time-series databases, document databases, and vector stores, we realized that MongoDB would be the perfect fit for us since it exactly solved all our requirements with a single database. Figure 2. MongoDB data store architecture. Metrics store When we migrated to MongoDB, we achieved a remarkable reduction in query latency. Previously, complex queries on 120 million documents took around 3 seconds to execute. With MongoDB's efficient architecture, we brought this down to an impressive 350-500 milliseconds for 500M+ docs , representing an 85-90% improvement in query speed for a much larger scale. Additionally, for storing metrics, we transitioned to a key-value pair schema in MongoDB. This change allowed us to reduce our data volume significantly— from 300 million documents to just 10 million documents —thanks to MongoDB's flexible schema and optimized storage. This optimization not only reduced our storage footprint for metrics but also enhanced query efficiency. Insights store By leveraging MongoDB for the insight service, we eliminated the need for extensive post-processing, which previously consumed substantial computational resources. This resulted in a significant cost advantage, reducing our Spark processing costs by 90% or more (from $80 to $8 per job). Querying 10,000+ insights took a minute before. With MongoDB, the same task is now completed in under 6 seconds—a 10x improvement in performance . MongoDB’s flexible aggregation pipeline was instrumental in achieving these results. For example, we extensively use dynamic filter presets to control which insights are shown to which users, based on their role & authority. The MongoDB aggregation pipeline dynamically adapts to user configurations, retrieving only the data that’s relevant. LLM service & vector store The Genie+ feature in DataGenie is our LLM-powered application that unifies all DataGenie features through a conversational interface. We leverage MongoDB as a vector database to store KPI details, dimensions, and dimension values. Each vector document embeds essential metadata, facilitating fast and accurate retrieval for LLM-based queries. By serving as the vector store for DataGenie, MongoDB enables efficient semantic search, allowing the LLM to retrieve contextual, relevant KPIs, dimensions, and values with minimal latency, enhancing the accuracy and responsiveness of Genie+ interactions. Additionally, integrating MongoDB Atlas Search for semantic search significantly improved performance. It provided faster, more relevant results while minimizing integration challenges.MongoDB’s schema-less design and scalable architecture also streamlined data management. Knowledge store & cache MongoDB’s schema-less design enables us to store complex, dynamic relationships and scale them with ease. We also shifted to using MongoDB as our caching layer. Previously, having separate data stores made syncing and maintenance cumbersome. Centralizing this information in MongoDB simplified operations, enabled automatic syncing, and ensured consistent data availability across all features. With MongoDB, DataGenie is reducing time-to-market for feature releases Although we started the MongoDB migration to solve only our existing scalability and latency issues, we soon realized that just by migrating to MongoDB, we could imagine even bigger and more demanding features without engineering limitations. Figure 3. MongoDB + DataGenie integration. DataGenie engineering team refers v2 magic moment since migrating to MongoDB makes it a lot easier & flexible to roll out the following new features: DataGenie Nirvana: A delay in the supply chain for a raw material can cascade into a revenue impact. Conventional analytics relies on complex ETL pipelines and data marts to unify disparate data and deliver connected dashboard metrics. DataGenie Nirvana eliminates the need for a centralized data lake by independently generating aggregate metrics from each source and applying advanced correlation and causation algorithms on aggregated data to detect hidden connections. DataGenie Wisdom: Wisdom leverages an agentic framework & knowledge stores, to achieve two outcomes: Guided onboarding: Onboarding a new use case in DataGenie is as simple as explaining the business problem, success criteria, and sharing sample data - DataGenie autonomously configures itself for relevant metrics tracking to deliver the desired outcome. Next best action: DataGenie autonomously surfaces insights - like a 10% brand adoption spike in a specific market and customer demographics. By leveraging enterprise knowledge bases and domain-specific learning, DataGenie would propose targeted marketing campaigns as the Next Best Action for this insight. Powered by Genie: DataGenie offers powerful augmented analytics that can be quickly configured for any use case and integrated through secure, high-performance APIs. This powers data products in multiple verticals, including Healthcare & FinOps, to deliver compelling augmented analytics as a premium add-on, drastically reducing their engineering burden and GTM risk. All of these advanced features require enormous schema flexibility, low latency aggregation, and a vector database that’s always in sync with the metrics & insights. That’s exactly what we get with MongoDB! Powered by MongoDB Atlas, DataGenie delivers actionable insights to enterprises, helping them unlock new revenue potential and reduce costs. The following are some of the DataGenie use cases in Retail: Demand shifts & forecasting: Proactively adjust inventory or revise marketing strategies based on product demand changes. Promotional effectiveness: Optimize marketing spend by understanding which promotions resonate with which customer segments. Customer segmentation & personalization: Personalize offers based on customer behavior and demographics. Supply chain & logistics: Minimize disruptions by identifying potential bottlenecks and proposing alternative solutions. Inventory optimization: Streamline inventory management by flagging potential stockouts or overstock. Fraud & loss prevention: Detect anomalies in transaction data that may signal fraud or errors. Customer retention & loyalty: Propose retention strategies to address customer churn. Staffing optimization: Optimize customer support staffing. Final thoughts Migrating to MongoDB did more than just solve DataGenie’s scalability and latency challenges - it unlocked new possibilities. The flexibility of MongoDB allowed DataGenie to innovate faster and conceptualize new features such as Nirvana, Wisdom, and ultra-efficient microservices. This transformation stands as a proof of concept for future product companies considering partnering with MongoDB. The partnership between DataGenie and MongoDB is a testament to how the right technology choices can drive massive business value, improving performance, scalability, and cost-efficiency. Ready to unlock deeper retail insights? Head over to our retail page to learn more. Check out our Atlas Learning Hub to boost your MongoDB skills.
Introducing Database Digest: Building Foundations for Success
Today at MongoDB .local Toronto , I’m excited to share the first issue of Database Digest —MongoDB’s new digital magazine that explores the critical role of data in powering modern applications. This inaugural issue explores modern data architecture, and shows how—when the right data foundation meets emerging technologies—pioneering companies are fundamentally reimagining what's possible. The dawn of data ubiquity Currently, we stand in what McKinsey calls the " data ubiquity era "— with data flowing through organizations as essentially as electricity powers the modern world. The transformation to this era has brought both unprecedented opportunity and formidable challenges. Organizations must simultaneously manage huge volumes of data while delivering the real-time, personalized experiences that define competitive advantage today. Successfully doing so doesn’t mean merely adopting new technologies. Instead, it requires fundamentally rethinking how data is stored, processed, and leveraged to drive business value. Traditional relational database systems simply cannot meet these demands. The future belongs to organizations with data architectures designed for the agility, scalability, and versatility needed to handle diverse data types while seamlessly integrating with emerging technologies like AI. The cornerstone of AI success The rise of AI, and the speed at which the market has been changing have fundamentally shifted the importance of adaptability. However, software can only adapt as fast as its foundation allows. At MongoDB, we believe modern databases are the cornerstone of the age of AI, providing the essential capabilities needed for success in this new era. To do so, they must be able to: Handle all forms of data and provide intelligent search: Modern databases consolidate structured and unstructured data into a single system, eliminating silos that restrict AI innovation. They ground AI output in accurate, contextual data that drives better outcomes. Scale without constraints and react instantly: Databases should be able to adapt to unpredictable workloads and massive data volumes without performance degradation. They should enable real-time decisions and actions when opportunities or threats emerge. Embed domain-specific AI and secure data throughout: Modern databases enhance accuracy with specialized models that reduce hallucinations, and they protect information at every stage without sacrificing speed or functionality. Figure 1. Modern database demands. The impact of a modern database on AI innovation isn’t theoretical—we're seeing organizations like Swisscom leverage this approach to apply generative AI to their extensive expert content library, transforming how they serve the banking industry by delivering bespoke, contextual information within seconds. The AI revolution Perhaps nowhere is the impact of a modern data foundation more profound than in the rapid evolution of AI applications. In just a short time, we've progressed from simple LLM-powered chatbots to more advanced agentic systems capable of understanding complex goals, breaking them into manageable steps, and executing them autonomously—all while maintaining context and learning from interactions. This represents more than incremental progress—it's a fundamental shift in how AI serves as a strategic partner in solving business challenges. MongoDB sits at the heart of this transformation, providing the critical bridge between AI models and data while enabling vector storage, real-time processing, and seamless integration with LLM orchestrators. Companies like Questflow demonstrate the power of this approach, revolutionizing the future of work through a decentralized, autonomous AI agent network that orchestrates multiple AI agents collaborating with humans. By leveraging MongoDB's flexible document model and vector search capabilities, they're enabling startups to create dynamic AI solutions that handle everything from data analysis to content creation, while maintaining context and learning from interactions. Modernizing legacy systems: the strategic imperative For established enterprises, the journey to a modern data foundation often begins with addressing the legacy systems that consume up to 80% of IT budgets yet constrain innovation. Modernization isn't just a technical upgrade—it's a strategic move toward growth, efficiency, and competitive advantage. The evidence is compelling: Bendigo and Adelaide Bank achieved a staggering 90% reduction in both time and cost modernizing core banking applications using MongoDB's repeatable modernization framework and AI-powered migration tools. This transformation isn't just about cost savings—it's about creating the foundation for entirely new capabilities that drive business value. Modern data architecture must embody flexibility across multiple dimensions—from supporting diverse data models to providing deployment options spanning cloud-native, cloud-agnostic, and on-premise environments. This approach enables organizations to break free from silos, integrate AI capabilities, and create a unified data foundation supporting both current operations and future innovations. What’s next for data The organizations featured throughout Database Digest share a common vision: they recognize that tomorrow's success depends on today's data foundation. The convergence of flexible document models, advanced AI integration, and cloud-native capabilities isn't just enabling incremental improvements—it's powering applications and experiences that were never before possible. So I invite you to explore the full, inaugural issue of Database Digest to discover how MongoDB is helping organizations across industries build the foundation for tomorrow's success. This isn't just about technology—it's about creating the foundation for transformation that delivers real business value in our increasingly data-driven world. Visit mongodb.com/library/database-digest to download your copy and join us on this journey into the future of data.
Now Generally Available: 7 New Resource Policies to Strengthen Atlas Security
Organizations demand for a scalable means to enforce security and governance controls across their database deployments without slowing down developer productivity. To address this, MongoDB introduced resource policies in public preview on February 10th, 2025. Resource policies enable organization administrators to set up automated, organization-wide ‘guardrails’ for their MongoDB Atlas deployments. At public preview, three policies were released to this end. Today, MongoDB is announcing the general availability of resource policies in MongoDB Atlas. This release introduces seven additional policies and a new graphical user interface (GUI) for creating and managing policies. These enhancements give organizations greater control over MongoDB Atlas configurations, simplifying security and compliance automation. How resource policies enable secure innovation Innovation is essential for organizations to maintain competitiveness in a rapidly evolving global landscape. Companies with higher levels of innovation outperformed their peers financially, according to a Cornell University study analyzing S&P 500 companies between 1998 and 2023 1 . One of the most effective ways to drive innovation is by equipping developers with the right tools and giving them the autonomy to put them into action 2 . However, without standardized controls governing those tools, developers can inadvertently configure Atlas clusters to deviate from corporate or regulatory best practices. Manual approval processes for every new project create delays. Concurrently, platform teams struggle to enforce consistent security policies across the organization, leading to increased complexity and costs. As cybersecurity threats evolve daily and regulations tighten, granting developers autonomy and quickly provisioning access to essential tools can introduce risks. Organizations must implement strong security measures to maintain compliance and enable secure innovation. Resource policies empower organizations to enforce security and compliance standards across their entire Atlas environment. Instead of targeting specific user groups, these policies establish organization-wide guardrails to govern how Atlas can be configured. This reduces the risk of misconfigurations and security gaps. With resource policies, security and compliance standards are applied automatically across all Atlas projects and clusters. This eliminates the need for manual approvals. Developers gain self-service access to the resources they need while remaining within approved organizational boundaries. Simultaneously, platform teams can centrally manage resource policies to ensure consistency and free up time for strategic initiatives. Resource policies strengthen security, streamline operations, and help accelerate innovation by automating guardrails and simplifying governance. Organizations can scale securely while empowering developers to move faster without compromising compliance. What resource policies are available? table, th, td { border: 1px solid black; } Policy Type Description Available Since Restrict cloud provider Ensure clusters are only deployed on approved cloud providers (AWS, Azure, or Google Cloud). This prevents accidental or unauthorized deployments in unapproved environments. This supports organizations in meeting regulatory or business requirements. Public preview
GraphRAG with MongoDB Atlas: Integrating Knowledge Graphs with LLMs
A key challenge AI developers face is providing context to large language models (LLMs) to build reliable AI-enhanced applications; retrieval-augmented generation (RAG) is widely used to tackle this challenge. While vector-based RAG, the standard (or baseline) implementation of retrieval-augmented generation, is useful for many use cases, it is limited in providing LLMs with reasoning capabilities that can understand relationships between diverse concepts scattered throughout large knowledge bases. As a result, the accuracy of vector RAG-enhanced LLM outputs in applications can disappoint—and even mislead—end users. Now generally available, MongoDB Atlas ’ new LangChain integration for GraphRAG—a variation of RAG architecture that integrates a knowledge graph with LLMs—can help address these limitations. GraphRAG: Connecting the dots First, a short explanation of knowledge graphs: a knowledge graph is a structured representation of information in which entities (such as people, organizations, or concepts) are connected by relationships. Knowledge graphs work like maps, and show how different pieces of information relate to each other. This structure helps computers understand connections between facts, answer complex questions, and find relevant information more easily. Traditional RAG applications split knowledge data into chunks, vectorize them into embeddings, and then retrieve chunks of data through semantic similarity search; GraphRAG builds on this approach. But instead of treating each document or chunk as an isolated piece of information, GraphRAG considers how different pieces of knowledge are connected and relate to each other through a knowledge graph. Figure 1. Embedding-based vector search vs. entity-based graph search. GraphRAG improves RAG architectures in three ways: First, GraphRAG can improve response accuracy . Integrating knowledge graphs into the retrieval component of RAG has shown significant improvements in multiple publications. For example, benchmarks in the AWS investigation, “ Improving Retrieval Augmented Generation Accuracy with GraphRAG ” demonstrated nearly double the correct answers compared to traditional embedding-based RAG. Also, embedding-based methods rely on numerical vectors and can make it difficult to interpret why certain chunks are related. Conversely, a graph-based approach provides a visual and auditable representation of document relationships. Consequently, GraphRAG offers more explainability and transparency into retrieved information for improved insight into why certain data is being retrieved. These insights can help optimize data retrieval patterns to improve accuracy. Finally, GraphRAG can help answer questions that RAG is not well-suited for—particularly when understanding a knowledge base's structure, hierarchy, and links is essential . Vector-based RAG struggles in these cases because breaking documents into chunks loses the big picture. For example, prompts like “What are the themes covered in the 2025 strategic plan?” are not well handled. This is because the semantic similarity between the prompt, with keywords like “themes,” and the actual themes in the document may be weak, especially if they are scattered across different sections. Another example prompt like, “What is John Doe’s role in ACME’s renewable energy projects?” presents challenges because if the relationships between the person, the company, and the related projects are mentioned in different places, it becomes difficult to provide accurate responses with vector-based RAG. Traditional vector-based RAG can struggle in cases like these because it relies solely on semantic similarity search. The logical connections between different entities—such as contract clauses, legal precedents, financial indicators, and market conditions—are often complex and lack semantic keyword overlap. Making logical connections across entities is often referred to as multi-hop retrieval or reasoning in GraphRAG. However, GraphRAG has its own limitations, and is use-case dependent to achieve better accuracy than vector-based RAG: It introduces an extra step: creating the knowledge graph using LLMs to extract entities and relationships. Maintaining and updating the graph as new data arrives becomes an ongoing operational burden. Unlike vector-based RAG, which requires embedding and indexing—a relatively lightweight and fast process—GraphRAG depends on a large LLM to accurately understand, map complex relationships, and integrate them into the existing graph. The added complexity of graph traversal can lead to response latency and scalability challenges as the knowledge base grows. Latency is closely tied to the depth of traversal and the chosen retrieval strategy, both of which must align with the specific requirements of the application. GraphRAG introduces additional retrieval options . While this allows developers more flexibility in the implementation, it also adds complexity. The additional retrieval options include keyword and entity-based retrieval, semantic similarity on the first node, and more. MongoDB Atlas: A unified database for operational data, vectors, and graphs MongoDB Atlas is perfectly suited as a unified database for documents, vectors, and graphs. As a unified platform, it’s ideal for powering LLM-based applications with vector-based or graph-based RAG. Indeed, adopting MongoDB Atlas eliminates the need for point or bolt-on solutions for vector or graph functionality, which often introduce unnecessary complexity, such as data synchronization challenges that can lead to increased latency and potential errors. The unified approach offered by MongoDB Atlas simplifies the architecture and reduces operational overhead, but most importantly, it greatly simplifies the development experience. In practice, this means you can leverage MongoDB Atlas' document model to store rich application data, use vector indexes for similarity search, and model relationships using document references for graph-like structures. Implementing GraphRAG with MongoDB Atlas and LangChain Starting from version 0.5.0, the langchain-mongodb package introduces a new class to simplify the implementation of a GraphRAG architecture. Figure 2. GraphRAG architecture with MongoDB Atlas and LangChain First, it enables the automatic creation of a knowledge graph. Under the hood, it uses a specific prompt sent to an LLM of your choice to extract entities and relationships, structuring the data to be stored as a graph in MongoDB Atlas. Then, it sends a query to the LLM to extract entities and then searches within the graph to find connected entities, their relationships, and associated data. This information, along with the original query, then goes back to the LLM to generate an accurate final response. MongoDB Atlas’ integration in LangChain for GraphRAG follows an entity-based graph approach. However, you can also develop and implement your own GraphRAG with a hybrid approach using MongoDB drivers and MongoDB Atlas’ rich search and aggregation capabilities. Enhancing knowledge retrieval with GraphRAG GraphRAG complements traditional RAG methods by enabling deeper understanding of complex, hierarchical relationships, supporting effective information aggregation and multi-hop reasoning. Hybrid approaches that combine GraphRAG with embedding-based vector search further enhance knowledge retrieval, making them especially effective for advanced RAG and agentic systems. MongoDB Atlas’ unified database simplifies RAG implementation and its variants, including GraphRAG and other hybrid approaches, by supporting documents, vectors, and graph representations in a unified data model that can seamlessly scale from prototype to production. With robust retrieval capabilities ranging from full-text and semantic search to graph search, MongoDB Atlas provides a comprehensive solution for building AI applications. And its integration with proven developer frameworks like LangChain accelerates the development experience—enabling AI developers to build more advanced and efficient retrieval-augmented generation systems that underpin AI applications. Ready to dive into GraphRAG? Learn how to implement it with MongoDB Atlas and LangChain. Head over to the Atlas Learning Hub to boost your MongoDB skills and knowledge.
Driving Retail Loyalty with MongoDB and Cognigy
Retail is one of the fastest moving industries, often the very first to leverage cutting-edge AI to create next-gen experiences for their customers. One of the latest areas we’re seeing retailers invest in is agentic AI: they are creating conversational chatbot “agents” that are pulling real-time information from their systems, using Natural Language processing to create conversational responses to customer queries, and then taking action- completing tasks and solving problems. In this race to stay ahead of their competition, retailers today are struggling to quickly bring to market these agents and don’t always have the AI skills in-house. Many are looking to the broad ecosystem of off-the-shelf solutions to leverage the best of what’s already out there—reducing time to market for their AI agents and leaving the AI models and integrations to the experts in the field. Some of the most successful retail conversational AI agents we’ve seen are built on Cognigy , a global leader in customer service solutions. With Cognigy, retailers are quickly spinning up conversational AI agents on top of their MongoDB data to create personalized conversational experiences that not only meet but anticipate customer expectations. Increasingly, whether or not retailers offer customers immediate, seamless interactions are key to retaining their loyalty. Why next-gen conversational AI matters in retail Customer loyalty has been declining yearly, and customers are moving to retailers who can provide an elevated experience at every interaction. According to HubSpot’s 2024 annual customer service survey , 90% of customers expect an immediate response to their inquiries, highlighting how speed has become a critical factor in customer satisfaction. Additionally, 45.9% of business leaders prioritize improving customer experience over product and pricing , demonstrating that in retail, speed and personalization are no longer optional as they define whether a customer stays or moves on. The chatbots of the past that relied on simple rules-based engines and static data don’t meet these customers' new expectations as they lack real-time business context, and can generate misleading answers as they’re not training on the retailer's in-house data sets. This is where Cognigy’s AI agents can create a more compelling experience: These intelligent systems integrate real-time business data with the capabilities of LLMs, enabling AI-driven experiences that are not only personalized but also precise and controlled. Instead of leaving responses open to interpretation, retailers can customize interactions , guide users through processes, and ensure AI-driven recommendations align with actual inventory, customer history, and business rules. This level of contextual understanding and action creates trust-driven experiences that foster loyalty. Having quality data and the ability to harness it effectively is the only way to meet the strategic imperatives that customers demand today. This requires key factors such as being fast, flexible, and high-performing at the scale of your business operations, as winning companies must store and manage their information efficiently. This is where MongoDB, a general-purpose database, truly shines. It is designed to manage your constantly evolving business data, such as inventory, orders, transaction history, and user preferences. MongoDB’s document model stands out in the retail industry, offering the flexibility and scalability businesses need to thrive in today’s fast-paced environment. Cognigy can use this real-time operational data from MongoDB as a direct input to build, run, and deploy conversational AI agents at scale. With just a few clicks, businesses can create AI-driven chatbots and voice agents powered by large language models (LLMs), following their business workflows in a smooth and easy-to-implement way. These agents can seamlessly engage with customers across various phone lines as a major driver for customer interactions, including website chat, Facebook Messenger, and WhatsApp, offering personalized interactions. On the back end, Cognigy is built on MongoDB as its operational data store, taking full advantage of MongoDB’s scalability and high performance to ensure that its conversational AI systems can efficiently process and store large volumes of real-time data while maintaining high availability and reliability. The power of combining AI agents with real-time business data transforms personalization from a static concept into a dynamic ever-evolving experience that makes customers feel truly recognized and understood at every touchpoint. By harnessing these intelligent systems, retailers can go beyond generic interactions to deliver seamless, relevant, and engaging experiences that naturally strengthen customer relationships. Ultimately, true personalization isn’t just about efficiency; it’s about creating meaningful connections that drive lasting customer engagement and loyalty. Let’s look at how this looks in the Cognigy interface when you’re creating a flow for your chatbot: What’s happening behind the scenes? Figure 1 below shows an example customer journey, and demonstrates how Cognigy and MongoDB work together to use real-time data to give reliable and conversational responses to customer questions: Figure 1. An Agentic AI conversational flow with Cognigy pulling user and order data from MongoDB This user’s journey starts when they make a purchase on a retailer’s ecommerce application. The platform securely stores the order details, including product information, customer data, and order status, in MongoDB. To coordinate the delivery, the user reaches out via a chatbot or phone conversation orchestrated by Cognigy AI agents, using advanced Large Language Models (LLMs) to understand the user’s inquiries and respond in a natural, conversational tone. The AI agent retrieves the necessary user information and order details from MongoDB, configured as the data source, taking real-time data that is always up to date. By understanding the user’s query, the agent retrieves the appropriate database information and is also able to update the database with any relevant information generated during the conversation, such as modifying a delivery appointment. As the user schedules their delivery, Cognigy updates the information directly in MongoDB, leveraging features like triggers and change streams to seamlessly synchronize real-time data with other key systems in the customer journey, such as inventory management and delivery providers. This ensures personalized user experiences at every interaction. Shaping the future of customer service with MongoDB and Cognigy Delivering responsive, personalized customer service is more essential than ever. By combining MongoDB’s flexible, versatile, and performant data management with Cognigy’s powerful conversational AI, businesses can create seamless, real-time interactions that keep customers engaged. The future of customer service is fast, dynamic, and seamlessly integrated into business operations. With MongoDB and Cognigy, organizations can harness the power of AI to automate and personalize customer interactions in real time, without the need for extensive development efforts. The MongoDB-Cognigy integration enables businesses to scale context-driven interactions, strengthen customer relationships, and exceed expectations while building lasting customer loyalty. Learn more about how Cognigy built a leading conversational AI solution with MongoDB on our customer story page. Needing a solution for your retail needs? Head over to our retail solutions page to learn how MongoDB supports retail innovation. Read our blog to learn how to enhance retail solutions with retrieval-augmented generation (RAG).
What’s New From MongoDB at Google Cloud Next 2025
At Google Cloud Next '25, MongoDB is excited to celebrate a deepening collaboration with Google Cloud, focused on delivering cutting-edge solutions that empower developers, enterprises, and startups alike. The event comes as MongoDB Atlas adds availability for Google Cloud regions in Mexico and South Africa, further expanding joint customers’ ability to deploy, scale, and manage their applications closer to their users while meeting local compliance and performance requirements. MongoDB is also honored to have achieved the 2025 Google Cloud Partner of the Year for Data & Analytics - Marketplace. This award is a testament to the enterprise-scale success stories driven by our combined data and analytics solutions. It’s also MongoDB’s sixth consecutive year as a Google Cloud Partner of the Year, reflecting the relentless innovation and customer-first mindset that define MongoDB’s partnership with Google Cloud. This is in addition to achieving the Google Cloud Ready – Regulated and Sovereignty Solutions Badge. The designation is a major milestone for MongoDB, and demonstrates our ability to deliver compliant and secure solutions that meet the highest standards for data sovereignty. More broadly, we’ve been focused on expanding our collaboration in order to unlock new opportunities for customers to enhance developer productivity, launch AI-powered applications, and do more with their data in 2025. Read on to learn more about what we’ve been working on. Enhancing developer productivity with gen AI For over a decade, MongoDB and Google Cloud have established a rich track record of making it easier, faster, and more secure to build enterprise-grade applications. Our latest gen AI collaborations further this mission, simultaneously enhancing innovation and efficiency. MongoDB is proud to be a launch partner for Google Cloud’s Gemini Code Assist. Announced in December and launching for MongoDB users this week at Google Cloud Next, our integration with Gemini Code Assist enables developers to seamlessly access the latest MongoDB documentation and code snippets within their IDEs. This innovative integration enhances developer productivity by providing immediate access to MongoDB resources, making development workflows more efficient by keeping developers 'in the flow' rather than having to hop in and out of the IDEs to find the information and code examples they need. MongoDB is also expanding our presence in Project IDX , an AI-assisted development workspace for full-stack, multiplatform applications. With MongoDB templates now available in IDX, developers can quickly set up MongoDB environments without leaving their IDE, accelerating the development of generative AI applications and other cloud-based solutions. Learn more by reading this blog post from Google. Developers building applications in Firebase can now integrate MongoDB Atlas with a few clicks. The new Firebase extension for MongoDB Atlas eliminates the need for complex query pipelines or manual data transfers, making it easier than ever to deploy and scale apps leveraging MongoDB Atlas as a vector database in Firebase. Additionally, the new MongoDB extension enables real-time synchronization between Firebase and MongoDB data, ensuring data consistency across both platforms. By combining the power of Firebase Extensions, MongoDB Atlas, and a direct MongoDB connector, developers can create innovative and data-driven applications with greater efficiency and ease. Streamlining cloud migrations Developers are taking advantage of the latest models and tooling to build the next wave of gen AI applications. As they do so, they’re wrangling unprecedented volumes of structured and unstructured data, and, in doing so, are facing growing requirements for application scalability and performance. As such, businesses have uncovered a newfound imperative to modernize and take advantage of cloud-native solutions that offer the highest levels of scalability and performance, as well as interoperability with their favorite tools. MongoDB and Google Cloud have made it even easier to make the move to the cloud with Google Migration Center, a unified platform that streamlines the transition from on-premises servers to the Google Cloud environment, offering tools for discovery, assessment, and planning. Within Google Cloud Migration Center, users can now generate cost assessments and migration plans for the on-premises MongoDB instances directly in Google Cloud Migration Console, simplifying the transition to MongoDB Atlas on Google Cloud. Specifically, users can now use integrated MongoDB cluster assessment to gain in-depth visibility into MongoDB deployments, both Community and Enterprise editions, running on your existing infrastructure. Learn more on our blog . With the aim of making it easier and quicker to deploy to the cloud, MongoDB Atlas is now available as part of Cloud Foundation Fabric. Specifically, Atlas is available within Fabric FAST, which streamlines Google Cloud organization setup using a pre-defined enterprise-grade design and a Terraform reference implementation. By integrating MongoDB Atlas, enterprises can enhance production readiness for applications that require persistent data, offloading database management overhead while ensuring high availability, scalability, and security. This integration complements FAST’s infrastructure automation, enabling organizations to quickly deploy robust, data-driven applications within an accelerated Google Cloud environment, reducing the time needed to establish a fully functional, enterprise-level platform. Check out the Github repository . Optimizing analytics and archiving Despite many organizations’ focus on modernization and generative AI, analytics and data warehousing remain essential pillars of the enterprise workflow. Building on our existing integration with BigQuery, Google Cloud’s fully managed data warehouse, MongoDB Atlas now offers native JSON support for BigQuery, eliminating the need for complex data transformations. This enhancement significantly reduces operational costs, improves query performance, and enables businesses to analyze structured and unstructured data with greater flexibility and efficiency. The Dataflow template is now 'Generally Available' for MongoDB and Google Cloud customers. A key advantage of this pipeline lies in its ability to directly leverage BigQuery's powerful JSON functions on the MongoDB data loaded into BigQuery. This eliminates the need for a complex and time-consuming data transformation process as the JSON data within BigQuery can be queried and analyzed using standard BQML queries. Learn more about the new launch from our blog . In a big step forward for MongoDB, Atlas now supports Data Federation and Online Archive directly on Google Cloud. With these new additions, users can effortlessly manage and archive cold data and perform federated queries across Google Cloud storage, all from within their MongoDB Atlas console. This integration provides businesses with cost-effective data management and analysis capabilities. Upskilling for the AI era Earlier this year, MongoDB introduced a new Skill Badges program , offering focused credentials to help learners quickly master and validate their skills with MongoDB. These badges are an excellent way for developers, database administrators, and architects to demonstrate their dedication to skill development and continuous learning. In just 60-90 minutes, participants can learn new skills, finish a short assessment, and earn a shareable digital badge through Credly. They can then display this badge on platforms like LinkedIn to highlight their accomplishments and career development. At Google Next, attendees will have the opportunity to earn the RAG with MongoDB Skill Badge by using our self-paced Google Lab or by interacting directly with our experts in the Makerspace. This badge focuses on building Retrieval-Augmented Generation (RAG) applications, teaching participants how to integrate vector search and improve retrieval workflows to enhance apps powered by LLMs. Whether you prefer the guided support in the Makerspace or the flexibility of the self-paced lab, this hands-on experience will provide you with advanced skills that you can apply to your projects. The bottom line is that we’ve been busy! MongoDB’s deepening collaboration with Google Cloud continues to unlock new innovations across AI, application development, and cloud infrastructure. Stop by Booth #1240 at Google Cloud Next or join one of MongoDB’s featured sessions to explore these advancements and discover how MongoDB and Google Cloud are shaping the future of AI and data-driven applications. Head over to our MongoDB Atlas Learning Hub to boost your MongoDB skills.
Modernize On-Prem MongoDB With Google Cloud Migration Center
Shifting your business infrastructure to the cloud offers significant advantages, including enhanced system performance, reduced operational costs, and increased speed and agility. However, a successful cloud migration isn’t a simple lift-and-shift. It requires a well-defined strategy, thorough planning, and a deep understanding of your existing environment to align with your company’s unique objectives. Google Cloud’s Migration Center is designed to simplify this complex process, acting as a central hub for your migration journey. It streamlines the transition from your on-premises servers to the Google Cloud environment, offering tools for discovery, assessment, and planning. MongoDB is excited to announce a significant enhancement to Google Cloud Migration Center: integrated MongoDB cluster assessment in the Migration Center Use Case Navigator. Google Cloud and MongoDB have collaborated to help you gain in-depth visibility into your MongoDB deployments, both MongoDB Community Edition and MongoDB Enterprise Edition , and simplify your move to the cloud. To understand the benefits of using Migration Center, let’s compare it with the process of migrating without it. Image 1. Image of the Migration Center Use Case Navigator menu, showing migration destinations for MongoDB deployments. Migrating without Migration Center Manual discovery: Without automation, asset inventories were laborious, leading to frequent errors and omissions. Complex planning: Planning involved cumbersome spreadsheets and manual dependency mapping, making accurate cost estimation and risk assessment difficult. Increased risk: Lack of automated assessment resulted in higher migration failure rates and potential data loss, due to undiscovered compatibility issues. Fragmented tooling: Disparate tools for each migration phase created inefficiencies and complexity, hindering a unified migration strategy. Higher costs and timelines: Manual processes and increased risks significantly lengthened project timelines and inflated migration costs. Specialized skill requirement: Migrating required teams to have deep specialized knowledge of all parts of the infrastructure being moved. Migrating with Migration Center When you move to the cloud, you want to make your systems better, reduce costs, and improve performance. A well-planned migration helps you do that. With Migration Center’s new MongoDB assessment, you can: Discover and inventory your MongoDB clusters: Easily identify all your MongoDB Community Server and MongoDB Enterprise Server clusters running in your on-premises environment. Gain deep insights: Understand the configuration, performance, and resource utilization of your MongoDB clusters. This data is essential for planning a successful and cost-effective migration. Simplify your migration journey: By providing a clear understanding of your current environment, Migration Center helps you make informed decisions and streamline the migration process, minimizing risk and maximizing efficiency. Use a unified platform: Migration Center is designed to be a one-stop shop for your cloud migration needs. It integrates asset discovery, cloud spend estimation, and various migration tools, simplifying your end-to-end journey. Accelerate using MongoDB Atlas : Migrate your MongoDB workloads to MongoDB Atlas running on Google Cloud with confidence. Migration Center provides the data you need to ensure a smooth transition, enabling you to fully use the scalability and flexibility of MongoDB Atlas. By providing MongoDB workload identification and guidance, the Migration Center Use Case Navigator enables you to gain valuable insights into the potential transformation journeys for your MongoDB workloads. With the ability to generate comprehensive reports on your MongoDB workload footprint, you can better understand your MongoDB databases. This ultimately enables you to update your systems and gain the performance enhancement of using MongoDB Atlas on Google Cloud, all while saving money. Learn more about Google Cloud Migration Center from the documentation . Visit our product page to learn more about MongoDB Atlas . Get started with MongoDB Atlas on Google Cloud today.
Firebase & MongoDB Atlas: A Powerful Combo for Rapid App Development
Firebase and MongoDB Atlas are powerful tools developers can use together to build robust and scalable applications. Firebase offers build and runtime solutions for AI-powered experiences, while MongoDB Atlas provides a fully managed cloud database service optimized for generative AI applications. We’re pleased to announce the release of the Firebase extension MongoDB Atlas , a direct MongoDB connector for Firebase that further streamlines the development process by enabling seamless integration between the two platforms. This extension enables developers to directly interact with MongoDB collections and documents from within their Firebase projects, simplifying data operations and reducing development time. A direct MongoDB connector, built as a Firebase extension , facilitates real-time data synchronization between Firebase and MongoDB Atlas. This enables data consistency across both platforms, empowering developers to build efficient, data-driven applications using the strengths of Firebase and MongoDB. MongoDB as a backend database for Firebase applications Firebase offers a streamlined backend for rapid application development, providing offerings like authentication, hosting, and real-time databases. However, applications requiring complex data modeling, high data volumes, or sophisticated querying often work well with MongoDB’s document store. Integrating MongoDB as the primary data store alongside Firebase addresses these challenges. MongoDB provides a robust document database with a rich query language (MongoDB Query Language), powerful indexing (including compound, geospatial, and text indexes), and horizontal scalability for handling massive datasets. This architecture enables developers to use Firebase’s convenient backend services while benefiting from MongoDB’s powerful data management capabilities. Developers commonly use Firebase Authentication for user management, then store core application data, including complex relationships and large volumes of information, in MongoDB. This hybrid approach combines Firebase’s ease of use with MongoDB’s data-handling prowess. Furthermore, the integration of MongoDB Atlas Vector Search significantly expands the capabilities of this hybrid architecture. Modern applications increasingly rely on semantic search and AI-driven features, which require efficient handling of vector embeddings. MongoDB Atlas Vector Search enables developers to perform similarity searches on vector data, unlocking powerful use cases Quick-start guide for Firebase’s MongoDB Atlas extension With the initial release of the MongoDB Atlas extension in Firebase, we are targeting the extension to perform operations such as findOne , insertOne , and vectorSearch on MongoDB. This blog will not cover how to create a Firebase application but will walk you through creating a MongoDB backend for connecting to MongoDB using our Firebase extension. To learn more about how to integrate the deployed backend into a Firebase application, see the official Firebase documentation . Install the MongoDB Atlas extension in Firebase. Open the Firebase Extensions Hub. Find and select the MongoDB Atlas extension. Or use the search bar to find “MongoDB Atlas.” Click on the extension card. Click the “Install” button. You will be redirected to the Firebase console. On the Firebase console, choose the Firebase project where you want to install the extension. Image 1. Image of the MongoDB Atlas extension’s installation page. On the installation page: Review “Billing and Usage.” Review “API Endpoints.” Review the permissions granted to the function that will be created. Configure the extension: Provide the following configuration details: MongoDB URI: The connection string for your MongoDB Atlas cluster Database Name: The name of the database you want to use Collection Name: The name of the collection you want to use Vertex AI Embedding to use: The type of embedding model from Vertex AI Vertex AI LLM model name: The name of the large language model (LLM) model from Vertex AI MongoDB Index Name: The name of the index in MongoDB MongoDB Index Field: The field that the index is created upon MongoDB Embedding Field: The field that contains the embedding vectors LLM Prompt: The prompt that will be sent to the LLM Click on “Install Extension.” Image 2. Image of the MongoDB Atlas extension created from Firebase extension hub. Once the extension is created, you can interact with it through the associated Cloud Function. Image 3. Firebase extension created cloud run function In conclusion, the synergy between Firebase extensions and MongoDB Atlas opens up exciting possibilities for developers seeking to build efficient, scalable, AI-powered applications. By using Firebase’s streamlined backend services alongside MongoDB’s robust data management and vector search capabilities, developers can create applications that handle complex data and sophisticated AI functionalities with ease. The newly introduced Firebase extension for MongoDB Atlas, specifically targeting operations like findOne , insertOne , and vectorSearch , marks a significant step toward simplifying this integration. While this initial release provides a solid foundation, the potential for further enhancements, such as direct connectors and real-time synchronization, promises to further empower developers. As demonstrated through the quick-start guide, setting up this powerful combination is straightforward, enabling developers to quickly harness the combined strength of these platforms. Ultimately, this integration fosters a more flexible and powerful development environment, enabling the creation of innovative, data-driven applications that meet the demands of modern users. Build your application with a pre-packaged solution using Firebase . Visit our product page to learn more about MongoDB Atlas .
Next-Generation Mobility Solutions with Agentic AI and MongoDB Atlas
Driven by advancements in vehicle connectivity, autonomous systems, and electrification, the automotive and mobility industry is currently undergoing a significant transformation. Vehicles today are sophisticated machines, computers on wheels, that generate massive amounts of data, driving demand for connected and electric vehicles. Automotive players are embracing artificial intelligence (AI), battery electrical vehicles (BEVs), and software-defined vehicles (SDVs) to maintain their competitive advantage. However, managing fleets of connected vehicles can be a challenge. As cars get more sophisticated and are increasingly integrated with internal and external systems, the volume of data they produce and receive greatly increases. This data needs to be stored, transferred, and consumed by various downstream applications to unlock new business opportunities. This will only grow: the global fleet management market is projected to reach $65.7 billion by 2030, growing at a rate of almost 10.8% annually. A 2024 study conducted by Webfleet showed that 32% of fleet managers believe AI and machine learning will significantly impact fleet operations in the coming years; optimizing route planning and improving driver safety are the two most commonly cited use cases. As fleet management software providers continue to invest in AI, the integration of agentic AI can significantly help with things like route optimization and driver safety enhancement. For example, AI agents can process real-time traffic updates and weather conditions to dynamically adjust routes, ensuring timely deliveries while advising drivers on their car condition. This proactive approach contrasts with traditional reactive methods, improving vehicle utilization and reducing operational and maintenance costs. But what are agents? In short, they are operational applications that attempt to achieve goals by observing the world and acting upon it using the data and tools the application has at its disposal. The term "agentic" denotes having agency, as AI agents can proactively take steps to achieve objectives without constant human oversight. For example, rather than just reporting an anomaly based on telemetry data analysis, an agent for a connected fleet could autonomously cross-check that anomaly against known issues, decide whether it's critical or not, and schedule a maintenance appointment all on its own. Why MongoDB for agentic AI Agentic AI applications are dynamic by nature as they require the ability to create a chain of thought, use external tools, and maintain context across their entire workflow. These applications generate and consume diverse data types, including structured and unstructured data. MongoDB’s flexible document model is uniquely suited to handle both structured and unstructured data as vectors. It allows all of an agent’s context, chain-of-thought, tools metadata, and short-term and long-term memory to be stored in a single database. This means that developers can spend more time on innovation and rapidly iterate on agent designs without being constrained by rigid schemas of a legacy relational database. Figure 1. Major components of an AI agent. Figure 1 shows the major components of an AI agent. The agent will first receive a task from a human or via an automated trigger, and will then use a large language model (LLM) to generate a chain of thought or follow a predetermined workflow. The agent will use various tools and models during its run and store/retrieve data from a memory provider like MongoDB Atlas . Tools: The agent utilizes tools to interact with the environment. This can contain API methods, database queries, vector search, RAG application, anything to support the model Models: can be a large language model (LLM), vision language model (VLM), or a simple supervised machine learning model. Models can be general purpose or specialized, and agents may use more than one. Data: An agent requires different types of data to function. MongoDB’s document model allows you to easily model all of this data in one single database. An agentic AI spans a wide range of functional tools and context. The underlying data structures evolve throughout the agentic workflow and as an agent uses different tools to complete a task. It also builds up memory over time. Let us list down the typical data types you will find in an agentic AI application. Data types: Agent profile: This contains the identity of the agent. It includes instructions, goals and constraints. Short-term memory: This holds temporary, contextual information—recent data inputs or ongoing interactions—that the agent uses in real-time. For example, short-term memory could store sensor data from the last few hours of vehicle activity. In certain agentic AI frameworks like Langgraph, short term memory is implemented through a checkpointer. The checkpointer stores intermediate states of the agent’s actions and/or reasoning. This memory allows the agent to seamlessly pause and resume operations. Long-term memory: This is where the agent stores accumulated knowledge over time. This may include patterns, trends, logs and historical recommendations and decisions. By storing each of these data types into rich, nested documents in MongoDB, AI developers can create a single-view representation of an agent’s state and behavior. This enables fast retrieval and simplifies development. In addition to the document model advantage, building agentic AI solutions for mobility requires a robust data infrastructure. MongoDB Atlas offers several key advantages that make it an ideal foundation for these AI-driven architectures. These include: Scalability and flexibility: Connected Car platforms like fleet management systems need to handle extreme data volumes and variety. MongoDB Atlas is proven to scale horizontally across cloud clusters, letting you ingest millions of telemetry events per minute and store terabytes of telemetry data with ease. For example, the German company ZF uses MongoDB to process 90,000 vehicle messages per minute (over 50 GB of data per day) from hundreds of thousands of connected cars. The flexibility of the document model accelerates development and ensures your data model stays aligned with the real-world entities it represents. Built-in vector search: AI agents require a robust set of tools to work with. One of the most widely used tools is vector search, which allows agents to perform semantic searches on unstructured data like driver logs, error codes descriptions, and repair manuals. MongoDB Atlas Vector Search allows you to store and index high-dimensional vectors alongside your documents and to perform semantic search over unstructured data. In practice, this means your AI embeddings live right next to the relevant vehicle telemetry and operational data in the database, simplifying architectures for use cases like the connected car incident advisor, in which a new issue can be matched against past issues before passing contextual information to the LLM. For more, check out this example of how an automotive OEM leverages vector search for audio based diagnostics with MongoDB Atlas Vector Search. Time series collections and real-time data processing: MongoDB Atlas is designed for real-time applications. It provides time series collections for connected car telemetry data storage, change streams, and triggers that can react to new data instantly. This is crucial for agentic AI feedback loops, where ongoing data ingestion and learning are happening continuously. Best-in-class embedding models with Voyage AI: In early 2025, MongoDB acquired Voyage AI , a leader in embedding and reranking models. Voyage AI embedding models are currently being integrated into MongoDB Atlas, which means developers will no longer need to manage external embedding APIs, standalone vector stores, or complex search pipelines. AI retrieval will be built into the database itself, making semantic search, vector retrieval, and ranking as seamless as traditional queries. This will reduce the time required for developing agentic AI applications. Agentic AI in action: Connected fleet incident advisor Figure 2 shows a list of use cases in the Mobility sector, sorted by various capabilities that an agent might demonstrate. AI agents excel at managing multi-step tasks via context management across tasks, they automate repetitive tasks better than Robotic process automation (RPA), and they demonstrate human-like reasoning by revisiting and revising past decisions. These capabilities enable a wide range of applications both during the manufacturing of a vehicle and while it's on the road, connected and sending telemetry. We will review a use case in detail below, and will see how it can be implemented using MongoDB Atlas, LangGraph, Open AI, and Voyage AI. Figure 2. Major use cases of agentic AI in the mobility and manufacturing sectors. First, the AI agent connects to traditional fleet management software and supports the fleet manager in diagnosing and advising the drivers. This is an example of a multi-step diagnostic workflow that gets triggered when a driver submits a complaint about the vehicle's performance (for example, increased fuel consumption). Figure 3 shows the sequence diagram of the agent. Upon receiving the driver complaint, it creates a chain of thought that follows a multi-step diagnostic workflow where the system ingests vehicle data such as engine codes and sensor readings, generates embeddings using the Voyage AI voyage-3-large embedding model, and performs a vector search using MongoDB Atlas to find similar past incidents. Once relevant cases are identified, those–along with selected telemetry data–are passed to OpenAI gpt-4o LLM to generate a final recommendation for the driver (for example, to pull off immediately or to keep driving and schedule regular maintenance). All data, including telemetry, past issues, session logs, agent profiles, and recommendations are stored in MongoDB Atlas, ensuring traceability and the ability to refine diagnostics over time. Additionally, MongoDB Atlas is used as a checkpointer by LangGraph, which defines the agent's workflow. Figure 3. Sequence diagram for a connected fleet advisor agentic workflow. Figure 4 shows the agent in action, from receiving an issue to generating a recommendation. So by leveraging MongoDB’s flexible data model and powerful Vector Search capabilities, we can agentic AI can transform fleet management through predictive maintenance and proactive decision-making. Figure 4. The connected fleet advisor AI agent in action. To set up the use case shown in this article, please visit our GitHub repository . And to learn more about MongoDB’s role in the automotive industry, please visit our manufacturing and automotive webpage . Want to learn more about why MongoDB is the best choice for supporting modern AI applications? Check out our on-demand webinar, “ Comparing PostgreSQL vs. MongoDB: Which is Better for AI Workloads? ” presented by MongoDB Field CTO, Rick Houlihan.
Why MongoDB is the Perfect Fit for a Unified Namespace
Smart manufacturing is transforming the industrial world by combining IoT, AI, and cloud technologies to create connected, data-driven production environments. Manufacturers embracing this shift are seeing real, measurable benefits: Deloitte reports that smart factory initiatives can boost manufacturing productivity by up to 12% and improve overall equipment effectiveness by up to 20%. But achieving these gains isn’t always straightforward. Many manufacturers still face the challenge of siloed data and legacy systems, making it difficult to get a real-time, holistic view of operations. Shop floor data, enterprise resource planning (ERP) systems, manufacturing execution system (MES) platforms, and other sources often operate in isolation, limiting the potential for optimization. The concept of a Unified Namespace model, which provides a single source of truth for all operational data, is a game-changing approach that helps unify these siloed systems into a cohesive ecosystem. MongoDB, with its powerful document-based model , is perfectly suited to be the backbone of this Unified Namespace model, acting as a flexible, scalable, highly available, and real-time repository that can seamlessly integrate and manage complex manufacturing data. In this blog post, we’ll explore how MongoDB’s architecture and capabilities align perfectly with the needs of a UNS, and how our "Leafy Factory" demo serves as a strong proof point of this alignment. Understanding the Unified Namespace and its importance in manufacturing A Unified Namespace (UNS) is an architecture in which production data across an organization is consolidated into one central data repository. In a manufacturing setup, a UNS enables the integration of diverse sources like ERP for business operations, MES for production monitoring, and real-time shop floor data. This centralized model provides a single, consistent view of data, allowing teams across the organization to access reliable information for decision-making. By unifying data from various systems, a UNS makes it significantly easier to connect disparate systems and ensures that data can be shared seamlessly across platforms, reducing complexity and integration overhead. Unlike the traditional automation pyramid, in which information flows hierarchically from sensors up through control systems, MES, and finally to ERP, the UNS breaks down these layers. It creates a flat, real-time data model that allows every system to access and contribute to a shared source of truth—eliminating delays, redundancies, and disconnects between layers. One of the most impactful advantages of a UNS is real-time data visibility. By centralizing live data streams from the production floor, it provides stakeholders—from operators to executives—with up-to-the-second insights. This immediacy empowers teams to make informed decisions quickly, respond to issues as they arise, and continuously optimize operations. And because the UNS consolidates all data into one namespace, it also unlocks cross-functional insights. Teams can correlate metrics across departmental boundaries—for instance, comparing machine uptime with production targets and financial performance. This integrated perspective enables more strategic planning, better alignment across departments, and continuous improvement initiatives grounded in data. The importance of flexible data to UNS success A key prerequisite for a successful UNS implementation is high adaptability. The model must be capable of easily incorporating new data sources, machines, or production lines without requiring a complete overhaul of the data architecture. This flexibility ensures that as operations evolve and scale, the UNS can grow with them—maintaining a unified and responsive data environment. While the UNS itself does not perform functions like predictive maintenance or cost optimization, it serves as the foundational data layer that enables such advanced applications. By centralizing and contextualizing historical and real-time data on machinery, materials, and production workflows, a UNS provides the essential infrastructure for building IoT-based solutions. With this data in place, manufacturers can develop predictive maintenance strategies, detect anomalies, and optimize costs—leading to reduced downtime, better resource utilization, and smarter decision-making. Together, these capabilities make the Unified Namespace a foundational element for smart manufacturing—bridging systems, enhancing visibility, and enabling data-driven transformation at scale. Figure 1. The automation pyramid versus a Unified Namespace. MongoDB as the ideal central repository for a UNS model The requirements of a UNS model map directly to MongoDB's strengths, making it an ideal choice for manufacturing environments seeking to unify their data. Manufacturing environments always deal with highly variable and constantly evolving data structures, ranging from raw machine sensor data to structured ERP records. This diversity presents a challenge for traditional relational databases, which rely on rigid schemas that are difficult to adapt. MongoDB, with its document-oriented design, offers a more flexible solution. By storing data in JSON-like structures, it allows manufacturers to easily accommodate changes—such as adding new sensors or modifying machine attributes—without the need to redesign a fixed schema. Another key requirement in smart manufacturing is the ability to process data in real time. With streaming data from multiple sources flowing into a UNS, manufacturers can maintain up-to-date information that supports timely interventions and data-driven decision-making. MongoDB supports real-time data ingestion through technologies like Kafka, change streams, and MQTT. This makes it simple to capture live data directly from shop floor machines into a time series collection and synchronize it with information from ERP and MES. Live shopfloor data, ERP, and MES information in one database—combined with MongoDB’s powerful querying, aggregating and analytics capabilities—allows teams to analyze and correlate diverse data streams in one platform. For instance, production teams can cross-reference MES quality metrics with sensor data to uncover patterns that lead to improved quality control. Finance teams can blend ERP cost data with MES output to gain a more comprehensive view of operational efficiency and cost drivers. What’s more, MongoDB’s distributed architecture supports horizontal scaling, which is crucial for large manufacturing operations where data volumes grow quickly. As more machines and production lines are brought online, MongoDB clusters can be expanded seamlessly, ensuring the UNS remains performant and responsive under increasing load. And by serving as a central repository for historical machine sensor data, a UNS allows manufacturers to analyze long-term patterns, detect anomalies, and anticipate maintenance needs. This approach helps reduce unplanned downtime, optimize maintenance schedules, and ultimately lower operational costs. However, with a UNS acting as a centralized data hub, high availability becomes critical—since any failure could disrupt the entire data ecosystem. MongoDB addresses this with replica sets, which provide ultra-high availability and allow updates without any downtime, eliminating the risk of a single point of failure. Proof point: Building a UNS on MongoDB in the "leafy factory" As shown below, MongoDB’s "Leafy Factory" demo offers a hands-on example of how MongoDB serves as an ideal central repository within a UNS for manufacturing. The demo simulates a realistic industrial environment, combining data from SQL-based ERP and MES systems with real-time MQTT streams from shop floor machines. This setup showcases MongoDB’s ability to consolidate and manage diverse data types into a single, accessible, and continuously updated source of truth. Figure 2. Leafy factory UNS architecture. In the demo, SQL data from a simulated MES is ingested into MongoDB. This includes key production planning, monitoring, and quality metrics—all seamlessly captured using MongoDB’s flexible, document-based JSON format. This structure allows the MES data to remain both organized and accessible for real-time analysis and reporting. Similarly, SQL-based ERP data (like work orders, material tracking, and cost breakdowns) is integrated using a combination of Kafka change streams and the MongoDB Sink connector . The SQL data is captured into Kafka topics using the Debezium connector, with SQL acting as a Kafka producer. The data is then consumed, transformed, and inserted into MongoDB via the MongoDB Sink connector, creating a seamless connection between SQL, Kafka, and MongoDB. This approach keeps ERP data continuously synchronized in MongoDB, demonstrating its reliability as a live source of business-critical information. At the same time, simulated MQTT data streams feed real-time shop floor data into the database, including machine status, quality outputs, and sensor readings like temperature and vibration. MongoDB’s support for real-time ingestion ensures that this data is immediately available, enabling up-to-date machine monitoring and faster response times. Change streams play a central role by enabling real-time data updates across systems. For instance, when a work order is updated in the ERP system, the change is automatically reflected downstream in MES and shop floor views—illustrating MongoDB’s capability for bi-directional data flows and live synchronization within a unified data model. Another critical capability shown in the demo is data contextualization and enrichment. As data enters the UNS, MongoDB enriches it with metadata such as machine ID, operator name, and location according to the ISA95 structure. This enriched model allows for fine-grained analysis and filtering, which is crucial for generating actionable, cross-functional insights across manufacturing, operations, and business teams. Together, the Leafy Factory demo not only validates MongoDB’s technical strengths—like real-time processing, flexible data modeling, and scalable architecture—but also demonstrates how these capabilities come together to support a robust, dynamic, and future-ready Unified Namespace for smart manufacturing. Conclusion A Unified Namespace is essential for modern manufacturing, offering a single, consistent view of data that drives operational efficiency, cross-functional insights, and cost savings. MongoDB, with its flexible schema, real-time data processing, and scalability, is uniquely suited to serve as the central repository in a UNS. The Leafy Factory demo showcases MongoDB’s potential in consolidating ERP, MES, and shop floor data, illustrating how MongoDB can transform manufacturing data management, enabling real-time insights and data-driven decision-making. In choosing MongoDB as the backbone of a UNS, manufacturers gain a powerful data infrastructure that not only meets current operational needs but also scales with future growth, creating an agile, responsive, and insight-driven manufacturing environment. Set up the use case shown in this article using our repository . And, to learn more about MongoDB’s role in the automotive industry, please visit our manufacturing and automotive webpage .
MongoDB 8.0: Improving Performance, Avoiding Regressions
MongoDB 8.0 is the most secure, durable, available and performant version of MongoDB yet: it’s 36% faster in read workloads and 32% faster in mixed read and write workloads than MongoDB 7.0 In addition to benefitting customers, MongoDB 8.0’s performance has also brought significant benefits to our own internal applications, as my colleague Jonathan Brill recently noted in his own blog post . To achieve these improvements, we created an 8.0 multi-disciplinary tiger team focused on performance, and eventually expanded this team into a broad “performance army.” The work by these engineers led to new ideas on how to process simple queries and how writes are replicated. Combined with a new way of measuring performance, we also added a new way to catch the gradual performance loss over time due to many miniscule regressions. Figure 1. MongoDB 8.0 benchmark results. Benchmarking at MongoDB The MongoDB Engineering team runs a set of benchmarks internally to measure MongoDB’s performance. Industry standard benchmarks like YCSB, Linkbench, TPCC, and TPCH are run periodically on a variety of configurations and architectures, and these benchmarks are augmented by custom benchmarks based on customer workloads. By running these benchmarks in our continuous integration system, we ensure that developers do not make commits that are detrimental to performance. For instance, if any commit would regress a benchmark by more than 5% for our most important workloads, we would revert the commit. However, this threshold does not detect regressions of 0.1%, and there are thousands of commits per release (e.g., more than 9000 in MongoDB 8.0). During the release of MongoDB 7.0, we started to take this gradual accumulation of performance loss by tiny regressions of release over release regressions seriously, so we changed the rules of the game. We decided we could not ship MongoDB 7.0 unless it at least matched MongoDB 6.0’s performance on the most important benchmarks. We began investigating regressions and made changes to get performance back. Typically, we use tools like Intel VTune and Linux perf to find regressions across releases. With the release of MongoDB 7.0 approaching, engineers limited the scope of these fixes to reduce their risk to the release. Some proposed fixes were considered too risky. Other fixes didn’t deliver statistically significant performance improvements (Z-score > 1). Unfortunately, MongoDB lost performance with many tiny cuts at a time, and our team realized that it would take many tiny steps to improve it. We got performance back to MongoDB 6.0’s levels, but we weren't quite satisfied. We knew that what we started with MongoDB 7.0 would need to continue into MongoDB 8.0 as a first-tier concern from the start. The MongoDB 8.0 performance push For the release of MongoDB 8.0, we increased the priority of performance over other work and set the goal of matching MongoDB 4.4’s performance at the start. This release was chosen because it switched the default to Write Concern Majority for replica sets. This change in write concern improved MongoDB’s default durability guarantees but came with a loss in performance since the primary needs to wait for a second write on a second machine to be performed. Before the release of MongoDB 5.0, the default write concern was w:1; when a client inserted a document, the response was returned to the client as soon as the write was journaled to the local disk. With write concern majority, the MongoDB server waits for a majority of the nodes to write the document to disk before returning a response. On the primary, MongoDB server inserts the document in the collection, journals this change to disk, sends the change to the secondary where it also journals the document to disk and then inserts the document into its collection. Applying the change immediately to collection on the secondary minimizes the latency for the secondary reads. Figure 2. MongoDB replication writes in MongoDB 7.0. To start our journey to improving the performance of MongoDB 8.0, we created a multi-disciplinary tiger team of 10 people in August 2023, with myself as the leader. The team comprised two performance engineers, three staff engineers, two senior staff engineers, a senior lead, and one technical program manager. Our team of ten worked together to generate ideas, proofs of concept, and experiments. The team’s process was different from our normal process, as we focused on idea experimentation, versus making ideas production-ready. I gave the team free reign to make any changes they thought could help, and I encouraged experimentation—the MongoDB 8.0 performance tiger team was a safe space. This spirit of experimentation was both important and successful, as it led to new ideas that delivered several big improvements (which are highlighted below). We were able to try quick hacks and measure their performance without having to worry about making our work production quality. The big improvements Two of the big improvements we made to MongoDB 8.0 came out of this team: simple finds and replication latency. MongoDB supports a rich query language, but a lot of queries are simple ones to look up a document by a single _id field; the _id field always has a unique index. MongoDB optimized this with a special query plan stage called IDHACK—a query stage optimized to retrieve a single document with a minimal code path. When the tiger team looked at this code, we realized that it was spending a lot of time going through the general purpose query planning code paths before choosing the IDHACK plan. So, a tiger team member did an experiment to bypass the entire query planner and hard code reading from the storage engine. When this delivered significant improvements to the YCSB 100% read, we knew we had a winner. While we knew it could not be committed as-is, it did serve as motivation to improve the IDHACK code path in the server in a new code path called ExpressPlan. The query team took this idea and ran with it by expanding it further for updates, deletes, and other unique index lookups. Here are traces for MongoDB from LLVM XRay and Perfetto . The highlighted red areas show the difference between 7.0 and 8.0 for query planning for a db.coll.find({_id:1}) . Figure 3. Comparing MongoDB 7.0 and MongoDB 8.0. The second big change was how we viewed replicating changes in a cloud database. As explained above, on secondaries, MongoDB journals the writes and then applies it to the collection before acknowledging it back to the primary. During a team brainstorming session, a tiger team member asked, “what if we acknowledge the write as soon as it is journaled, but before we applied it to the collection in-memory?” This reduces the latency of the primary and speeds up writes in a replica set while still maintaining our durability guarantees. A second engineer ran with this idea, prototyped it quickly, and proved that it provided a significant performance boost in a week. Now that the idea was proven to be beneficial, we handed it to the replication team to ship this work. Shipping this change took three months because we had to prove it was correct in the TLA+ models for our replication system and all corner cases before we could ship it. Catching very small regressions To detect small regressions, it is important to have benchmarks with no or low noise. But if the threshold is too small, this creates needless noise and creates a very noisy or flakey test that developers will learn to ignore. Given the noisiness of various metrics such as latency and throughput, a tiger team member came up with the idea of simply counting instructions via Linux perf_event_open syscall. In this test, the code exercises the request processing code to do a simple MongoDB ping command. We run the ping command in a loop on a CI machine a few times and report the average instruction count. This test has a 0.2% tolerance and uses a hard code number. Developers can adjust the threshold up or down as needed, but this test has been a huge success as it allows us to detect regressions without spurious noise. Check out the benchmark on GitHub . From tiger team to (tiger) army A small tiger team can only do so much, and we didn’t want to create a situation in which one team ships features only for another team to clean up their work later. For example, the MongoDB 8.0 performance tiger team focused on a subset of benchmarks, but MongoDB’s performance is measured with dozens of benchmarks. From November 2023 to January 2024, we started implementing all the performance ideas that the tiger team implemented, but more work remained to improve performance. This was when we built a performance “army”—we enlisted 75 people from across the 11 MongoDB server teams to work on performance. In this phase of the project, engineers were charged with idea generation, and fixing performance issues allowed us to accomplish even more than the tiger team; the larger team finished eight performance projects and 140 additional tickets as part of this work. By bringing in additional team members, we were able to draw on ideas from a larger pool of database experts. This led to improvements in a wide variety of areas—like parsing of large $in queries, improvements to query yielding, making config.transactions a clustered collection, reworking locking in count less places, micro optimizations in authorization checks, and a change to a new TCMalloc memory allocator with lower fragmentation. Engineers also looked at improving common code such as namespace string handling, our custom code generation (we found tries helped speed up generated parsers), reducing memory usage, and choosing better data structures in some cases. To give people the time and space they needed to succeed, we gave them dedicated weeks of time to focus on this work in lieu of adding new features. We encouraged both experimentation and for people to go with their gut feelings for small improvements that didn’t appear to move the needle on performance. Because not every experiment succeeded, it was important to encourage each other to keep experimenting and trying in the face of failure. For example, in one failed experiment two engineers tried to use restartable sequences on Linux, but the change failed to deliver the improvements we wanted given their cost and complexity. On the other hand, custom containers and reader writer mutexes did deliver. For my part, the most impactful thing I did during this phase was to be a cheerleader and to support the team’s efforts in our performance push. Being positive and optimistic helped people push forward in their performance work even when ideas didn’t work out. Performance improvements take a village Overall, MongoDB 8.0 was our most successful release ever in terms of performance. Concerted, innovative work by a passionate team—and later an army—of engineers led to new ideas for performance and new ways of thinking. Performance work is neither easy nor straightforward. But by building a sense of community around our performance push, we supported each other and encouraged each other to deliver great performance improvements for MongoDB 8.0. To read more about how MongoDB raised the bar with the release of MongoDB 8.0, check out our Chief Technology Officer Jim Scharf’s blog post . And please visit the MongoDB 8.0 page to learn more about all of its features and upgrades.