MongoDB Blog
Announcements, updates, news, and more
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 MongoDB Relational Migrator and Kafka change streams. 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 4.4, 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.
Introducing MongoDB Atlas Service Accounts via OAuth 2.0
Authentication is a crucial aspect of interacting with the MongoDB Atlas Administration API , as it ensures that only authorized users or applications can access and manage resources within a MongoDB Atlas project. While MongoDB Atlas users currently have programmatic API keys (PAKs) as their primary authentication method, we recognize that development teams have varying authentication workflow requirements. To help developer teams meet these requirements, we’re excited to announce that Service Accounts via OAuth 2.0 for MongoDB Atlas is now generally available! MongoDB Atlas Service Accounts offer a more streamlined way of authenticating API requests for applications, enabling your developers to use their preferred authentication workflow. Addressing the challenges of using programmatic access keys At some point in your MongoDB Atlas journey, you have likely created PAKs. These API keys enable MongoDB Atlas project owners to authenticate access for their users. API keys include a public key and a private key. These two parts serve the same function as a username and a password when you make API requests to MongoDB Atlas. Each API key belongs to only one organization, but you can grant API keys access to any number of projects in that organization. PAKs use a method of authentication known as HTTP Digest, which is a challenge-response authentication mechanism that uses a hash function to securely transmit credentials without sending plaintext passwords over the network. MongoDB Atlas hashes the public key and the private key using a unique value called a nonce. The HTTP Digest authentication specifies that the nonce is only valid for a short amount of time. This is to prevent replay attacks so that you can’t cache a nonce and use it forever. It’s also why your API keys are a mix of random symbols, letters, and numbers and why you can only view a private key once. As a result, many teams must manage and rotate PAKs to maintain application access security. However, doing this across multiple applications can be cumbersome, especially for teams operating in complex environments. As a result, we’ve introduced support for an alternate authentication method through Service Accounts via OAuth 2.0, which enables users to take advantage of a more automated authentication method for application development. Using Service Accounts with an OAuth 2.0 client credentials flow OAuth 2.0 is a standard for interapplication authentication that relies on in-flight TLS encryption to secure its communication channels. This prevents unauthorized parties from intercepting or tampering with the data. The MongoDB Atlas Administration API supports in-flight TLS encryption and uses it to enable Service Accounts as an alternative method for authenticating users. MongoDB Atlas Service Accounts provide a form of OAuth 2.0 authentication that enables machine-to-machine communication. This enables applications, rather than users, to authenticate and access MongoDB Atlas resources. Authentication through Service Accounts follows the same access control model as PAKs, with full authentication lifecycle management. Service Accounts use the OAuth 2.0 client credentials flow, with MongoDB Atlas acting as both the identity provider and the authorization server. Like PAKs, Service Accounts are not tied to individual MongoDB Atlas users but are still ingrained with MongoDB Atlas. Figure 1. How it Works - MongoDB Atlas Service Accounts Experiencing benefits through Service Accounts Using Service Accounts to manage programmatic access offers a number of advantages: Automation Service Accounts offer an automated way to manage access. Users don’t need to manually manage authentication mechanisms, like recreating a Service Account to rotate the “client secrets.” Instead, they only need to regenerate the client secrets while keeping the other configuration of the existing Service Account intact. Furthermore, Service Accounts are broadly supported across many platforms, enabling easier integration between different services and tools and facilitating easier connections across applications and infrastructure components, regardless of the underlying technology. Seamless integration with MongoDB Atlas Service Accounts enable developers to manage authentication in the workflow of their choice. Users can manage the Service Account lifecycle at the organization and project levels via the MongoDB Atlas Administration API, the provided client library (currently, the Atlas Go SDK) , and the Atlas UI . They integrate with MongoDB Atlas via the OAuth 2.0 client credential flow, enabling seamless authentication using cloud-native identity systems. Granular access control and role management Service Accounts also have robust security features, providing a standardized and consistent way to manage access. Each organization or project can have its own Service Account, simplifying credential management and access control. Additionally, you can define granular roles for a Service Account to limit its access to only the necessary resources. This reduces the risk of over-permissioning and unauthorized access. Ready to uplevel your user authentication? Learn how to create your first Service Account by visiting our documentation . Not a MongoDB Atlas user yet? Sign up for free today.
MongoDB: Gateway to Open Finance and Financial Data Access
This is the second in a two-part series about open finance and the importance of a flexible data store to open finance innovation. Check out part one here! Open finance is reshaping the financial services industry, pushing traditional institutions to modernize with a data-driven approach. Consumers increasingly expect personalized experiences, making innovation key to customer retention and satisfaction. According to a number of studies 1 , there is an exponential increase of dynamic transformations in financial services, driven primarily by the impact of Banking-as-a-Service (BaaS), embedded banking services, and AI. All of these initiatives are mainly powered by API services intended for data sharing, and have become must-have technical capabilities for financial institutions. Open finance can also unlock massive opportunities for continuous innovation. As a result, financial institutions must provision themselves with the right tools and expertise to be fully aware of the potential risks and challenges of embarking on such a “data-driven” journey. Now, let’s dive deeper into an application of open finance with MongoDB. MongoDB as the open finance data store Integrating diverse financial data while ensuring its security, compliance, and scalability represents a series of considerable challenges for financial institutions. Bringing together data from a variety of backend systems entails a set of complex hurdles for financial ecosystem participants—banks, fintechs, and third-party providers (TPP). First, they need to be able to handle structured, semi-structured, and increasingly unstructured data types. Then, cybersecurity and regulatory compliance concerns must be addressed. What’s more, an increase in data-sharing scenarios can open up potential vulnerabilities, which lead to the risk of breach exposure and cyber-attacks (and, therefore, possible legal penalties and/or eventual reputational damage). Figure 1. The power of open finance. To implement open finance strategies, organizations must first determine the role they will play: whether they act as data holders, are in charge of sharing the data with TPP, or whether they will be data users, the ones able to provide enhanced financial capabilities to end-users. Then, they must choose the most suitable technology for the data management strategy—and this is where MongoDB comes in, functioning as the operational data store. Let’s explore how MongoDB can play a crucial role for both actors—data holders and data users—through an open finance functional prototype. Open finance in action: Aggregated financial view for banking users Figure 2 below shows a digital application from a fictional bank—Leafy Bank—that allows customers to aggregate all their bank accounts into a single platform. Figure 2. Architecture of MongoDB as the open finance data store. Four actors are involved in this scenario: a. Customer - User b. Data Users - Leafy Bank c. Data Holders - External Institution d. Open Finance Data Store - MongoDB Atlas Now let’s go through the steps from the customer experience. Step 1. Log in to the banking application Once logged in, the Leafy Bank digital banking application allows users to aggregate their external bank accounts. It is done behind the scenes, through a RESTFul API request that will usually interchange data in JSON format. For the Leafy Bank prototype, we are using MongoDB and FastAPI together, exposing and consuming RESTful APIs and therefore taking advantage of MongoDB Atlas’s high performance, scalability, and flexibility. Figure 3. Logging in to the banking application. Step 2. User authentication and authorization A crucial step to ensure security and compliance is user consent. End-users are responsible for granting access to their financial information (authorization). In our case, Leafy Bank emulates the OAuth 2.0 authentication. It generates the corresponding tokens for securing the service communication between participants. To achieve efficient interoperability without security issues, data holders must enable a secured technological “fence” for sharing data while preventing the operational risk of exposing core systems. Figure 4. User authorization. Step 3. Data exposure After the authorization has been granted, Leafy Bank will fetch the corresponding account data from the data custodian—external banks (in our fictional scenario, Green Bank or MongoDB Bank)—via APIs. Usually, participants expose customers’ financial data (accounts, transactions, and balances) through their exposed services in JSON format to ensure compatibility and seamless data exchange. Because MongoDB stores data in BSON, a superset of JSON , it provides a significant advantage by allowing seamless storage and retrieval of JSON-like data—making it an ideal backend for open finance. Figure 5. Data exposure. Step 4. Data fetching The retrieved financial data is then pushed into the open finance data store—in our case, in MongoDB Atlas—where it is centrally stored. Unlike rigid relational databases, MongoDB uses a flexible schema model, making it easy for financial institutions to aggregate diverse data structures from different sources, making it ideal for dynamic ecosystems and easy to adapt without costly migrations or downtime. Figure 6. Data fetching from data holder into MongoDB Atlas Data Store. Step 5. Data retrieval Now that the data has been aggregated in the operational data store (powered by MongoDB Atlas), Leafy Bank can leverage MongoDB Aggregation Pipelines for real-time data analysis and enrichment. To become “open finance” compliant, our Leafy Bank provides a holistic financial view and a global position accessible in a single application, thus improving individuals' experience with their finances. Furthermore, this set of features also benefits financial institutions. They can unveil useful insights for building unique services meant to enhance customers' financial well-being. Figure 7. Data retrieval from MongoDB Atlas Data Store. Step 6. Bank connected! In the end, customers can view all their finances in one place, while enabling banks to offer competitive, data-driven, tailored services. Figure 8. Displaying the bank connection in Leafy Bank. Demo in action Now, let’s combine these steps into a real-world demo application: Figure 9. Leafy Bank - MongoDB as the Open Finance Data Store. Advantages of MongoDB for open finance Open finance presents opportunities for all the ecosystem participants. On the one hand, bank customers can benefit from tailored experiences. For personal financial management, it can provide end-users central visibility of their bank accounts. And open finance can enable extended payment initiation services, financial product comparison, enhanced insurance premium assessments, more accurate loan and credit scoring, and more. From a technical standpoint, MongoDB can empower data holders, data users, and TPP to achieve open finance solutions. By offering a flexible schema , banks can adapt to open finance’s evolving requirements and regulatory changes while avoiding the complexity of rigid schemas, yet allowing a secure and manageable schema validation if required. Furthermore, a scalable ( vertical and horizontal ) and cloud-native ( multi-cloud ) platform like MongoDB can simplify data sharing in JSON format, as it has been widely adopted as the data interchange “defacto” format, making it ideal for open finance applications. Internally, MongoDB uses BSON, the binary representation of JSON, for efficient storage and data traversal. MongoDB’s rich extensions and connectors support a variety of frameworks to create RESTful API development. Besides FastAPI, there are libraries for Express.js (Node.js), Django (Python), Spring Boot (Java), and Flask (Python). The goal is to empower developers with an intuitive and easy-to-use data platform that boosts productivity and performance. Additionally, MongoDB offers key features like its aggregation pipeline , which is designed to process data more efficiently by simplifying complex transformations, real-time analytics, and detailed queries. Sophisticated aggregation capabilities from MongoDB allow financial institutions to improve their agility while maintaining their competitive edge, all by having data as their strategic advantage. Lastly, MongoDB provides financial institutions with critical built-in security controls, including encryption, role-based access controls (RBAC), and auditing. It seamlessly integrates with existing security protocols and compliance standards while enforcing privileged access controls and continuous monitoring to safeguard sensitive data, as detailed in the MongoDB Trust Center . Check out these additional resources to get started on your open finance journey with MongoDB: Read part-one of our series to discover why a flexible data store is vital for open finance innovation. Explore our GitHub repository for an in-depth guide on implementing this solution. Visit our solutions page to learn more about how MongoDB can support financial services.
MongoDB Powers M-DAQ’s Anti-Money Laundering Compliance Platform
Founded and headquartered in Singapore, M-DAQ Global is a fintech powerhouse providing seamless cross-border transactions for businesses worldwide. M-DAQ’s comprehensive suite of foreign exchange, collections, and payments solutions help organizations of all sizes navigate the complexities of global trade, offering FX clarity, certainty, and payment mobility. M-DAQ also offers AI-powered services like Know Your Business (KYB), onboarding, and advanced risk management tools. Amidst ever-evolving requirements, these enable business transactions across borders with ease, while staying compliant. One of M-DAQ's most innovative solutions, CheckGPT , is an AI-powered platform designed to streamline Anti-Money Laundering (AML) compliance. It was built on MongoDB Atlas , providing a strong foundation for designing multitenant data storage. This approach ensures that each client has a dedicated database, effectively preventing any data co-mingling. Traditional AML processes often involve tedious, time-consuming tasks, from document review, to background checks, to customer onboarding. By building CheckGPT, M-DAQ’s aim was to change this paradigm, and to leverage AI to automate (and speed) these manual processes. Today, CheckGPT allows businesses to process onboarding 30 times faster than traditional human processing. The platform also leverages MongoDB Atlas’s native Vector Search capabilities to power intelligent semantic searches across unstructured data. The challenge: Managing unstructured, sensitive data, and performing complex searches One of CheckGPT’s priorities was to improve processes around collecting, summarizing, and analyzing data, while flagging potential risks to customers quickly and accurately. Considering the vast number and complexity of data sets its AI platform had to handle, and the strict regulatory landscape the company operates in, it was crucial that M-DAQ chose a robust database. CheckGPT needed a database that could efficiently and accurately handle unstructured data, and adapt rapidly as the data evolved. The database also had to be highly secure; to function, the AI tool would have to handle highly sensitive data, and would need to be used by companies operating in highly regulated industries. Finally, CheckGPT was looking for the ability to perform complex, high-dimensional searches to power a wide range of complex searches and real-time information analysis. MongoDB Atlas: A complete platform with unique features According to M-DAQ, there are many benefits of using MongoDB Atlas’ document model: Flexibility: MongoDB Atlas’s document model accommodates the evolving nature of compliance data, providing the flexibility needed to manage CheckGPT's dynamic data structures, such as onboarding documents and compliance workflows. Security and performance: The MongoDB Atlas platform also ensures that data remains secure throughout its lifecycle. M-DAQ was able to implement a multi-tenancy architecture that securely isolates data across its diverse client base. This ensures that the platform can handle varying compliance demands while maintaining exceptional performance, giving M-DAQ’s customers the confidence that the AML processes handled by CheckGPT are compliant with stringent regulatory standards. Vector search capabilities: MongoDB Atlas provides a unified development experience. Particularly, MongoDB Atlas Vector Search enables real-time searches across a vast amount of high-dimensional datasets. This makes it easier to verify documents, conduct background checks, and continuously monitor customer activity, ensuring fast and accurate results during AML processes. “AI, together with the flexibility of MongoDB, has greatly impacted CheckGPT, enabling us to scale operations and automate complex AML compliance processes,” said Andrew Marchen, General Manager, Payments and Co-founder, Wallex at M-DAQ Global. “This integration significantly reduces onboarding time, which typically took between 4-8 hours to three days depending on the document’s complexity, to less than 10 minutes. With MongoDB, M-DAQ is able to deliver faster and more accurate results while meeting customer needs in a secure and adaptable environment." The future of CheckGPT, powered by MongoDB M-DAQ believes that AI and data-driven technologies and tools will continue to play a central role in automating complex processes. By employing AI, M-DAQ aims to improve operational efficiency, enhance customer experiences, and scale rapidly—while maintaining high service standards. MongoDB’s flexibility and multi-cloud support will be key as M-DAQ plans to use single/multi-cluster and multi-region capabilities in the future. M-DAQ aims to explore additional features that could enhance CheckGPT's scalability and performance. The company, for example, plans to expand its use of MongoDB for future projects involving automating complex processes like compliance, onboarding, and risk management in 2025. Learn more about CheckGPT on their site . Visit our product page to learn more about MongoDB Atlas. Get started with MongoDB Atlas Vector Search today with our Atlas Vector Search Quick Start guide .
LangChainGo and MongoDB: Powering RAG Applications in Go
MongoDB is excited to announce our integration with LangChainGo, making it easier to build Go applications powered by large language models (LLMs). This integration streamlines LLM-based application development by leveraging LangChainGo’s abstractions to simplify LLM orchestration, MongoDB’s vector database capabilities, and Go’s strengths as a performant, scalable, and easy-to-use production-ready language. With robust support for retrieval-augmented generation (RAG) and AI agents, MongoDB enables efficient knowledge retrieval, contextual understanding, and real-time AI-driven workflows. Read on to learn more about this integration and the advantages of using MongoDB as a vector database for AI/ML applications in Go. LangChainGo: Bringing LangChain to the Go ecosystem LangChain is an open-source framework that simplifies building LLM-powered applications. It offers tools and abstractions to integrate LLMs with diverse data sources, APIs, and workflows, supporting use cases like chatbots, document processing, and autonomous agents. While LangChain currently supports only Python and JavaScript, the need for a similar solution in the Go ecosystem led to the development of LangChainGo. LangChainGo is a community-driven, third-party port of the LangChain framework for the Go programming language. It allows Go developers to directly integrate LLMs into their Go applications, bringing the capabilities of the original LangChain framework into the Go ecosystem. LangChainGo enables users to embed data using various services, including OpenAI, Ollama, Mistral, and others. It also supports integration with a variety of vector stores, such as MongoDB. MongoDB’s role as an operational and vector database MongoDB excels as a unified data layer for AI applications with native vector search capabilities due to its simplicity, scalability, security, and rich set of features. With Atlas Vector Search built into the core database, there's no need to sync operational and vector data separately—everything stays in one place, saving time and reducing complexity when you develop AI-powered applications. You can easily combine semantic searches with metadata filters, graph lookups, aggregation pipelines, and even geo-spatial or lexical search, enabling powerful hybrid queries all within a single platform. MongoDB’s distributed architecture allows the usage of vector search to scale independently from the core database, ensuring optimized vector query performance and workload isolation for superior scalability. Plus, with enterprise-grade security and high availability, MongoDB provides the reliability and peace of mind you need to power your AI-driven applications at scale. MongoDB, Go, and AI/ML As the Go AI/ML landscape grows, MongoDB continues to drive innovation with its powerful vector search capabilities and LangChainGo integration, empowering developers to build RAG implementations and AI agents. This integration is powered by the MongoDB Go Driver , which supports vector search and allows developers to interact with MongoDB directly from their Go applications, streamlining development and reducing friction. Figure 1. RAG architecture with MongoDB and LangChainGo. While Python and JavaScript dominate the AI/ML ecosystem, Go’s AI/ML ecosystem is still emerging—yet its potential is undeniable. Go’s simplicity, scalability, runtime safety, concurrency, and single-binary deployment make it an ideal production-ready language for AI. With MongoDB’s powerful database and helpful learning resources, developers can seamlessly build next-generation AI solutions in Go. Ready to dive in? Explore the tutorials below to get started! Getting Started with MongoDB and LangChainGo MongoDB was added as a vector store in LangChainGo’s v0.1.13 release. It is packaged as mongovector , a component that enables developers to use MongoDB as a powerful vector store in LangChainGo. Usage guidance is provided through the mongovector-vectorstore-example , along with the in-depth tutorials linked below. Dive into this integration to unlock the full potential of Go AI applications with MongoDB. We’re excited for you to work with LangChainGo. Here are some tutorials to help you get started: Get Started with the LangChainGo Integration Retrieval-Augmented Generation (RAG) with Atlas Vector Search Build a Local RAG Implementation with Atlas Vector Search Get started with Atlas Vector Search (select Go from the dropdown menu)
Secure and Scale Data with MongoDB Atlas on Azure and Google Cloud
MongoDB is committed to simplifying the development of robust, data-driven applications—regardless of where the data resides. Today, we’re announcing two major updates that enhance the security, scalability, and flexibility of MongoDB Atlas across cloud providers. Private, secure connectivity with Azure Private Link for MongoDB Atlas Data Federation, Atlas Online Archive, and Atlas SQL Developers building on Microsoft Azure can now establish private, secure connections to MongoDB Atlas Data Federation , MongoDB Atlas Online Archive , and MongoDB Atlas SQL using Azure Private Link, enabling: End-to-end security: Reduce exposure to security risks by keeping sensitive data off the public internet. Low-latency performance: Ensure faster and more reliable access through direct, private connectivity. Scalability: Build applications that scale while maintaining secure, seamless data access. Imagine a financial services company that needs to run complex risk analysis across multiple data sources, including live transactional databases and archived records. With MongoDB Atlas Data Federation and Azure Private Link, the company can securely query and aggregate this data without exposing it to the public internet, helping it achieve compliance with strict regulatory standards. Similarly, an e-commerce company managing high volumes of customer orders and inventory updates can use MongoDB Atlas Online Archive to seamlessly move older transaction records to cost-effective storage—all while ensuring real-time analytics dashboards still have instant access to historical trends. With Azure Private Link, these applications benefit from secure, low-latency connections, enabling developers to focus on innovation instead of on managing complex networking and security policies. General availability of MongoDB Atlas Data Federation and Atlas Online Archive on Google Cloud Developers working with Google Cloud can now use MongoDB Atlas Data Federation and Atlas Online Archive, which are now generally available in GA. This empowers developers to: Query data across sources: Run a single query across live databases, cloud storage, and data lakes without complex extract, transform, and load (ETL) pipelines. Optimize storage costs: Automatically move infrequently accessed data to lower-cost storage while keeping it queryable with MongoDB Atlas Online Archive. Achieve multi-cloud flexibility: Run applications across Amazon Web Services (AWS), Azure, and Google Cloud without being locked in. For example, a media streaming service might store frequently accessed content metadata in a high-performance database while archiving older user activity logs in Google Cloud Storage. With MongoDB Atlas Data Federation, the streaming service can analyze both live and archived data in a single query, making it easier to surface personalized recommendations without complex ETL processes. For a healthcare analytics platform, keeping years’ worth of patient records in a primary database can be expensive. By using MongoDB Atlas Online Archive, the platform can automatically move older records to lower-cost storage—while still enabling fast access to historical patient data for research and reporting. These updates give developers more control over building and scaling in the cloud. Whether they need secure access on Azure or seamless querying and archiving on Google Cloud, MongoDB Atlas simplifies security, performance, and cost efficiency. These updates are now live! Log in to your MongoDB Atlas account to start exploring the possibilities today.
How Cognistx’s SQUARY AI is Redefining Information Access
In a world where information is abundant but often buried, finding precise answers can be tedious and time-consuming. People spend hours a week simply searching for the information they need. Cognistx, an applied AI startup and a member of the MongoDB for Startups program, is on a mission to eliminate this inefficiency. Through its flagship product, SQUARY AI, the company is building tools to make information retrieval faster, more reliable, and radically simpler. As Cognistx seeks to unlock the future of intuitive search with speed, accuracy, and innovation, MongoDB Atlas serves as a reliable backbone for the company’s data operations. A company journey: From bespoke AI projects to a market-ready solution Cognistx started its journey with a focus on developing custom AI solutions for clients. Over time, the company identified a common pain point across industries: the need for efficient, high-quality tools to extract actionable insights from large volumes of data. This realization led it to pivot toward a product-based approach, culminating in the development of SQUARY AI—a next-generation intelligent search platform. SQUARY AI’s first iteration was born out of a bespoke project. The goal was to build a smart search engine capable of extracting answers to open-ended questions across multiple predefined categories. Early on, the team incorporated features like source tracking to improve trustworthiness and support human-assisted reviews, ensuring that the AI’s answers could be verified and trusted. Seeing the broader potential of its technology, Cognistx began using advancements in natural language processing and machine learning, transforming its early work into a stand-alone product designed for diverse industries. The evolution of SQUARY AI: Using state-of-the-art large language models Cognistx initially deployed traditional machine learning approaches to power SQUARY AI’s search capabilities, such as conversation contextualization and multihop reasoning (the ability to combine information from multiple sources to form a more complete answer). Before the rise of large language models (LLMs), this was no small feat. Today, SQUARY AI incorporates state-of-the-art LLMs to elevate both speed and precision. The platform uses a combination of retrieval-augmented generation (RAG), custom text-cleaning methods, and advanced vector search techniques. MongoDB Atlas integrates seamlessly into this ecosystem. MongoDB Atlas Vector Search powers SQUARY AI’s advanced search capabilities and lays the groundwork for even faster and more accurate information retrieval. With MongoDB Atlas, the company can store vectorized data alongside the rest of its operational data. There’s no need to add a separate, stand-alone database to handle vector search. MongoDB Atlas serves as both the operational data store and vector data store. Cognistx offers multiple branches of SQUARY AI, including: SQUARY Chat: Designed for public-facing or intranet deployment, these website chatbots provide instant, 24/7 access to website content, eliminating the need for human agents. It also empowers website owners with searchable, preprocessed AI insights from user queries. These analytics enable organizations to directly address customer needs, refine marketing strategies, and ensure that their sites contain the most relevant and valuable information for their audiences. SQUARY Enterprise: Built with businesses in mind, this enterprise platform helps companies retrieve precise answers from vast and unorganized knowledge bases. Whether it’s assisting employees or streamlining review processes, this tool helps organizations save time, improve team efficiency, and deliver actionable insights. One of the standout features of SQUARY AI is it's AI-driven metrics that assess system performance and provide insights into user interests and requirements. This is particularly valuable for public-facing website chatbots. A powerful database: How MongoDB powers SQUARY AI Cognistx attributes much of its technical success to MongoDB. The company’s history with MongoDB spans years, and its trust in MongoDB’s performance and reliability made the database the obvious choice for powering SQUARY AI. “MongoDB has been pivotal in our journey,” said Cognistx Data Scientist Ihor Markevych. “The scalable, easy-to-use database has allowed us to focus on innovating and refining SQUARY AI without worrying about infrastructure constraints. With MongoDB’s support, we’ve been able to confidently scale as our product grows, ensuring both performance and reliability.” The team’s focus when selecting a database was on cost, convenience, and development effort. MongoDB checked all those boxes, said Markevych. The company’s expertise with MongoDB, coupled with years of consistent satisfaction with its performance, made it the obvious choice. With no additional ramp-up effort necessary, the team was able to deploy very quickly. In addition to MongoDB Atlas Vector Search, the other critical feature of MongoDB is its scalability, which Markevych described as seamless. “Its intuitive structure enables us to monitor usage patterns closely and scale up or down as needed. This flexibility ensures we’re always operating efficiently without overcommitting resources,” Markevych said. The MongoDB for Startups program has also been instrumental in the company’s success. The program provides early-stage startups with free MongoDB Atlas credits, technical guidance, co-marketing opportunities, and access to a network of partners. With help from MongoDB technical advisors, the Cognistx team is now confidently migrating data from OpenSearch to MongoDB Atlas to achieve better performance at a reduced cost. The free MongoDB Atlas credits enabled the team to experiment with various configurations to optimize the product further. It also gained access to a large network of like-minded innovators. “The MongoDB for Startups community has provided invaluable networking opportunities, enhancing our visibility and connections within the industry,” Markevych said. The future: Scaling for more projects Looking ahead, Cognistx is focusing on making SQUARY AI even more accessible and customizable. Key projects include automating the onboarding process, which will enable users to define and fine-tune system behavior from the start. The company also aims to expand SQUARY AI’s availability across various marketplaces. With a successful launch on AWS Marketplace, the company next hopes to offer its product on WordPress, making it simple for businesses to integrate SQUARY Chat into their websites. Cognistx is continuing to refine SQUARY AI’s balance between speed, accuracy, and usability. By blending cutting-edge technologies with a user-centric approach, the company is shaping the future of how people access and interact with information. See it in action Cognistx isn’t just building a tool; it’s building a movement toward intuitive, efficient, and conversational search. Experience the possibilities for yourself— schedule a demo of SQUARY AI today . To get started with vector search in MongoDB, visit our MongoDB Atlas Vector Search Quick Start guide .
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?