MongoDB AMP: Uma Abordagem Orientada por IA Para a Modernização

Paul Done and Alex Block
September 16, 2025 | Updated: September 25, 2025

Por que uma empresa de banco de dados deveria ser sua parceira de modernização? É uma pergunta justa.

Com mais de uma década de experiência em migrações de banco de dados, aprendemos que o banco de dados é frequentemente o maior obstáculo que impede a transformação digital. É onde décadas de lógica de negócios foram incorporadas, onde as dependências críticas se multiplicam e onde a complexidade que impede a inovação realmente reside. Mas ao trabalhar com o MongoDB, os clientes descobriram que a transformação da camada de dados removeu as barreiras que haviam paralisado as tentativas de modernização anteriores.

Agora, com o lançamento de hoje da Plataforma de Modernização de Aplicativos MongoDB (AMP), estamos oferecendo aos clientes uma abordagem comprovada para a modernização completa da pilha. MongoDB AMP é uma solução com tecnologia de IA que transforma rapidamente e com segurança aplicativos legados em serviços modernos e dimensionáveis. O MongoDB AMP integra fluxos de trabalho de IA agentica à nossa metodologia de modernização, juntamente com FERRAMENTAS reutilizáveis e testadas em campo, além da experiência que desenvolvemos por meio de engajamentos com cliente na última década—uma poderosa combinação de FERRAMENTAS, técnicas e talentos. Ao combinar as ferramentas AMP com o framework comprovado e repetível do MongoDB, os clientes observaram que tarefas como a transformação de código foram aceleradas em 10 vezes ou mais, com projetos de modernização sendo implementados de 2 a 3 vezes mais rápido, em média.

Figura 1. A Plataforma de Modernização de Aplicações MongoDB.
This diagram outlines AMP. At the top are three buckets which are modernization experts, proprietary tools, and agentic AI. These funnel down into further buckets for analysis, test generation, code transformation, data migration, and validation.

Os desafios comuns

Muitos de nossos clientes estão enfrentando a mesma escolha impossível: aceitar uma dívida técnica crescente que atrasa todas as iniciativas de negócios ou arriscar a interrupção com uma reescrita completa do sistema. As equipes deles estão presas mantendo código legado em vez de desenvolver novas capacidades.

Esses sistemas legados evoluíram para redes interconectadas ("emaranhados de espaguete"), onde até mesmo mudanças simples exigem coordenação entre vários sistemas e equipes. As alterações no banco de dados exigem que se atualize as integrações de middleware, a lógica de negócios do aplicativo e os componentes da interface do usuário. As equipes enfrentam dificuldades para atualizar os sistemas, pois qualquer alteração traz o risco de quebrar algo que elas não compreendem completamente. As iniciativas de inovação frequentemente são bloqueadas porque novas capacidades enfrentam dificuldades para se integrar às restrições dos sistemas legados. A dívida técnica acumula-se com cada solução alternativa, tornando cada alteração subsequente mais complexa e arriscada do que a anterior.

Antes de trabalhar com o MongoDB, a plataforma de gerenciamento de patrimônio da Intellect Design exemplificava perfeitamente esse desafio. A lógica de negócios principal estava bloqueada em centenas de procedimentos armazenados em SQL, resultando em atrasos no processamento em lote de até oito horas e limitando a escalabilidade à medida que os volumes de transação aumentavam. A arquitetura rígida da plataforma impedia a inovação e bloqueava a integração com outros sistemas, como os de tesouraria e seguros, impedindo a entrega de serviços financeiros unificados que os clientes empresariais exigiam.

Em casos como este, o resultado é estagnação disfarçada de estabilidade. Os sistemas "funcionam", mas não conseguem evoluir. Os aplicativos conseguem lidar com os requisitos de hoje, mas não conseguem se adaptar às oportunidades de amanhã. As arquiteturas legado tornaram-se a base sobre a qual tudo o mais depende — e a restrição que impede que tudo o mais mude.

Soluções comprovadas em campo.

Ao enfrentar desafios com os clientes, criamos uma metodologia abrangente para a modernização, apoiada por FERRAMENTAS sofisticadas que lidam com a complexa realidade das aplicações legadas. Nossa abordagem capacita equipes de aplicativo com processos comprovados e tecnologia criada especificamente para enfrentar sistematicamente os principais desafios.

Central na nossa metodologia é a filosofia de testar primeiro, que se provou essencial para uma modernização segura e confiável. Antes de qualquer transformação começar, desenvolvemos uma cobertura de teste abrangente para os aplicativos existentes, criando uma linha de base que captura como os sistemas legados realmente se comportam em produção. Este investimento inicial em testes torna-se a base para tudo o que segue, fornecendo salvaguardas que garantem que o código modernizado tenha um desempenho idêntico ao original, ao mesmo tempo em que dá às equipes a confiança para fazer alterações sem medo de interromper processos de negócios críticos. Nossa abordagem orientada a testes garante que a modernização seja um processo metódico e validado, onde cada alteração é verificada.

Antes de fazermos qualquer alteração no código, estabelecemos um quadro completo do sistema legado. Criamos FERRAMENTAS de análise sofisticadas que mapeiam de forma abrangente arquiteturas de aplicativo legado. Essas ferramentas revelam as interdependências complexas e a lógica incorporada que tornam os aplicativos legados muito mais intrincados do que aparentam ser na superfície. Esta análise profunda não é apenas sobre catalogar a complexidade; é sobre compreender o verdadeiro escopo, informar a execução da transformação e identificar riscos potenciais antes que eles inviabilizem os projetos.

A análise é apenas o início. Ao trabalhar com clientes, aprendemos que uma modernização bem-sucedida requer um sequenciamento e planejamento cuidadosos. Nossas capacidades de análise de dependência ajudam as equipes a compreender não apenas o que precisa ser migrado, mas também a ordem crítica das operações e quais salvaguardas precisam estar em vigor em cada etapa. É crucial evitar a tentação de migrar tudo de uma vez.

A abordagem do MongoDB é projetada para tornar as modernizações complexas bem-sucedidas, transformando aplicativos de forma incremental com validação robusta. Em vez de cruzar os dedos e esperar que tudo funcione após meses de desenvolvimento, nossa metodologia decompõe grandes esforços de modernização em componentes gerenciáveis, onde cada componente é testado e verificado de forma iterativa. Os problemas são detectados no início, quando são fáceis de corrigir, e não após meses de desenvolvimento, quando o rollback se torna caro e complexo. Cada iteração bem-sucedida reduz o risco em vez de acumulá-lo.

A aceleração agentiva da IA

O MongoDB AMP representa mais de dois anos de esforço dedicado para integrar automação impulsionada por IA em nossos processos comprovados em batalha, acelerando drasticamente a modernização enquanto mantém a confiabilidade da qual nossos clientes dependem.

A IA expande poderosamente nossos processos de validação, gerando casos de teste adicionais para validar aplicativos modernizados em relação aos seus equivalentes legados. Isso melhora drasticamente a confiança nos resultados da migração enquanto reduz o tempo que as equipes gastam criando manualmente casos de teste para a complexa lógica de negócios que estão tentando preservar.

Nossas ferramentas de análise atuais, que decompõem a lógica embutida em segmentos menores, agora alimentam diretamente os sistemas de IA que podem transformar automaticamente os componentes de código que identificam. O que antes exigia semanas de conversão manual de código agora pode ser feito em horas, com frameworks de teste fornecendo a mesma validação rigorosa na qual sempre insistimos. Por exemplo, o Bendigo and Adelaide Bank reduziu o tempo de desenvolvimento para migrar um aplicativo bancário em até 90%. A diferença está na velocidade e em dimensionar, sem sacrificar a qualidade ou a segurança.

Figura 2. O processo AMP.
This process diagram begins on the left with Analysis, which is defined as decompose complex applications into small testable transformable steps. The analysis then goes to Test Generation, which is the generation of test coverage for each transformation step. From here, you go to Code Transformation, which is agent-AI code transformation with automated repair. Next is data migration, which is the redesign of the data layer for MongoDB. The final step is validation, where we validate functionality by comparing modern application against legacy.

Anos de engajamento com clientes e processos refinados fornecem a base e as diretrizes que tornam a modernização com IA eficaz e segura. Com o MongoDB AMP, a IA se torna um multiplicador de forças que transforma nossa abordagem comprovada em algo capaz de enfrentar desafios de modernização a uma velocidade e dimensionar sem precedentes.

A migração de código simples agora é de 50 a 60 vezes mais rápida, e podemos migrar pequenos aplicativos 20 vezes mais rapidamente para o MongoDB. Os testes de regressão também foram reduzidos de três dias para três horas com a geração automatizada de testes.

Fabrice Bidard, Head of Technical Architecture, Lombard Odier

Pronto para começar sua jornada de modernização?

A modernização de aplicativos legados não precisa ser um salto no escuro. Com o MongoDB como seu parceiro, você tem acesso a metodologias comprovadas, FERRAMENTAS testadas em campo e as funcionalidades aceleradas que a IA agente traz para a nossa experiência existente.

Entre em contato com nossa equipe para discutir seus desafios específicos e aprender como nossa metodologia comprovada pode ser aplicada ao seu ambiente.

← Previous

3 “Lightbulb Moments” for Better Data Modeling

We all know that feeling: the one where you have been wrestling with a complex problem for hours, maybe even days, and suddenly, it just clicks. It is a rush of clarity, a "lightbulb moment" that washes away the frustration and replaces it with pure, unadulterated excitement. It's the moment you realize a solution is not just possible, it is elegant. This blog post is dedicated to that feeling—the burst of insight when you discover a more intuitive, performant, and powerful way to work. We have spoken with hundreds of developers new to MongoDB to understand where they get stuck, and we have distilled their most common "Lightbulb Moments" to help you get there faster. We found that the key to getting the best performance from MongoDB is to adjust the way you think about data. Once developers recognize that the flexible document model gives them more control, not less, they become unstoppable. In this inaugural post of our new “Lightbulb Moments” blog series, we will walk you through three essential data modeling tips on schema validation and versioning, the aggregation pipeline framework, and the the Single Collection Pattern. These concepts will help you structure your data for optimal performance in MongoDB and lead to your own "Lightbulb Moments," showing you how to build fast, efficient, and scalable applications. 1. Schema validation and versioning: Flexibility with control A common misconception about MongoDB is that its underlying document model is “schemaless.” With MongoDB, your schema is flexible and dependent on the needs of your application. If your workload demands a more structured schema, you can create validation rules for your fields with schema validation. If your schema requires more flexibility to adapt to changes over time, you can apply the schema versioning pattern. db.createCollection("students", { validator: { $jsonSchema: { bsonType: "object", title: "Student Object Validation", required: [ "address", "major", "name", "year" ], properties: { name: { bsonType: "string", description: "'name' must be a string and is required" }, year: { bsonType: "int", minimum: 2017, maximum: 3017, description: "'year' must be an integer in [ 2017, 3017 ] and is required" }, gpa: { bsonType: [ "double" ], description: "'gpa' must be a double if the field exists" } } } } } ) MongoDB has offered schema validation since 2017, providing as much structure and enforcement as a traditional relational database. This feature allows developers to define validation rules for their collections using the industry-standard JSON Schema. Schema validation gives you the power to: Ensure every new document written to a collection conforms to a defined structure. Specify required fields and their data types, including for nested documents. Choose the level of strictness, from off to strict , and whether to issue a warning or an error when a document fails validation. The most powerful feature, however, is schema versioning . This pattern allows you to: Gradually evolve your data schema over time without downtime or the need for migration scripts. Support both older and newer document versions simultaneously by defining multiple schemas as valid within a single collection using the oneOf operator. db.contacts.insertOne( { _id: 2, schemaVersion: 2, name: "Cameron", contactInfo: { cell: "903-555-1122", work: "670-555-7878", instagram: "@camcam9090", linkedIn: "CameronSmith123" } } ) Performance problems can stem from poor schema design—not the database. One example from a financial services company showed that proper schema design improved query speed from 40 seconds to 377 milliseconds. The ability to enforce a predictable structure while maintaining the flexibility of the document model gives developers the best of both worlds. For a deeper dive: See an example of schema optimization in MongoDB Design Reviews: how applying schema design best practices resulted in a 60x performance improvement by Staff Developer Advocate, Graeme Robinson. Learn how to use MongoDB Compass to analyze, export, and generate schema validation rules. 2. Aggregation pipeline framework: Simplifying complex data queries In SQL, developers often use JOINs to aggregate data across multiple tables. As joins stack up, queries can become slow and operationally expensive. Some may attempt a band-aid solution by querying each table separately and manually aggregating the data in their programming language, but this can introduce additional latency. MongoDB's Aggregation Framework provides a much simpler alternative. Instead of a single, complex query, you can break down your logic into an Aggregation Pipeline , or a series of independent pipeline stages. This approach offers several advantages: Easier to debug: Each pipeline stage can be developed and tested independently. Visual query building: MongoDB's stage-based Aggregation Pipeline simplifies query visualization compared to SQL. Tools like the Pipeline Builder in Atlas and Compass make it easy to build complex queries with stages like $match , $group , and $sort , while analyzing performance in real-time. Fewer joins: The framework's design encourages a schema that reduces the need for joins in the first place, as data that is accessed together should be stored together. When you do need to pull data from another collection, the $lookup operator handles it easily. Figure 1. MongoDB Compass aggregation pipeline builder. The ability to decompose complex queries into independent stages is a powerful new experience that long-time SQL users will find far smoother. For more information and case studies, see: MongoDB official resources on Aggregation and Aggregation Operations . Take a free, one-hour MongoDB Skills course on Fundamentals of Data Transformation to learn how to build aggregation pipelines to process, transform, and analyze data efficiently in MongoDB. Aggregation Optimization in MongoDB: A Case Study From the Field (Part 1) by Staff Developer Advocate, Graeme Robinson. 3. The Single Collection Pattern: Storing data together for faster queries Many developers new to MongoDB create a separate collection for each entity. If someone were building a new book review app, they might have collections for books , reviews , and users . While this seems logical at first, it can lead to slow queries that require expensive $lookup operations or multiple queries to gather all the data for a single view, which can slow down your overall app and increase your database costs. A more efficient approach is to use the Single Collection Pattern. This pattern helps model many-to-many relationships when embedding is not an option. It lets you store all related data in a single collection, avoiding the need for data duplication when the costs outweigh the benefits. This approach adheres to three defining characteristics: All related documents that are frequently accessed together are stored in the same collection. Relationships between the documents are stored as pointers or other structures within the document. An index is built on a field or array that maps the relationships between documents. Such an index supports retrieving all related documents in a single query without database join operations. When using this pattern, you can add a docType field (e.g., book, review, user) and use a relatedTo array to link all associated documents to a single ID. This approach offers significant advantages: Faster queries: A single query can retrieve a book, all of its reviews, and user data. No joins: This eliminates the need for expensive joins or multiple database trips. Improved performance: Queries are fast because all the necessary data lives in the same collection. For developers struggling with slow MongoDB queries, understanding this pattern is a crucial step towards better performance. For more details and examples, see: Building with Patterns: The Single Collection Pattern by Staff Senior Developer Advocate, Daniel Coupal. Take a free, one-hour MongoDB Skills course on Schema Design Optimization . Get started with MongoDB Atlas for free today. Start building your MongoDB skills through the MongoDB Atlas Learning Hub .

September 15, 2025
Next →

Carrying Complexity, Delivering Agility

Resilience, intelligence, and simplicity: The pillars of MongoDB’s engineering vision for innovating at scale We’re relatively new to MongoDB— Ashish joined two years ago via the Granite acquisition after a decade-plus building Google’s databases and distributed systems, and Akshat joined in June 2024 after 15 years building databases at AWS. We have a shared obsession with distributed systems. We’d seen how much developers loved MongoDB, which is part of the reason we joined the company—MongoDB is one of the most loved databases in the world. So one of the first things we sought to understand was why. It turned out to be simpler than we thought: MongoDB’s vision is to get developers to production fast. This means making it easy to start, and easier to keep going—one command spin-up, sane defaults for day one, and zero downtime upgrades and zero downtime expansion to multiple clouds as you scale. That’s what developer agility looks like in practice: the ability to choose the best tools, move quickly, and to trust the system to carry the weight of failure, complexity, and change. At MongoDB, three principles drive that vision: resilience, intelligence, and simplicity. Resilience is the ability to keep going when something breaks, intelligence is the ability to adapt to changing conditions, and simplicity is reducing cognitive and operational load so users and operators can move quickly and safely. These are not just technical goals—we treat them as non-negotiable design constraints. So if a change widens blast radius, breaks adaptive performance, or adds operator toil, it doesn’t ship. In this post, we share the key engineering themes shaping our work and the mechanisms that keep us honest. Security as a first principle Security isn't a wall you build around your data. It's an assumption you design against from the very beginning. The assumption is simple: in a distributed system, you can’t trust the network, you can’t trust the hardware, and you certainly can't trust your neighbors. This starts with architectural isolation. In most cloud database service offerings, you're sharing walls with strangers. Shared walls hurt performance, they leak failures, and sometimes they leak secrets. We minimize shared walls, and where utilities must be shared, we build firebreaks. Stronger isolation reduces the blast radius of mistakes and attacks. With a MongoDB Atlas dedicated cluster, you get the whole building. Your cluster runs on its own provisioned servers, in its own private network (VPC). Your unencrypted data is never available in a shared VM or process. There are no "noisy neighbors" because you have no neighbors. The attack surface shrinks dramatically, and resource contention disappears. The blast radius of a problem elsewhere stops at your door. In other words, we follow an anti-Vegas principle—what happens outside your cluster will stay outside. But true security is layered. Once we’ve isolated the environment, we defend it from the inside out. We start by asking the hard questions: Who are you? That's strong authentication, from SCRAM to AWS IAM. What can you do? That's fine-grained RBAC, enforcing the principle of least privilege. What if someone gets in? That's encryption everywhere—in transit, at rest, and even in use with Client-Side Field Level Encryption . How do we lock down the roads? That’s network controls like IP access lists and private endpoints. And how do we prove it? That's granular auditing for a clear, immutable trail. Every one of these layers reflects defense in depth. Figure 1. Queryable Encryption. The history of database security is full of trade-offs between safety and functionality. For decades, the trade-off has been brutal: to run a query, you had to decrypt your data on the server, exposing it to risk. Queryable Encryption —an industry-first searchable encryption scheme developed by MongoDB Research—breaks this paradigm. It allows your application to run expressive queries, including equality and range checks on data that remains fully encrypted on the server. The decryption keys never leave your client. The server maintains encrypted indexes for the fields you wish to query on, and queries can be done entirely on the encrypted data, maintaining the strongest privacy and security of your sensitive data. By carrying these defenses in the platform itself, security stops being another burden developers have to design around. They get the privacy guarantees , the audit trails, and the compliance , without sacrificing functionality or velocity. Achieving resilience: Architecture, operations, and proof Systems don’t live in a vacuum. They live in messy realities: network partitions, power outages, kernel panics, cloud control plane hiccups, operator mistakes. The measure of resilience is not “will it fail?” but “what happens next?” Resilience is the ability to keep going when the thing you depend on stops working, not because you planned for it to fail, but because you planned for it to recover. Here’s how we achieve resilience. Architecture: MongoDB Atlas is built on the assumption that something may fail at any time. Every cluster starts life as a replica set, spread across independent availability zones. That’s the default, not an upgrade. The moment a primary becomes unreachable, an election happens. Within seconds, another node takes over, clients reconnect, and in-flight writes retry automatically. Single-zone diversity buys you protection against a data center outage. Adding more regions buys you protection against a full region failure. Adding more cloud providers buys you insulation against provider-wide events. Each step up that ladder buys you more protection against bigger failures. The trade-off is that each step adds more moving parts to manage, and the failure modes evolve: intra-region links are fast; cross-region introduce wide, lossy links; cross-cloud adds different fabrics, load balancers, and failure semantics. Figure 2. Resilience options: Single zone, multi-AZ, multi-region, multi-cloud. Our job is to make any type of failures (node failures, link failures, gray failures) invisible to you. Writes are only committed when a majority of voting members have the entry in the same term. That rule sounds small, but it’s the safety net that prevents a primary stranded on the wrong side of a partition from accepting writes it can’t keep. Heartbeats and UpdatePosition messages carry progress and truth; if a node learns of a higher term, it steps down immediately. When elections happen, the new primary doesn’t open for writers until it has caught up to the latest known state, preserving as many uncommitted writers as possible. Secondaries apply operations as they arrive, even over lossy links. Operating discipline: Resilience isn’t just in the code and architecture, it’s in how you operate it every day. Even the best design will fail without the discipline to detect problems early and recover quickly. You need to embed it in how you operate. Operational excellence is about preventing avoidable failures, detecting the ones you can’t prevent, and recovering quickly when they happen. And we’ve turned that into a discipline. Every week, the people closest to the work—engineers, on-calls, product managers, and leaders—step out of the day’s firefight to review the system with rigor. We celebrate the small wins that quietly make the system safer. We dig into failures to understand not just what happened, but how to make sure it doesn’t happen again anywhere. The goal isn’t perfection. Instead, it’s building a system where every lesson learned and every fix made raises the floor for everyone. A single automation can remove a whole category of incidents. A well-written postmortem can stop the same mistake from happening across dozens of systems. The return isn’t linear—it compounds. Figure 3. The ops excellence flywheel. When resilience works, failure stops being something every developer has to carry in their head. The system absorbs it, recovers, and lets them keep moving. Proof before shipping: Testing tells you that your code works in the cases you’ve thought to test. Formal verification tells you whether it works in all the cases that matter, even the ones you didn’t think to test. MongoDB is among the few cloud databases that apply and publish formal methods on the core database paths. This rigor translates into agility; teams using the database ship products without worrying about node failures, failovers, or clock skew, causing edge cases. Those edge cases in the database have already been explored, proven, and designed against. Figure 4. Formal methods. When we design a new replication or failover protocol, we don’t just code it, run a few chaos tests, and ship it. We build a mathematical model of the core logic stripped of distracting details like disk format or thread pools and ask a model checker to try every possible interleaving of events. The tool doesn’t skip the “unlikely” cases. It tries them all. Take logless reconfiguration . The idea is simple: MongoDB decouples configuration changes from the data replication log, so membership changes no longer queue behind user writes. But while the idea is simple, the implementation is not. Without care, concurrent configs can fork the cluster, primaries can be elected on stale terms, or new majorities can lose the old majority’s writes. We modeled the protocol in TLA+, explored millions of interleavings, and distilled the solution down to four invariants: terms block stale primaries, monotonic versions prevent forks, majority votes stop minority splits, and the oplog-commit rule ensures durability carries forward. For transactions , we developed a modular formal specification of the multi-shard protocol in TLA+ to verify protocol correctness and snapshot isolation, defined and tested the WiredTiger storage interface with automated model-based techniques, and analyzed permissiveness to assess how well concurrency is maximized within the isolation level. These models are not giant, perfect representations of the whole system. They’re small, precise abstractions that focus on the essence of correctness. The payoff is simple: the model checker explores more corner cases in minutes than a human tester could in years. Alongside formal proofs, we use additional tools to test the implementation under deterministic simulation: fuzzing, fault injection, and message reordering against real binaries. Determinism gives us one-click bug replication, CI/CD regression gates, and reliable incident replays—o rare timing bugs become easy fixes. Mastering the multi-cloud reality with simple abstractions Developer agility isn’t about having a hundred choices on a menu; it's about removing the friction that makes real choice impossible. One such choice that almost never materializes in practice is multi-cloud. We achieve multi-cloud by building a unified data fabric that lets you put your data anywhere you need it, controlled from a single place. A DIY multi-cloud database where you run self-managed MongoDB across AWS, Microsoft Azure, and Google Cloud seems simple on paper. In practice, it involves weeks of networking (VPC/VNet peering, routing, and firewall rules) and brittle scripts. The theoretical agility that you got by going multi-cloud collapses under the weight of operational reality. Figure 5. Multi-cloud replica sets with MongoDB. Now contrast this with MongoDB Atlas, where you don’t have to manually orchestrate provisioning across three different cloud APIs. A single replica set can span AWS, Google Cloud, and Azure. Provisioning, networking, and failover are handled for you. Your app connects with a standard mongodb+srv string, and our intelligent drivers ensure that if your AWS primary fails, traffic automatically fails over to a new primary in GCP or Azure without any changes to your code. This transforms an operational nightmare into a simple deployment choice, giving you freedom from vendor lock-in and a robust defense against provider-wide outages. Agility also means precise data placement for data sovereignty and global latency. Global Clusters and Zone sharding let you describe simple rules so data stays where policy requires and users are served locally, e.g., A rule to map "DE", "FR", and "ES" to the EU_Zone can guarantee that all European customer data and order history physically reside within European borders, satisfying strict GDPR requirements out of the box. Because Zone Sharding is built into the core sharding system, you can add or adjust placement without app rewrites. That’s real agility: the platform removes the hard parts, so the choices are real. From data to intelligence: Building the next generation of AI-powered applications Building intelligent AI-powered features has been a complex and fragmented process. The traditional approach forced developers to maintain separate vector databases for semantic search, creating brittle ETL pipelines to shuttle data back and forth from their primary operational database. This introduced architectural complexity, latency, and a higher total cost of ownership. That’s not agility. That’s friction. Our approach is to eliminate this friction entirely. We believe the best place to build AI-powered applications is directly on your operational data. This is the vision behind MongoDB Atlas Vector Search. Instead of creating a separate product, we integrated vector search capabilities directly into the MongoDB query engine. This is a profound simplification for developers. You can now perform semantic search—finding results based on meaning and context, not just keywords—using the same MongoDB Query API (MQL) and drivers you already know. There are no new systems to learn and no data to synchronize. You can seamlessly combine vector search with traditional filters, aggregations, and updates in a single, expressive query. This dramatically accelerates the development of modern features like RAG ( retrieval-augmented generation ) for chatbots, sophisticated recommendation engines, and intelligent search experiences. Intelligence isn’t something you bolt on. It’s something you build on. This is an area where we continue to make multiple enhancements. For example, with the acquisition of Voyage AI earlier this year, we are making progress towards integrating Voyage's embedding and reranking models into Atlas to deliver a truly native experience . We are also actively applying AI toward our Application Modernization efforts. Consider a relational database application that involves pages of SQL statements representing a view or a query. How do you translate it so it can work effectively with MongoDB’s MQL? LLMs have advanced enough to provide a base version that may be mostly the correct shape, but to get it accurate and performant requires building additional tooling. We are actively working with several customers, not only on the SQL → MQL translation, but also on modernizing their application code using similar techniques. What’s next? We’ll keep pushing on the same three levers: resilience, intelligence, and simplicity. Keep watching this space. We’ll publish deep dives similar to our TLA+ write-up on logless reconfiguration , covering formal methods and other behind-the-scenes work on hard engineering problems, such as MongoDB 8.0 performance improvement challenges . Our vision is to carry the complexity so developers don’t have to—and to give them the agility & freedom to build the next generation of intelligent applications wherever they want. For more on how MongoDB went from a “niche” NoSQL database to a powerhouse with the high availability, tunable consistency, ACID transactions, and robust security that enterprises demand, check out the MongoDB blog .

September 25, 2025