MongoDB Blog
Announcements, updates, news, and more
Redefining the Database for AI: Why MongoDB Acquired Voyage AI
February 24, 2025
News
Embracing Open Finance Innovation with MongoDB
The term "open finance" is increasingly a topic of discussion among banks, fintechs, and other financial services providers—and for good reason. Open finance, as the next stage of open banking, expands the scope of data sharing beyond traditional banking to include investments, insurance, pension funds, and more. To deliver these enhanced capabilities, financial service providers need a versatile and flexible data store that can seamlessly manage a wide array of financial data. MongoDB serves as an ideal solution, providing a unified data platform that empowers financial services providers to integrate various data sources, enabling real-time analytics, efficient data retrieval, and scalability. These capabilities are pivotal in enhancing customer experiences, providing users with a comprehensive view of their finances, and empowering them with greater visibility and control over their own data. By adopting MongoDB, financial services can seamlessly adapt to the growing demands of open finance and deliver innovative, data-driven solutions. Open finance's past and future As highlighted in a study conducted by the Cambridge Centre for Alternative Finance 1 , the terms 'open banking' and 'open finance' vary globally. Acknowledging these differences, we'll focus on the model displayed in Figure 1 due to its widespread adoption and relevance in our study. Figure 1. The three waves of innovation in financial services. The development of open finance started with open banking, which intended for banks to promote innovation by allowing customers to share their financial data with third-party service providers (TPP) and allow those TPP—fintech and techfin companies—to initiate transactions on their behalf solely in the context of payments. This proved to be an effective way to promote innovation and thus led to a broader spectrum of financial products adding loans, mortgages, savings, pensions, insurance, investments, and more. Leading to this new directive, commonly referred to as: open finance. If we take a step further—regardless of its final implementation—a third development called open data suggests sharing data beyond the traditional boundaries of the financial services industry (FSI), exponentially increasing the potential for financial services by moving into cross-sector offerings, positioning FSI as a horizontal industry rather than an independent vertical as it was previously known. Who and what plays a role in open finance? Among the different actors across open finance, the most important are: Consumers: End-users empowered to grant or revoke consent to share their data primarily through digital channels. Data holders: These are mainly financial services companies, and thereby consumer data custodians. They are responsible for controlling the data flow across the different third-party providers (TPPs). Data users: Data users are common third-party providers offering their services based on consumers’ data (upon request/consent). Connectivity providers: Trusted intermediaries that facilitate data flow, also known as TSPs in the EU and UK, and Account Aggregators in India. Regulatory authorities: Set standards, oversee processes, and may intervene in open finance implementation. They may vary according to the governance type. The interactions between all these different parties define the pillars for open finance functioning: Technology: Ensures secure data storage and the exposure-consumption of services. Standards: Establishes frameworks for data interchange schemas. Regulations and enforceability: Encompasses security policies and data access controls. Participation and trust: Enables traceability and reliability within a regulated ecosystem. Figure 2. High-level explanation of data sharing in open finance. Drivers behind open finance: Adoption, impact, and compliance Open finance seeks to stimulate innovation by promoting competition, safeguarding consumer privacy, and ensuring market stability—ultimately leading to economic growth. Additionally, it has the potential to provide financial institutions with greater access to data and better insights into consumers' preferences, allowing them to tailor their offerings and to enhance user experiences. This data sharing between the ecosystem’s participants requires a regulated set of rules to ensure data protection, security, and compliance according to each jurisdiction. As seen in Figure 3 below, there are two broad drivers of open finance adoption: regulation-led and market-driven adoption. Whether organizations adopt open finance depends on factors like market dynamics, digital readiness, and regulatory environment. Figure 3. An illustrative example of open finance ecosystem maturity. Even though there is not one single, official legal framework specifying how to comply with open finance, countries around the world have crafted their own specific set of norms as guiding principles. Recent market research reports reveal how several countries are already implementing open finance solutions, each coming from different starting points, with their own economic goals and policy objectives. In Europe, the Revised Payment Services Directive (PSD2) combined with the General Data Protection Regulation (GDPR) form the cornerstone of the regulatory framework. The European Commission published a proposal in June 2023 for a regulation on a framework for Financial Data Access 2 (FiDA) set to go live in 2027. 3 In the UK, open finance emerged from the need to address the market power held by a few dominant banks. In India, open finance emerged as a solution to promote financial inclusion by enabling identity verification for accounts opening through the national ID system. The aim is to create a single European data space – a genuine single market for data, open to data from across the world – where personal as well as non-personal data, including sensitive business data, are secure and businesses also have easy access to an almost infinite amount of high-quality industrial data, boosting growth and creating value, while minimising the human carbon and environmental footprint. 4 Build vs. buy: Choosing the right open finance strategy One of the biggest strategic decisions financial institutions face is whether to build their own open finance solutions in-house or buy from third-party open finance service providers. Both approaches come with trade-offs: Building in-house provides full ownership, flexibility, and control over security and compliance. While it requires significant investment in infrastructure, talent, and ongoing maintenance, it ensures lower total cost of ownership (TCO) in the long run, avoids vendor lock-in, and offers complete traceability—reducing reliance on external providers and eliminating “black box” risks. Institutions that build their own solutions also benefit from customization to fit specific business needs and evolving regulations. Buying from a provider accelerates time to market and reduces development costs while ensuring compliance with industry standards. However, it introduces potential challenges such as vendor lock-in, limited customization, and integration complexities with existing systems. For financial institutions that prioritize long-term cost efficiency, compliance control, and adaptability, the building approach offers a strategic advantage—though it comes with its own set of challenges. What are the challenges and why do they matter? As open finance continues to evolve, it brings significant opportunities for innovation—but also introduces key challenges that financial institutions and fintech companies must navigate. These challenges impact efficiency, security, and compliance, ultimately influencing how quickly new financial products and services can reach the market. 1. Integration of data from various sources Open finance relies on aggregating data from multiple institutions, each with different systems, APIs, and data formats. This complexity leads to operational inefficiencies, increased latency, and higher costs associated with data processing and infrastructure maintenance. Without seamless integration, financial services struggle to provide real-time insights and a frictionless user experience. 2. Diverse data types Financial data comes in various formats—structured, semi-structured, and unstructured—which creates integration challenges. Many legacy systems operate with rigid schemas that don’t adapt well to evolving data needs, making it difficult to manage new financial products, regulations, and customer demands. Without flexible data structures, innovation is slowed, and interoperability between systems becomes a persistent issue. 3. Data security With open finance, vast amounts of sensitive customer data are shared across multiple platforms, increasing the risk of breaches and cyberattacks. A single vulnerability in the ecosystem can lead to data leaks, fraud, and identity theft, eroding customer trust. Security vulnerabilities have financial consequences and can result in legal examination and long-term reputational damage. 4. Regulatory compliance Navigating a complex and evolving regulatory landscape is a major challenge for open finance players. Compliance with data protection laws, financial regulations, and industry standards—such as GDPR or PSD2—requires constant updates to systems and processes. Failure to comply can lead to legal penalties, substantial fines, and loss of credibility—making it difficult for institutions to operate confidently in a global financial ecosystem. These challenges directly impact the ability of financial institutions to innovate and launch new products quickly. Integration issues, security concerns, and regulatory complexities contribute to longer development cycles, operational inefficiencies, and increased costs—ultimately slowing the time to market for new financial services. In a highly competitive industry where speed and adaptability are critical, overcoming these challenges is essential for success in open finance. MongoDB as the open finance data store To overcome open finance’s challenges, a flexible, scalable, secure, and high-performing data store is required. MongoDB is an ideal solution, as it offers a modern, developer-friendly data platform that accelerates innovation while meeting the critical demands of financial applications. Seamless integration with RESTful JSON APIs According to OpenID’s 2022 research , most open finance ecosystems adopt RESTful JSON APIs as the standard for data exchange, ensuring interoperability across financial institutions, third-party providers, and regulatory bodies. MongoDB’s document-based model natively supports JSON, making it the perfect backend for open banking APIs. This enables financial institutions to ingest, store, and process API data efficiently while ensuring compatibility with existing and emerging industry standards. Flexible data model for seamless integration Open finance relies on diverse data types from multiple sources, each with different schemas. Traditional relational databases require rigid schema migrations, often causing downtime and disrupting high-availability services. MongoDB's document-based model—with its flexible schema—offers an easy, intuitive, and developer-friendly solution that eliminates bottlenecks, allowing financial institutions to adapt data structures dynamically, all without costly migrations or downtime. This ensures seamless integration of structured, semi-structured, and unstructured data, increasing productivity and performance while being cost-effective, enables faster iteration, reduced complexity, and continuous scalability. Enterprise-grade security and compliance Security and compliance are non-negotiable requirements in open finance, where financial data must be protected against breaches and unauthorized access. MongoDB provides built-in security controls, including encryption, role-based access controls, and auditing. It seamlessly integrates with existing security protocols and compliance standards, ensuring adherence to regulations such as GDPR and PSD2. MongoDB also enforces privileged access controls and continuous monitoring to safeguard sensitive data, as outlined in the MongoDB Trust Center . Reliability and transactional consistency Financial applications demand zero downtime and high availability, especially when processing transactions and real-time financial data. MongoDB’s replica sets ensure continuous availability, while its support for ACID transactions guarantees data integrity and consistency—critical for handling sensitive financial operations such as payments, lending, and regulatory reporting. The future of open finance The evolution of open finance is reshaping the financial industry, enabling seamless data-sharing while introducing new challenges in security, compliance, and interoperability. As financial institutions, fintechs, and regulators navigate this shift, the focus remains on balancing innovation with risk management to build a more inclusive and efficient financial ecosystem. For organizations looking to stay ahead in this landscape, choosing the right technology stack is crucial. MongoDB provides the flexibility, scalability, and security needed to power the next generation of open finance applications—helping financial institutions accelerate innovation while ensuring compliance and data integrity. In Part 2 of our look at open finance, we’ll explore a demo from the Industry Solutions team that leverages MongoDB to implement an open finance strategy that enhances customer experience, streamlines operations, and drives financial accessibility. Stay tuned! Head over to our GitHub repo to view the demo. Visit our solutions page to learn more about how MongoDB can support financial services. 1 CCAF, The Global State of Open Banking and Open Finance (Cambridge: Cambridge Centre for Alternative Finance, Cambridge Judge Business School, University of Cambridge, 2024). 2 “The Financial Data Access (FiDA) Regulation,” financial-data-access.com, 2024, https://www.financial-data-access.com/ 3 Maout, Thierry, “What is Financial Data Access (FiDA), and how to get ready?”, July 16th, 2024, https://www.didomi.io/blog/financial-data-access-fida?315c2b35_page=2 4 European Commission (2020), COMMUNICATION FROM THE COMMISSION TO THE EUROPEAN PARLIAMENT, THE COUNCIL, THE EUROPEAN ECONOMIC AND SOCIAL COMMITTEE AND THE COMMITTEE OF THE REGIONS, EUR-Lex.
MongoDB Atlas Expands Cloud Availability to Mexico
¡MongoDB ama a Mexico! The company’s second-largest market in Latin America, Mexico is also one of MongoDB’s top 20 markets globally. With rapid customer adoption across the country, we’re doubling down on our commitment to Mexico—investing in the resources and support our customers need to build and scale with MongoDB. That’s why I’m so thrilled to announce that MongoDB Atlas , MongoDB’s modern, cloud-native database, is now available on Amazon Web Services (AWS), Google Cloud, and Microsoft Azure cloud infrastructure regions in Mexico. MongoDB Atlas is the most widely available data platform in the world and the only true multi-cloud database on the market. With availability in over 125 cloud regions globally, customers can deploy applications on their choice of cloud, across cloud regions, or across multiple cloud providers, which provides them with the flexibility to move data seamlessly between cloud providers and to utilize the unique services of each cloud provider simultaneously. Innovating faster with MongoDB Atlas Until now, customers in Mexico have used MongoDB Enterprise Advanced for on-premise deployments or they’ve run Atlas deployments on cloud infrastructure regions outside of Mexico. But for customers in highly regulated industries—or for those with highly sensitive workloads who are required to keep their data in-country—modernizing their applications in the cloud with the three major cloud providers wasn’t an option. MongoDB Atlas streamlines and secures enterprises’ data infrastructure by integrating a globally distributed database with built-in search, analytics, and AI-ready capabilities. By eliminating the need for single-purpose databases and complex data pipelines, Atlas will help organizations in Mexico modernize faster, simplify operations, and stay competitive in an AI-driven world. Bottom line: MongoDB was built for change, and its flexibility empowers businesses to innovate with next-generation technologies like AI at the breakneck speed of the market. Now that MongoDB Atlas is available on all three major cloud providers’ local infrastructure regions, more of our customers across Mexico can begin modernizing enterprise-grade applications in the cloud with confidence. Around the world, tens of thousands of customers are innovating faster in the cloud thanks to MongoDB Atlas. For instance, Bendigo and Adelaide Bank recently partnered with MongoDB to modernize its core banking technology with MongoDB Atlas as the keystone of an ambitious application modernization initiative. As part of the initiative, the bank reduced the development time required to migrate a core banking application off of a legacy relational database to MongoDB Atlas by up to 90% and at one-tenth the cost of a traditional legacy-to-cloud migration. Investing in Mexico In recent years, MongoDB has seen significant customer growth across Mexico. Today, more than 35,000 developers in Mexico list MongoDB as a skill on LinkedIn, and MongoDB has seen meaningful adoption across the financial services, retail, telecommunications, and software development sectors. Our team has been dedicated to helping these customers modernize their applications and accelerate their digital transformation. A key driver of this success is MongoDB’s deep partnerships with AWS, Google Cloud, and Microsoft Azure. We continue to expand our integrations with services like Amazon Bedrock, Gemini Code Assist, and Azure AI Foundry that empower Mexican customers to build intelligent applications more quickly and with less friction, while our recognition as a Partner of the Year by each of these cloud providers is a testament to the impact of our collaboration and the success of our joint customers. Since opening MongoDB’s Mexico City office in 2016, we’ve expanded rapidly, and have hired approximately 50 employees over the past three years to support rising demand and enhance every stage of the customer journey. As our presence has grown, Mexico has become MongoDB’s corporate headquarters for all Spanish-speaking countries in LATAM. Notably, it is now our second-largest market in the region, with a total addressable market exceeding that of our third, fourth, and fifth-largest LATAM markets combined. To further support our expanding customer base, we are committed to continued investment in our local team through 2025. Mexico boasts an exceptional talent pool, and we are actively growing our organization across key areas, including sales, customer success, partners, solutions architecture, and professional services. With this expansion, we’re ensuring that businesses in Mexico have not only the most powerful tools to innovate but also the local expertise and partnerships to accelerate their success with confidence. If you’re looking for your next adventure, take a look at our open roles in Mexico. Connect with us This spring, MongoDB.local is coming to Mexico City! MongoDB.local is a global series of in-person events, bringing together developers, IT professionals, and technology enthusiasts to explore the latest in MongoDB. Through expert-led talks, hands-on workshops, and networking opportunities, you’ll gain valuable insights and practical skills—all in an engaging and collaborative environment. Join us in Mexico City on May 15 to connect with the community and take your MongoDB expertise to the next level.
Innovating with MongoDB | Customer Successes, March 2025
Hello and welcome! This is the first installment of a new bi-monthly blog series showcasing how companies around the world are using MongoDB to tackle mission-critical challenges. As the leading database for modern applications, MongoDB empowers thousands of organizations to harness the power of their data and to drive creativity and efficiency across industries. This series will shine a light on some of those amazing stories. From nimble startups to large enterprises, our customers are transforming data management, analytics, and application development with MongoDB's flexible schema, scalability, and robust cloud services. What do I mean? Picture retailers like Rent the Runway improving customer experiences with real-time analytics, fintech companies such as Koibanx speeding up and securing transaction processes, and healthcare companies like Novo Nordisk optimizing the path to regulatory approvals. With MongoDB, every developer and organization can fully tap into the potential of their most valuable resource: their data. So please read on—and stay tuned for more in this blog series!—to learn about the ingenuity of the MongoDB customer community, and how they’re pushing the boundaries of what's possible. Lombard Odier Lombard Odier , a Swiss bank with a legacy dating back to 1796, transformed its application architecture with MongoDB to stay at the forefront of financial innovation. Confronted with the challenge of modernizing its systems amidst rapid digital and AI advancements, the bank leveraged MongoDB’s Application Modernization Factory and generative AI to streamline its application upgrades. This initiative resulted in up to 60x faster migration of simple code and slashed regression testing from three days to just three hours. By transitioning over 250 applications to MongoDB, including its pivotal portfolio management system, Lombard Odier significantly reduced technical complexity and empowered its developers to focus on next-generation technologies. SonyLIV SonyLIV faced challenges with its over-the-top (OTT) video-streaming platform. Their legacy relational database had poor searchability, complex maintenance, and slow content updates. Critically, it lacked the scalability necessary to support 1.6 million simultaneous users. To power their new CMS— ‘Blitz’—SonyLIV selected MongoDB Atlas’s flexible document model to improve performance and lower search query latency by 98%. Collaborating with MongoDB Professional Services , SonyLIV optimized API latency using MongoDB Atlas Search and Atlas Online Archive , effectively managing over 500,000 content items and real-time updates. With their new high-performing, modern solution in place, SonyLIV can now deliver flawless customer experiences to the world, faster. Swisscom Swisscom , Switzerland's leading telecom and IT service provider, harnessed MongoDB to enrich its banking sector insights with AI. Faced with the challenge of streamlining access to its extensive library of over 3,500 documents, Swisscom utilized MongoDB Atlas and MongoDB Atlas Vector Search capabilities to transform unstructured data into precise, relevant content summaries in seconds. In just four months, Swisscom launched a production-ready platform with improved relevance, concrete answers, and transparency. The project sets a new standard in Swiss banking, and showcases Swisscom's commitment to driving the digital future with advanced AI solutions. Victoria’s Secret Victoria's Secret’s e-commerce platform processes thousands of transactions daily across over 2.5 billion documents on hundreds of on-premises databases. Experiencing high costs and operational constraints with its monolithic architecture, the retailer initially adopted CouchDB but faced challenges like data duplication and limited functionality. In 2023, Victoria's Secret migrated to MongoDB Atlas on Azure , achieving zero downtime while optimizing performance and scalability. Over four months, they successfully migrated more than four terabytes of data across 200 databases, reducing CPU core usage by 75% and achieving a 240% improvement in API performance. The move to MongoDB also allowed the retailer to introduce additional products, like MongoDB Atlas Vector Search, resulting in significant operational efficiencies and cost savings. Video spotlight Before you go, be sure to watch one of our recent customer videos featuring the Danish pharmaceutical giant, Novo Nordisk . Discover how Novo Nordisk leveraged MongoDB and GenAI to reduce the time it takes to produce a Clinical Study Report (CSR) from 12 weeks to 10 minutes.. Want to get inspired by your peers and discover all the ways we empower businesses to innovate for the future? Visit our Customer Success Stories hub to see why these customers, and so many more, build modern applications with MongoDB.
Modernizing Telecom Legacy Applications with MongoDB
The telecommunications industry is currently undergoing a profound transformation, fueled by innovations in 5G networks, the growth of Internet of Things applications, and the rapid rise of AI. To capitalize on these technologies, companies must effectively handle increasing volumes of unstructured data, which now represents up to 90% of all information, while also developing modern applications that are flexible, high-performance, and scalable. However, the telecommunications industry's traditional reliance on relational databases such as PostgreSQL presents a challenge to modernization. Their rigid structures limit adaptability and can lead to decreased performance as table complexity grows. With this in mind, this blog post explores how telecom companies can modernize their legacy applications by leveraging MongoDB’s modern database and its document model. With MongoDB, telecom companies can take advantage of the latest industry innovations while freeing their developers from the burdens of maintaining legacy systems. Navigating legacy system challenges Legacy modernization refers to the process of updating a company’s IT infrastructure to align it with the latest technologies and workflows, and ultimately advancing and securing strategic business goals. For telecom companies, this modernization involves overcoming the limitations of their legacy systems, which hinder adjustment to changing market conditions that demand greater system scalability and availability to run real-time operations. The main drawbacks of legacy technologies like relational databases stem from their design, which wasn’t built to support the data processing capabilities required for modern telecom services. These limitations, as illustrated in Figure 1 below, include rigid data schemas, difficulty handling complex data formats, limited scaling ability, and higher operational costs for maintenance. Figure 1. The limitations of legacy systems. Expanding on these limitations, relational databases depend on a predefined schema, which becomes difficult to modify once established, as changes entail extensive restructuring efforts. In telecommunications, handling growing data volumes from connected devices and 5G networks can rapidly become burdensome and costly due to frequent CPU, storage, and RAM upgrades. Over time, technology lock-in can further escalate costs by hindering the transition to alternative solutions. Altogether, these factors hold back modernization efforts urging telecoms to transform their legacy systems to newer technologies. To overcome these challenges, telecom companies are replacing these legacy systems with modern applications that effectively provide them with greater scalability, enhanced security, and high availability, as shown in Figure 2. However, achieving this transition can be a daunting task for some organizations due to the complexity of current systems, a lack of internal technical expertise, and the hurdles of avoiding downtime. Therefore, before transforming their outdated systems, telecom companies must carefully select the appropriate technologies and formulate a modernization strategy to facilitate this transition. Figure 2. Characteristics of modern applications. Getting onboard with MongoDB Enter MongoDB. The company’s document-oriented database offers a flexible data model that processes any information format, easily adapting to specific application requirements. MongoDB Atlas —MongoDB’s unified, modern database—delivers a robust cloud environment that efficiently manages growing data volumes through its distributed architecture, ensuring seamless connectivity and enhanced performance. Moreover, as telecom providers prioritize cybersecurity and innovation, MongoDB includes robust security measures—comprising encryption, authentication, authorization, and auditing—to effectively protect sensitive information and ensure regulatory compliance. Additionally, leveraging MongoDB’s document model with built-in Atlas services like Vector Search , Atlas Charts , and Stream Processing allows telecommunications organizations to streamline advanced industry cases, including single customer view, AI integrations, and real-time analytics. Figure 3. Core MongoDB modernization features for Modernization. Recognizing these benefits, leading telecom companies like Nokia , Swisscom , and Vodafone have successfully modernized their applications with MongoDB. However, selecting the right technology is only part of the modernization process. In order to ensure a successful and effective modernization project, organizations should establish a comprehensive modernization strategy. This process typically follows one of three following paths: Data-driven modernization: this approach transfers all data from the legacy system to the new environment and then migrates applications. Application-driven modernization (all-or-nothing): this approach executes all reads and writes for new applications in the new data environment from the start, but leaves the business to decide when to retire existing legacy applications. Iterative modernization (one-step-at-a-time): this approach blends the previous paths, starting with the modernization of the least complex applications and incrementally moving forward into more complex applications. Read this customer story to learn more about telecoms migrating to MongoDB. With this overview complete, let's dive into the migration process by examining the iterative modernization of a telecom billing system. Modernizing a telecom billing system Telecom billing systems often consist of siloed application stacks segmented by product lines like mobile, cable, and streaming services. This segmentation leads to inefficiencies and overly complex architectures, highlighting the need to simplify these structures. With this in mind, imagine a telecom company that has decided to modernize its entire billing system to boost performance and reduce complexity. In the initial stage, telecom developers can assess the scope of the modernization project, scoring individual applications based on technical sustainability and organizational priorities. Applications with high scores undergo further analysis to estimate the re-platforming effort required. Later on, a cross-functional team selects the first component to migrate to MongoDB, initiating the billing system modernization. This journey then follows the steps outlined in Figure 4: Figure 4. The modernization process. First, developers analyze legacy systems by examining the codebase and the underlying architecture of the chosen billing system. Then, developers create end-to-end tests to ensure the application functions correctly when deployed. Later, developers design an architecture that incorporates managerial expectations of the desired application. Next, developers rewrite and recode the legacy application to align with the document model and develop APIs for MongoDB interaction. Following this, developers conduct user tests to identify and resolve any existing application bugs. Finally, developers migrate and deploy the modernized application in MongoDB, ensuring full functionality. Throughout this process, developers can leverage MongoDB Relational Migrator to streamline the transition. Relational Migrator helps developers with data mapping and modeling, SQL object conversion, application code generation, and data migration—corresponding to steps three, four, and five. Additionally, telecom companies can accelerate modernization initiatives by leveraging MongoDB Professional Services for dedicated, tailored end-to-end migration support. Our experts work closely with you to provide customized assistance, from targeted technical support and development resources to strategic guidance throughout the entire project. Building on this initial project, telecom companies can progressively address more complex applications, refining their approach to support a long-term modernization strategy. Next steps By revamping legacy applications with MongoDB, telecom companies can improve their operations and gain a competitive edge with advanced technology. This shift allows telcos to apply the latest innovations and free developers from the burdens of maintaining legacy systems. Start your journey to migrate core telecom applications to MongoDB Atlas, by visiting our telecommunications solutions page to learn more. If you would like to discover how to upgrade your TELCO legacy systems with MongoDB, discover how to start with the following resources: Visit our professional services to learn more about MongoDB Consulting YouTube: Relational Migrator Explained in 3 minutes White paper: Unleash Telco Transformation with an Operational Data Layer White paper: Modernization: What’s Taking So Long?
Building Gen AI with MongoDB & AI Partners | February 2025
February was big for MongoDB—and, more importantly, for anyone looking to build AI applications that deliver highly accurate, relevant information (in other words, for everyone building AI apps). MongoDB announced the acquisition of Voyage AI , a pioneer in state-of-the-art embedding and reranking models that power next-generation AI applications. Because generative AI is by nature probabilistic, models can “hallucinate”, and generate false or misleading information. This can lead to serious risks, especially in cases or industries (e.g., financial services) where accurate information is paramount. To address this, organizations building AI apps need high-quality retrieval; they need to trust that the most relevant information is extracted from their data with precision. Voyage AI’s advanced embedding and reranking models enable applications to extract meaning from highly specialized and domain-specific text and unstructured data. With roots at Stanford and MIT, Voyage AI’s world-class team is trusted by AI innovators like Anthropic, LangChain, Harvey, and Replit. Integrating Voyage AI’s technology with MongoDB will enable organizations to easily build trustworthy, AI-powered applications by offering highly accurate and relevant information retrieval deeply integrated with operational data. For more, check out MongoDB CEO Dev Ittycheria’s blog post about Voyage AI , and what this means for developers and businesses (in short, delivering high-quality results at scale). Onward! P.S. If you’re in Vegas for HumanX this week, stop by booth 412 to say hi to MongoDB! Welcoming new AI and tech partners The Voyage AI news was hardly the only exciting development last month. In February 2025, MongoDB welcomed three new AI and tech partners that offer product integrations with MongoDB. Read on to learn more about each great new partner! CopilotKit Seattle-based CopilotKit provides open source infrastructure for in-app AI copilots. CopilotKit helps organizations build production-ready copilots and agents effortlessly. “We’re excited to be partnering with MongoDB to help companies build best-in-class copilots that leverage RAG & take action based on internal data,” said Uli Barkai, Co-Founder and Chief Marketing Officer at CopilotKit. “MongoDB made it dead simple to build a scalable vector database with operational data. This collaboration enables developers to easily ship production-grade RAG applications.” Varonis Varonis is the leader in data security, protecting data wherever it lives—across SaaS, IaaS, and hybrid cloud environments. Varonis’ cloud-native Data Security Platform continuously discovers and classifies critical data, removes exposures, and detects advanced threats with AI-powered automation. “Varonis’s mission is to protect data wherever it lives,” said David Bass, Executive Vice President of Engineering and Chief Technology Officer at Varonis. “We are thrilled to further advance our mission by offering AI-powered data security and compliance for MongoDB, the database of choice for high-performance application and AI development. With this integration, joint customers can automatically discover and classify sensitive data, detect abnormal activities, secure AI data pipelines, and prevent data leaks.” Xlrt Xlrt is an automated insight-generation platform that enables financial institutions to create innovative financial credit products at scale by simplifying the financial spreading process. “We are excited to partner with MongoDB Atlas to transform AI-driven financial workflows,” said Rupesh Chaudhuri, Chief Operating Officer and Co-Founder of Xlrt. “XLRT.ai leverages agentic AI, combining graph-based contextualization, vector search, and LLMs to redefine data-driven decision-making. With MongoDB's robust NoSQL and vector search capabilities, we’re delivering unparalleled efficiency, accuracy, and scalability in automating financial processes.” To learn more about building AI-powered apps with MongoDB, check out our AI Learning Hub and stop by our Partner Ecosystem Catalog to read about our integrations with MongoDB’s ever-evolving AI partner ecosystem. And visit the MongoDB AI Applications Program (MAAP) page to learn how MongoDB and the MAAP ecosystem helps organizations build applications with advanced AI capabilities.
ORiGAMi: A Machine Learning Architecture for the Document Model
The document model has proven to be the optimal paradigm for modern application schemas. At MongoDB, we've long understood that semi-structured data formats like JSON offer superior expressiveness compared to traditional tabular and relational representations. Their flexible schema accommodates dynamic and nested data structures, naturally representing complex relationships between data entities. However, the machine learning (ML) community has faced persistent challenges when working with semi-structured formats. Traditional ML algorithms, as implemented in popular libraries like scikit-learn and pandas , operate on the assumption of fixed-dimensional tabular data consisting of rows and columns. This fundamental mismatch forces data scientists to manually convert JSON documents into tabular form—a time-consuming process that requires significant domain expertise. Recent advances in natural language processing (NLP) demonstrate the power of Transformers in learning from unstructured data but their application to semi-structured data has been under-studied. To bridge this gap, MongoDB's ML research group has developed a novel Transformer-based architecture designed for supervised learning on semi-structured data (e.g., JSON data in a document model database). We call this new architecture ORiGAMi (Object Representation through Generative, Autoregressive Modelling), and we're excited to make it available to the community at github.com/mongodb-labs/origami . It includes components that make training a Transformer model feasible on datasets entailing as few as 200 labeled samples. By combining this data efficiency with the flexibility of Transformers, ORiGAMi enables prediction directly from semi-structured documents, without the cumbersome flattening and manual feature extraction required for tabular data representation. You can read more about our model on arXiv . Technical innovation The key insight behind ORiGAMi lies in its tokenization strategy: documents are transformed into sequences of key-value pairs and special structural tokens that encode nested types like arrays and subdocuments: These token sequences serve as input to the Transformer model trained to predict the next token given a portion of the document, similar to how large language models (LLMs) are trained on text tokens. What’s more, our modifications to the standard Transformer architecture include guardrails to ensure that the model only generates valid, well-formed documents, and a novel position encoding strategy that respects the order invariance of key/value pairs in JSON. These modifications also allow for much smaller models compared to LLMs, which can thus be trained on consumer hardware in minutes to hours depending on dataset size and complexity, versus days to weeks for LLMs. By reformulating classification as a next-token prediction task, ORiGAMi can predict any field within a document, including complex types like arrays and nested subdocuments. This unified approach eliminates the need for separate models or preprocessing pipelines for different prediction tasks. Example use case Our initial focus has been supervised learning: training models from labeled data to make predictions on unseen documents. Let's explore a practical example of user segmentation. Consider a collection where each document represents a user profile, containing both simple fields and complex nested structures: { "_id": "user_7842", "email": "sarah.chen@example.com", "signup_date": "2024-01-15", "device_history": [ { "device": "mobile_ios", "first_seen": "2024-01-15", "last_seen": "2024-02-11" }, { "device": "desktop_chrome", "first_seen": "2024-01-16", "last_seen": "2024-02-10" } ], "subscription": { "plan": "pro", "billing_cycle": "annual", "features_used": ["analytics", "api_access", "team_sharing"], "usage_metrics": { "storage_gb": 45.2, "api_calls_per_day": 1250, "active_projects": 8 } }, "user_segment": "enterprise_power_user" // <-- target field } Suppose you want to automatically classify users into segments like "enterprise_power_user", "smb_growth", or "early_stage_startup" based on their behavior and characteristics. Some documents in your collection already have correct labels, perhaps assigned through manual analysis or customer interviews. Traditional ML approaches would require flattening this rich document structure, leading to very sparse tables and potentially losing important hierarchical relationships. With ORiGAMi, you can: Train directly on the raw documents with existing labels Preserve the full context of nested structures and arrays Make predictions for the "user_segment" field on new users immediately after signup Update predictions as user behavior evolves without rebuilding feature pipelines Getting started with ORiGAMi We're excited to be open-sourcing ORiGAMi ( github.com/mongodb-labs/origami ) and you can read more about our model on arXiv . We've also included a command-line interface that lets users make predictions without writing any code. Training a model is as simple as pointing ORiGAMi to your MongoDB collection: origami train <mongo-uri> -d app -c users Once trained, you can generate predictions and seamlessly integrate them back into your MongoDB workflow. For example, to predict user segments for new signups (from the analytics.signups collection ) and write the resulting predictions back to MongoDB to an analytics.predicted collection: origami predict <mongo-uri> -d analytics -c signups --target user_segment --json | mongoimport -d analytics -c predicted For those looking to dive deeper, we've also included several Jupyter notebooks in the repository that demonstrate advanced features and customization options. Model performance can be improved by adjusting the hyperparameters. We're just scratching the surface of what's possible with document-native machine learning, and have many more use cases in mind. We invite you to explore the repository, contribute to the project, and share how you use ORiGAMi to solve real-world problems. Head over to the ORiGAMi github repo , play around with it, and tell us about new ways of applying it and problems it’s well-suited to solving.
ZEE5: A Masterclass in Migrating Microservices to MongoDB Atlas
ZEE5 is a leading Indian over-the-top (OTT) video-streaming platform that delivers streamed content via Internet-connected devices. The platform offers a wide variety of content—movies, TV shows, web series, and original programming—across multiple genres and languages. Owned by Zee Entertainment Enterprises Limited , ZEE5 produces over 260 hours of content daily, with a monthly active user base of more than 119.5 million users across 190 countries. ZEE5’s operations and customer satisfaction are dependent on its backend infrastructure being robust and scalable to handle immense traffic and complex workflows. In order to future-proof its infrastructure and to maintain its competitive edge, the company needed to streamline operations and enhance its database management capabilities. This included the migration of its entire OTT platform, including a total of 100+ microservices and 80+ databases to Google Cloud. Pramod Prakash, Senior Vice President of Engineering at ZEE5, was on the stage of MongoDB.local Bangalore in 2024 . He shared insights into how ZEE5 managed this migration without hindering performance or disrupting its services. “It was a massive project which required a very carefully orchestrated migration plan,” said Prakash. Massive migration, zero downtime: Challenge accepted ZEE5’s team embarked on an ambitious journey to migrate a total of 40+ microservices (out of its 100+ microservices) to MongoDB Atlas . These were previously running on the Community Edition of MongoDB and on other NoSQL databases. One of the challenges of this migration was to ensure continuous data flow for the platform’s 119.5 million streaming users. To do so, Prakash and his team created multiple environments using a change data capture tool . This ensured continuous replication of data so the user experience would not be impacted. “We had to build four environments: dev, QA [Quality Assurance], UAT [User Acceptance Testing], and production,” explained Prakash. “We needed to keep testing and verifying each environment, and then finally enter the production phase when we migrated the data and moved the traffic.” The approach involved migrating production data twice: first for testing and then for the final cutover. This was to minimize any data loss. ZEE5 used MongoDB Atlas’ integrated tools mongosync and mongomirror . The tools helped achieve an essential goal: avoiding any downtime. “We migrated this entire mammoth application with zero downtime!” said Prakash. “We have not stopped ZEE5’s operations at all.” “The second important thing is the performance: you want to be 100% sure that the entire scale and peak traffic will work seamlessly within the new cloud environment,” added Prakash. ZEE5 relied on MongoDB Professional Services (PS)’s support. The PS team helped architect and plan the entire migration strategy. They also accompanied Prakash’s team step by step to ensure there would be no unexpected disruptions. The production environment was built and tested rigorously before the final migration to ensure seamless performance at peak traffic levels. “We iterated until we were 100% sure that the new environment was ready to take up ZEE5’s peak traffic. Functionally, it was all perfect,” said Prakash. The power of the Atlas platform According to Prakash, the power of MongoDB Atlas lies in the fact that it offers a fully managed platform. “There is no maintenance overhead at all,” he said. “All upgrades happen automatically without any downtime. We are also leveraging auto-scaling capabilities and point-in-time recovery.” All of this enables efficient handling of varying traffic loads without manual intervention. Additionally, data recovery capabilities are enhanced, and most importantly, the engineering team can prioritise application development rather than operational maintenance. As of February 2025, MongoDB Atlas supports a total of seven key use cases at ZEE5: payments, subscriptions, plans and coupons, video engineering, Zee Music (users’ preferences and playlists), content metadata, and the platform’s communication engine (SMS and email notifications). Looking ahead, ZEE5 is working on more use cases powered by MongoDB. For example, the company is looking to completely migrate their master data source for content metadata to MongoDB Atlas. ZEE5 is also considering relying on MongoDB Atlas to support and enhance its search and recommendations capabilities. Interested in learning how MongoDB is powering other companies applications? Head over to our customer case studies hub to read the latest stories. Visit our product page to learn more about MongoDB Atlas .
Debunking MongoDB Myths: Security, Scale, and Performance
MongoDB has come a long way since its founding in 2007. Many people first encountered MongoDB during its early years. They formed opinions about the database based on impressions from 2012 to 2014. However, much has changed since then. Over the past eleven years, MongoDB has made significant strides. Foremost being the launch of MongoDB Atlas in 2016. It has placed a substantial focus on improving the four critical areas that matter most to businesses and developers alike: security, durability, availability, and performance. Security: Protecting sensitive data from unauthorized access and ensuring regulatory compliance. Durability: Ensuring data remains intact and reliable, even during system failures or unexpected disruptions. Availability: Minimizing downtime and maintaining system operation, no matter what happens. Performance: Delivering fast, consistent application response times and scaling efficiently to meet growing demand. These advancements have earned the trust of some of the world’s largest enterprises, including Toyota , Cisco , Wells Fargo , Bosch , and Verizon . Yet despite this progress, outdated myths regarding MongoDB persist—particularly in these four foundational areas. In this blog, we will tackle those misconceptions head on and set the record straight about MongoDB’s security, durability, availability, and performance. Let’s dive in. Myth 1: “MongoDB is not as secure as a relational database” One of the most persistent myths about MongoDB is that it is not secure—certainly not as secure as traditional relational databases. This misconception likely stems from a series of ransomware attacks in the mid-2010s. Hackers exploited unsecured databases that lacked proper authentication and were left exposed on default TCP ports. While these incidents highlighted poor configuration practices, they have unfairly cast a shadow over MongoDB’s contemporary security capabilities. MongoDB provides robust, intelligent security features designed to protect sensitive data at every stage of its lifecycle. MongoDB encrypts data both in transit and at rest , just like other leading NoSQL and relational databases. However, what sets MongoDB apart is its ability to keep data encrypted while in use. With Queryable Encryption , an industry-first innovation unique to MongoDB, sensitive data can remain encrypted even while it is queried. This eliminates the need to decrypt the data and reduces exposure to threats. MongoDB also supports flexible authentication and authorization that seamlessly integrates with many identity management systems. Features like role-based access control and fine-grained permissions ensure users only have access to what they are authorized for. Concurrently, intuitive configuration makes these controls easy to implement. Beyond encryption and access control, MongoDB includes powerful auditing tools to monitor database activity and advanced network security features, such as IP allow-listing and private networking . Together, these capabilities provide comprehensive protection against unauthorized access and help organizations meet strict compliance requirements. Best of all, these advanced security features are included by default in both MongoDB Atlas and MongoDB Enterprise Advanced at zero cost. MongoDB’s approach simplifies security management while minimizing expenditure. This allows teams to focus on building applications with confidence that their data is protected. Myth 2: “MongoDB’s multi-cloud capabilities do not set it apart from other databases” At first glance, the claim that MongoDB is multi-cloud may not sound special. After all, plenty of databases are available through more than one cloud provider - however, this should not be confused with them all being multi-cloud . True multi-cloud supports ‘cross-cloud’ deployments, i.e. the ability to deploy individual nodes of a single cluster across multiple cloud providers. This distinction is often obfuscated by those vendors unable to run their clusters in such a configuration. Support for multi-cloud clusters in Atlas became generally available in October of 2020. MongoDB Atlas enables deployment not only on Amazon Web Services (AWS), Microsoft Azure, or Google Cloud but also across all three clouds simultaneously with a single cluster. It is possible to set up and configure cross-cloud deployments solely from the Atlas management console. No further configuration is required via the individual cloud providers. This is more than just a convenience; it is a transformative capability that eliminates the boundaries between cloud providers. With MongoDB Atlas, it is as if AWS, Azure, and Google Cloud operate as one unified cloud environment. Why does this matter? For starters, deploying a single database cluster across multiple clouds removes the operational complexity of managing data replication and migration between providers. Seamless data mobility can be achieved. The hardest part of any application to move—the data—now becomes the easiest. Multicloud also enables the creation of application architectures that exploit the best services from multiple cloud providers simultaneously. In addition, cross-cloud deployments deliver unmatched resiliency. With cross-cloud failover, in the event of an outage, data can be automatically switched to another cloud provider in the same geographic region. Thus ensuring uninterrupted service. Finally, MongoDB Atlas provides the flexibility to meet regional and cloud provider preferences with ease. Atlas spans 115+ supported regions across all three major cloud providers . This makes it easy to meet customer demands or comply with local regulations using a single database. MongoDB Atlas gives us the ability to run our database on multiple clouds through the same service. With Atlas, we have the freedom from lock-in—each client can choose where they are the most comfortable hosting their data. Gary Hoberman, CEO and Founder - Unquork Myth 3: “I get that MongoDB is built for horizontal scaling, but it is so painful to scale” Horizontal scaling, also known as scale-out, is a core strength of MongoDB. It allows workloads to be distributed by adding more nodes as data and applications expand. However, some beliefs have perpetuated that scaling MongoDB is difficult and complex. The reality? MongoDB makes scaling not just possible, but seamless—whether scaling out horizontally or scaling up vertically. With MongoDB Atlas, vertical scaling—or scale-up—is simple. By enabling auto-scaling , MongoDB Atlas dynamically adjusts cluster resources to meet workload demands. Adding more RAM, CPU, or storage capacity can be performed automatically and on-demand. This ensures optimal performance without continual manual intervention or oversight. If you need to move beyond vertical scaling, MongoDB offers three flexible ways to scale horizontally : Hashed sharding : Data is distributed randomly across nodes using a hashed shard key. This ensures an even distribution of data and workloads to prevent bottlenecks. Ranged sharding : Data is distributed based on ranges of a specific field. This enables fine-grained control over how data is divided. This approach is especially useful for preventing hotspots in workloads. Zone sharding : Data is distributed geographically. This enables compliance with data residency requirements and reduces latency by keeping data closer to users. What happens if the initial sharding strategy does not go as planned? MongoDB addresses this challenge with the ability to refine shard keys and reshard a collection with zero downtime. This ensures data distribution strategies can adapt as needs evolve, all without disrupting applications or users. Myth 4: “Since MongoDB is built for flexibility, it must not be very performant” One common misconception about MongoDB is that its flexibility and versatility must come at the expense of performance. After all, can such an agile database—one built for developers to model data however they want—really deliver the speed and efficiency of a performance-first solution? MongoDB is designed to provide both; unmatched flexibility and exceptional performance —all while keeping costs low. MongoDB’s performance stems from its intelligent architecture and powerful features. Ad hoc queries, indexing , and real-time aggregations make it easy to access and analyze data quickly. How fast are queries? Primary key or indexed queries typically execute in milliseconds. Even complex queries that are not indexed remain efficient. Performance typically is dependent on factors like collection size and machine specifications. What about workloads like search and analytics? Some developers might assume these would compete for resources and degrade performance on operational tasks. However, MongoDB solves this with workload isolation . This feature ensures that operational and nonoperational workloads are separated. This enables each to run at peak performance without requiring costly and time-consuming extract, transform, and load (ETL) processes. Network latency? For globally distributed applications, MongoDB’s hedged reads enable the nearest replica nodes to be read from rather than waiting for a response from distant nodes. This reduces latency and ensures applications remain highly responsive. MongoDB’s real-world performance is backed by incredible use cases: Amadeus processes 630 million bookings per year. Idealo supports 200,000 queries and 60,000 updates per second. Temenos achieves 150,080 transactions per second. This was before the release of MongoDB 8.0 , the most performant version of the database yet. MongoDB 8.0 has delivered: 36% faster reads 32% faster reads and updates 56% faster bulk inserts A stunning 200% improvement for time series queries MongoDB Atlas doesn’t just solve our performance issues. It makes life easier for web developers, who can build and maintain simpler, more straightforward code. Moutia Khatiri, CTO - Tech Accelerator, L’Oreal MongoDB Today MongoDB has evolved far beyond the myths perpetuated during its early years. MongoDB 8.0 delivers robust capabilities across security, durability, availability, and performance. It encrypts sensitive data throughout its lifecycle and enables seamless cross-cloud deployments. It simplifies horizontal and vertical scaling and powers some of the world’s most demanding applications. These capabilities solidify MongoDB’s position as the database of choice for modern applications. Read about more MongoDB myths and misconceptions in our previous two posts in this series: Debunking MongoDB Myths: Enterprise Use Case Busting the Top Myths About MongoDB vs Relational Databases Don't be held back by outdated misconceptions. Experience the innovation and performance of MongoDB. Start using MongoDB Atlas for free today . Or, to learn more about MongoDB, head over to MongoDB University and take our free Intro to MongoDB course .
Advancing Encryption in MongoDB Atlas
Maintaining a strong security posture and ensuring compliance with regulations and industry standards are core responsibilities of enterprise security teams. However, satisfying these responsibilities is becoming increasingly complex, time-consuming, and high-stakes. The rapid evolution of the threat landscape is a key driver of this challenge. In 2024, the percentage of organizations that experienced a data breach costing $1 million or more jumped from 27% to 36%. 1 This was partly fueled by a 180% surge from 2023 to 2024 in vulnerability exploitation by attackers. 2 Concurrently, regulations are tightening. Laws like the Health Insurance Portability and Accountability Act (HIPAA) 3 and the U.S. Securities and Exchange Commission’s cybersecurity regulations 4 have introduced stricter security requirements. This has raised the bar for compliance. Thousands of enterprises rely on MongoDB Atlas to protect their sensitive data and support compliance efforts. Encryption plays a crucial role on three levels; securing data at rest, in transit, and in use. However, security teams need more than solely strong encryption. Flexibility and control are essential to align with an organization’s specific requirements. MongoDB is introducing significant upgrades to MongoDB Atlas encryption to meet these needs. This includes enhanced customer-managed key (CMK) functionality and support for TLS 1.3. This post explores these improvements, along with the planned deprecation of outdated TLS versions, to strengthen organizations’ security postures. Why customer-managed keys (CMKs) matter Customer-managed keys (CMKs) are a security and data governance feature that delivers enterprises full control over the encryption keys protecting their data. With CMKs, customers can define and manage their encryption strategy. This ensures they have ultimate authority over access to their sensitive information. MongoDB Atlas customer key management provides file-level encryption, similar to transparent data encryption (TDE) in other databases. This customer-managed encryption-at-rest feature works alongside always-on volume-level encryption 5 in MongoDB Atlas. CMKs ensure all database files and backups are encrypted. MongoDB Atlas also integrates with AWS Key Management Service (AWS KMS), Azure Key Vault , and Google Cloud KMS . This ensures customers have the flexibility to manage keys as part of their broader enterprise security strategy. Customers using CMKs retain complete control of their encryption keys. If an organization needs to revoke access to data due to a security concern or any other reason, it can do so immediately by freezing or destroying the encryption keys. This capability acts as a “kill switch,” ensuring sensitive information becomes inaccessible when protection is critical. Similarly, an organization can destroy the keys to render the data and backups permanently unreadable and irretrievable. This may be applicable should they choose to retire a cluster permanently. Announcing CMK over private networking As part of a commitment to deliver secure and flexible solutions for enterprise customers, MongoDB is introducing CMKs over private networking. This enhancement enables organizations to manage their encryption keys without exposing their key management service (KMS) to the public internet. Using CMKs in MongoDB Atlas previously required Azure Key Vault and AWS KMS to be accessible via public IP addresses prior to today. While functional, this posed challenges for customers who need to keep KMS traffic private. It forced those customers to either expose their KMS endpoints or manage IP allow lists. By using private networking, customers can now: Eliminate the need for public IP exposure. Simplify network management by removing the need to manage allowed IP addresses. This reduces administrative effort and misconfiguration risk. Align with organizational requirements that mandate the use of private networking. Customer key management over private networking is now available for Azure Key Vault and AWS KMS . Customers can enable and manage this feature for all their MongoDB Atlas projects through the MongoDB Atlas UI or the MongoDB Atlas Administration API . More enhancements are coming for MongoDB customer key management in 2025. These include secretless authentication mechanisms and CMKs for search nodes. MongoDB Atlas TLS enhancements advance encryption in transit Securing data in transit is equally vital as a foundation of encryption at rest with CMKs. To address this, MongoDB Atlas enforces TLS by default. This ensures encrypted communication across all aspects of the platform, including client connections. Now MongoDB is reinforcing its TLS implementation with key enhancements for enterprise-grade security. MongoDB is in the process of rolling out fleetwide support for TLS 1.3 in MongoDB Atlas. The latest version of the cryptographic protocol offers several advantages over its predecessors. This includes stronger security defaults, faster handshakes, and reduced latency. Concurrently, TLS versions 1.0 and 1.1 are being deprecated. The rationale for this is known weaknesses and their inability to meet modern security standards. MongoDB is aligning with industry best practices by standardizing on TLS 1.2 and 1.3. This ensures a secure communication environment for all MongoDB Atlas users. Additionally, MongoDB now offers custom cipher suite selection, giving enterprises more control over their cryptographic configurations. This feature lets organizations choose the cipher suites for their TLS connections, ensuring compliance with their security requirements. Achieving encryption everywhere This post covers how MongoDB secures data at rest with CMKs and in transit with TLS. However, what about data in use while it’s being processed in a MongoDB Atlas instance? That’s where Queryable Encryption comes in. This groundbreaking feature enables customers to run expressive queries on encrypted data without ever exposing the plaintext or keys outside the client application. Sensitive data and queries never leave the client unencrypted. This ensures sensitive information is protected and inaccessible to anyone without the keys, including database administrators and MongoDB itself. MongoDB is committed to providing enterprise-grade security that evolves with the changing threat and regulatory landscapes. Organizations now have greater control, flexibility, and protection across every stage of the data lifecycle with enhanced CMK functionality, TLS 1.3 adoption, and custom cipher suite selection. As security challenges grow more complex, MongoDB continues to innovate to enable enterprises to safeguard their most sensitive data. To learn more about these encryption enhancements and how they can strengthen your security posture, visit MongoDB Data Encryption . 1 PwC , October 2024 2 Verizon Data Breach Investigations Report , 2024 3 U.S. Department of Health and Human Services , December 2024 4 U.S. Securities and Exchange Commission , 2023 5 MongoDB Atlas Security White Paper , Encryption at Rest section page 12
AI-Powered Java Applications With MongoDB and LangChain4j
MongoDB is pleased to introduce its integration with LangChain4j , a popular framework for integrating large language models (LLMs) into Java applications. This collaboration simplifies the integration of MongoDB Atlas Vector Search into Java applications for building AI applications. The advent of generative AI has opened up many new possibilities for developing novel applications. These advancements have led to the development of AI frameworks that simplify the complexities of orchestrating and integrating LLMs and the various components of the AI stack , where MongoDB plays a key role as an operational and vector database. Simplifying AI development for Java The first AI frameworks to emerge were developed for Python and JavaScript, which were favored by early AI developers. However, Java remains widespread in enterprise software. This has led to the development of LangChain4j to address the needs of the Java ecosystem. While largely inspired by LangChain and other popular AI frameworks, LangChain4j is independently developed. As with other LLM frameworks, LangChain4j offers several advantages for developing AI systems and applications by providing: A unified API for integrating LLM providers and vector stores. This enables developers to adopt a modular approach with an interchangeable stack while ensuring a consistent developer experience. Common abstractions for LLM-powered applications, such as prompt templating, chat memory management, and function calling, offering ready-to-use building blocks for common AI applications like retrieval-augmented generation (RAG) and agents. Powering RAG and agentic systems with MongoDB and LangChain4j MongoDB worked with the LangChain4j open-source community to integrate MongoDB Atlas Vector Search into the framework, enabling Java developers to develop AI-powered applications from simple RAG to agentic applications. In practice, this means developers can now use the unified LangChain4j API to store vector embeddings in MongoDB Atlas and use Atlas Vector Search capabilities for retrieving relevant context data. These capabilities are essential for enabling RAG pipelines, where private, often enterprise data is retrieved based on relevancy and combined with the original prompt to get more accurate results in LLM-based applications. LangChain4j supports various levels of RAG, from basic to advanced implementations, making it easy to prototype and experiment before customizing and scaling your solution to your needs. A basic RAG setup with LangChain4j typically involves loading and parsing unstructured data from documents stored locally or on remote services like Amazon S3 or Azure Storage using the Document API. The process then transforms and splits the data, then embeds it to capture the semantic meaning of the content. For more details, check out the documentation on core RAG APIs . However, real-world use cases often demand solutions with advanced RAG and agentic systems. LangChain4j optimizes RAG pipelines with predefined components designed to enhance accuracy, latency, and overall efficiency through techniques like query transformation, routing, content aggregation, and reranking. It also supports AI agent implementation through dedicated APIs, such as AI Services and Tools , with function calling and RAG integration, among others. Learn more about the MongoDB Atlas Vector Search integration in LangChain4j’s documentation . MongoDB’s dedication to providing the best developer experience for building AI applications across different ecosystems remains strong, and this integration reinforces that commitment. We will continue strengthening our integration with LLM frameworks enabling developers to build more-innovative AI applications, agentic systems, and AI agents. Ready to start building AI applications with Java? Learn how to create your first RAG system by visiting our tutorial: How to Make a RAG Application With LangChain4j .
MongoDB 8.0: Eating Our Own Dog Food
Key Takeaways We achieve real-world testing by adopting release candidates (RCs) on our internal production systems before finalizing a release. Our diverse internal workloads delivered unique insights. For instance, an internal cluster’s upgrade identified a rare MongoDB server crash and an inefficiency for a specific query shape introduced by a new MongoDB 8.0 feature. Issues encountered while testing MongoDB 8.0 internally were fixed proactively before they went out to customers. For example, during an upgrade to an 8.0 RC, one of our internal databases crashed and the issue was fixed in the next RC. Prerelease testing uncovered gaps in our automated testing, leading to improved coverage with additional tests. Using MongoDB 8.0 internally on mission-critical internal systems demonstrated its reliability. This gave customers confidence that the release could handle their demanding workloads, just as it did for our own engineering teams. Release jitters Every software release, whether it’s a new product or an update of an existing one, comes with an inherent risk: what if users encounter a bug that the development team didn’t anticipate? With a mission-critical product like MongoDB 8.0 , even minor issues can have a significant impact on customer operations, uptime, and business continuity. Unfortunately, no amount of automated testing can guarantee how MongoDB will perform when it lands with customers. So how does MongoDB proactively identify and resolve issues in our software before customers encounter them, thereby ensuring a seamless upgrade experience and maintaining customer trust? Catching issues before you do To address these challenges, we employ a combination of methods to ensure reliability. One approach is to formally model our system to prove the design is correct, such as the effort we undertook to mathematically model our protocols with lightweight formal methods like TLA+. Another method is to prove reliability empirically by dogfooding. Dogfooding (🤨)? Eating your own dog food—aka eating your own pizza, aka “dogfooding”—refers to a development process where you put yourself in customers’ shoes by using your own product in your own production systems. In short: you’re your own customer. Why dogfood? Enhanced product quality: Testing in a controlled environment can’t replicate the edge cases of true-to-life workloads, so real-world scenarios are needed to ensure robustness, reliability, and performance under diverse conditions. Early identification of issues: Testing internally surfaces issues earlier in the release process, enabling fixes to be deployed proactively before customers encounter them. Build customer empathy: Acting as users provides direct insight into customer pain points and needs. Engineers gain firsthand understanding of the challenges of using their product, informing more customer-centric solutions. Without dogfooding, things like upgrades are taken for granted and customer pain points can be overlooked. Boost credibility and trust: Relying on our own software to power critical internal systems reassures customers of its dependability. Dogfooding at MongoDB MongoDB has a strong dogfooding culture. Many internal services are built with MongoDB and hosted on MongoDB Atlas , the very same setup we provide our customers. Eating our own dog food is essential to our customer mindset. Because internal teams work alongside MongoDB engineers, acting as users bridges the gap between MongoDB engineers and their customers. Additionally, real-life workloads vet our software and processes in a way automated testing cannot. Release dogfooding With the release of MongoDB 8.0, the company decided to take dogfooding one step further. Driven by a company-wide focus on making 8.0 the most performant version of MongoDB yet, we embarked on an ambitious plan to dogfood the release candidates within our own infrastructure. Before, our release process looked like this: Figure 1. Releases without real-world testing. We wanted it to look more like this: Figure 2. Releases pregamed on internal clusters. Adding internal testing to the release process allows us to iterate long before we make the product available to customers. Whereas in the past we’d release and fix issues reactively as customers encountered them, using the release internally, before it got into customers’ hands, would uncover edge cases so we could fix them proactively. By acting as our own customers, we remove our real customers from the development cycle and build confidence in the release. The confidence team To tackle upgrades effectively, we assembled a cross-functional team of MongoDB engineers, Atlas SREs, and internal service developers. A technical program manager (TPM) was assigned to the effort to track progress and coordinate efforts across the team. Together, we enumerated the databases, scheduled upgrade dates, and assigned directly responsible individuals (DRIs) to each upgrade. To streamline communication, we created an internal Slack channel and invited everyone on the team to it. We agreed on a playbook: with the support of the team, the assigned DRI would upgrade their cluster and monitor for any issues. If something came up we would create a ticket in an internal Jira project and mention it in Slack for visibility. I took on the role of DRI for Evergreen database upgrades. Evergreen My team maintains the database clusters for Evergreen , MongoDB’s bespoke continuous integration (CI) system. Evergreen is responsible for running automated tests at scale against MongoDB, Atlas, the drivers, Evergreen itself, and many other products. At last count, each day Evergreen executes, in parallel, roughly ten years of tests per day and is on the critical path for many teams at the company. Evergreen runs on two separate clusters in Atlas: the application’s main replica set and a smaller one for our background job coordinator, Amboy . In terms of scale, the main replica set contains around 9.5TB of data and handles 1 billion CRUD operations per day, while the Amboy cluster contains about 1TB of data and handles 100 million CRUD operations per day. Because of Evergreen’s criticality to the development cycle, historically we’ve taken a cautious approach to any operational changes and database upgrades were not a priority. The initiative to dogfood our internal clusters changed our approach—we were going to use 8.0 before it went out to customers. Enabling a feature flag in Atlas made the RC build available in our Atlas project before it was available to customers. A showstopper Our first target was the Amboy cluster, which handles background jobs for Evergreen. I clicked the button to upgrade our Amboy cluster and we held our collective breath. Atlas upgrades are rolling. This means an upgrade is applied iteratively to each secondary in the cluster until finally the primary is stepped down and upgraded. Usually this works well since any issues will at most affect just a secondary, but in our case it didn’t work out. The secondaries’ upgrades succeeded, but when the primary was stepped down, each node that won the election to be the next primary crashed. The result was that our cluster had no primary and the Amboy database was unavailable, which threw a monkey-wrench in our application. We sounded the alarm and an investigation commenced ASAP. Stack traces, logs, and diagnostics were captured and the cluster was downgraded to 7.0. As it turned out, we’d hit an edge case that was triggered by a malformed TTL index specification with a combination of two irregularities: Its expireAfterSeconds was not an integer. It contained a weights field , which is not valid in an index that’s not a text index . Both irregularities were previously allowed, but became invalid due to strengthened validation checks. When a node steps up to primary, it corrects these malformed index specifications, but in that 8.0 RC if there were two things wrong with an index it would go down an execution path that ended in a segfault. This bug only occurs when a node steps up to primary, which is why it brought down our cluster despite the rolling upgrade. SERVER-94487 was opened to fix the bug and the fix was rolled into the next RC. When the RC was ready, we upgraded the Amboy database again and the upgrade succeeded. Not a showstopper Next up was the main database cluster for the Evergreen application. We performed the upgrade, and at first all indications were that the upgrade was a success. However, on further inspection a discontinuous jump had appeared in two of the Atlas monitoring graphs. Before the upgrade our Query Executor graph usually looked like this: Figure 3. Query Executor graph before the upgrade. Whereas after the upgrade it looked like this: Figure 4. Query Executor graph after the upgrade. This represented roughly a 5x increase in the rate per second of index keys and documents scanned by queries and query plans. Similarly, the Query Targeting graph looked like this before the upgrade: Figure 5. Query Targeting graph before the upgrade. Whereas after the upgrade it looked like this: Figure 6. Query Targeting graph after the upgrade. This also represented roughly a 5x increase to the ratio of scanned index keys and documents to the number of documents returned. Both these graphs indicated there was at least one query that wasn’t using indexes as well as it had been before the upgrade. We got eyes on the cluster and it was determined that a bug in index pruning (a new feature introduced in 8.0) was causing the query planner to remove the most efficient index for a contained $or query shape. This is when a query contains an $or branch that isn’t the root of the query predicate, such as A and (C or B) . For the 8.0 release this was listed as a known issue and disabled in Atlas, and index pruning was disabled entirely by the 8.0.1 release until we can fix the underlying issue in SERVER-94741 . Other clusters Other teams’ clusters followed suit, but their upgrades went off without a hitch. It’s to be expected that the particulars of each dataset and workload would trigger various edge cases. Evergreen’s clusters hit some while the rest did not. This brings out an important lesson: testing against a variegated set of live workloads raises the likelihood we’ll encounter and address all the issues our customers would have encountered. Continuous improvement Although we caught these issues before they reached customers, our shift-left mindset motivates us to catch them earlier in the process through automated testing. As part of this effort, we plan to add additional tests focused on upgrades from older versions of the database. The index pruning issue, in particular, was part of the inspiration for us to investigate property based testing –an approach that has already uncovered several new bugs ( SERVER-89308 ). SERVER-92232 will introduce a property based test specifically for index pruning. What’s next? All told, the exercise was a success. The 8.0 upgrade reduced Evergreen’s operation execution times by an order of magnitude: Figure 7. Drastically faster database operations after the upgrade. For customers, dogfooding uncovered novel issues and gave us the chance to fix them before they could disrupt customer workloads. By the time we cut the release we were confident we were providing our customers a seamless upgrade. Through the dogfooding process we discovered additional internal teams with services built on MongoDB. And now we’re further leaning in on dogfooding by building out a formal framework that will include those teams and their clusters. For the next release, this will uncover even more insights and provide greater confidence. Looking ahead, as our CTO aptly put it , "all customers demand security, durability, availability, and performance" from their technology. Our commitment to eating our own dogfood directly strengthens these very pillars. It's a commitment to our customers, a commitment to innovation, and a commitment to making MongoDB the best database in the world. Join our MongoDB Community to learn about upcoming events, hear stories from MongoDB users, and connect with community members from around the world.
Secure by Default: Mandatory MFA in MongoDB Atlas
On March 26, 2025, MongoDB will start rolling out mandatory multi-factor authentication (MFA) for MongoDB Atlas users. While MFA has long been supported in Atlas, it was previously optional. MongoDB is committed to delivering customers the highest level of security, and the introduction of mandatory MFA adds an extra layer of protection against unauthorized access to MongoDB Atlas. Note: MFA will require users to provide a second form of authentication, such as a one-time passcode or biometrics. To ensure a smooth transition, users are encouraged to set up their preferred MFA method in advance. This process should take around three minutes to set up. If MFA is not configured by March 26, 2025, users will need to enter a one-time password (OTP) sent to their registered email each time they log in. Why are we making MFA mandatory? Stealing users’ credentials is a key tactic in the modern cyberattack playbook. According to a Verizon report, stolen credentials have been involved in 31% of data breaches in the past decade, and credential stuffing is the most common attack type for web applications. 1 Credential stuffing is when attackers use stolen credentials obtained from a data breach on one service to attempt to log in to another service. These breaches are particularly harmful, taking an average of 292 days to detect and contain. 2 This rise in cyber threats has rendered password-only security inadequate. Organizations of all sizes trust MongoDB Atlas to safeguard their mission-critical applications and sensitive data. These range from global enterprises to individual developers. Therefore, to strengthen account security and to reduce the risk of unauthorized access, MongoDB is introducing mandatory MFA. The impact of MFA A large-scale study by Microsoft measured the effectiveness of MFA to prevent cyberattacks on enterprise accounts. The findings indicated enabling MFA reduces the risk of account compromise by 99.22%. For accounts with previously leaked credentials, MFA still lowered the risk by 98.56%. This makes MFA one of the most effective defenses against unauthorized access. By default, requiring MFA strengthens the security of all MongoDB Atlas accounts. By reducing the risk of compromised accounts being used in broader attacks, this proactive step protects individual users and enhances MongoDB Atlas’s overall security. Ensuring strong authentication practices across the Atlas ecosystem maintains the integrity of mission-critical applications and sensitive data— and a safer experience for everyone is the result. Preparing for mandatory MFA MFA will be a prerequisite for all users when logging into MongoDB services using Atlas credentials. These services include: MongoDB Atlas user interface MongoDB Support portal MongoDB University MongoDB Forums Atlas supports the following MFA methods: Security key or biometrics: FIDO2 (WebAuthn) compliant security keys (e.g., YubiKey ) or biometric authentication (e.g., Apple Touch ID or Windows Hello) One-time password (OTP) and push notifications: Provided through the Okta Verify app Authenticator apps: Such as Twilio Authy , Google Authenticator , or Microsoft Authenticator for generating time-based OTPs Email: For generating OTPs MongoDB encourages users to choose phishing-resistant MFA methods, such as security keys or biometrics. Strengthening security with mandatory MFA Requiring MFA is a significant step that enhances MongoDB Atlas’s default security. Multi-factor authentication protects users from credential-based attacks and unauthorized access. Making MFA’s additional layer of authentication mandatory ensures greater account security. This safeguards mission-critical applications and data. To ensure a smooth transition, users are encouraged to set up their preferred MFA method before March 26, 2025. For detailed setup instructions, refer to the MongoDB documentation . And, please visit the MongoDB security webpage and Trust Center to learn more about MongoDB’s commitment to security.