MongoDB(MDB)

As enterprise AI agent adoption scales, the absence of centralized, organization-level tool infrastructure is producing compounding costs. When adoption is built around optimizing for deployment speed, enterprises expose themselves to a combination of risks: duplicated engineering effort, security exposure, and operational opacity. Every enterprise needs its own shared tool registry, one that reflects its specific regulatory environment, security posture, and operational conventions. To be clear, this is not an argument for a public package manager, something like npm, PyPI, or Maven. The infrastructure each enterprise needs is internal; scoped to its own teams, its own data, its own policies, its own domain. Trying to expand the scope beyond the confines of individual organizations would be premature standardization in a fast-moving, nascent space. A shared enterprise tool registry is not an optimization or a nice-to-have. It is foundational infrastructure as agent deployments scale b

Today, we announced at .local London that MongoDB 8.3 is built for the speed AI demands—and our customers can't afford to wait. The data layer has to move at AI speed The old contract between databases and the applications on top of them was simple: databases improve slowly, and architectures evolve around them. AI has changed that contract. The workloads our customers are shipping today—agents retrieving at sub-100ms, retry storms hitting in milliseconds, multi-region deployments that can't trade compliance for latency—were edge cases 18 months ago. Now they're the baseline. MongoDB 8.3, generally available today, is our fourth significant release in 19 months. These releases compound. Customers running on 8.0 have seen 36% faster reads and 59% higher throughput for updates. 8.3 adds another 35% to write throughput, 45% to reads, and 15% to ACID transactions over 8.0 — without changing a line of application code. Enterprises like Adobe, running the most demanding AI in production, hav

This guest post comes from IDC’s Dr. William Lee, Senior Research Director, Service Provider and Core Infrastructure Research. MongoDB commissioned IDC to explore the connection between legacy infrastructure, data challenges, and AI across Asia Pacific, and today we’re happy to share that work. For more, see the full MongoDB-sponsored IDC InfoBrief, Modernizing Legacy: Winning in the Age of AI, Doc #AP242555-IB, April 2026. AI ambition is everywhere across Asia/Pacific. But ambition alone does not determine success. Organizations are discovering that AI outcomes are directly tied to the quality, accessibility, and modernity of their underlying technology stack and associated data technology foundations. Organizations that have managed to stay abreast of technical and data management changes across the application and infrastructure stacks, by embedding modernization into their organizational DNA, are experiencing 3x more digital revenue growth than those that are bound up in technical

You can often predict a load spike before it arrives. Maybe it happens at the same time every day, or there’s always a spike at midnight on a Friday when you run a certain batch job. Or maybe it’s not cyclical, but load is rising steadily, and it’s a reasonable guess that it will keep rising for a while. MongoDB Atlas’s reactive auto-scaler handles these spikes, but scaling to the right size takes several minutes. What if MongoDB Atlas could use these temporal patterns—cycles and trends—to scale up a replica set before it’s overloaded? In 2023, we prototyped predictive auto-scaling. We wanted to see if it was possible to predict rises and falls in load on MongoDB Atlas replica sets. We researched which machine learning models made the best predictions, and estimated how much a predictive auto-scaler could improve performance and save our customers money. MongoDB has now rolled out predictive auto-scaling. The production version of the algorithm is quite different from the prototype, an

Software engineering is evolving into agentic engineering. According to the Stack Overflow Developer Survey 2025, 84% of respondents use or plan to use AI tools in their development, up from 76% the previous year. At this rate, the tooling needs to keep pace. Last year, we introduced the MongoDB MCP Server to give agents the connectivity they need to interact with MongoDB, helping them generate context-aware code. But connectivity was only the start. Agents are generalists by design, and they don't inherently know the best practices and design patterns that real-world production systems demand. Today, we're addressing this by introducing official MongoDB Agent Skills: structured instructions, best practices, and resources that agents can discover and apply to generate more reliable code across the full development lifecycle, from schema design and performance optimization to implementing advanced capabilities like AI retrieval. To bring this directly into the tools you use, we're also

MongoDB is excited to announce the general availability of our enhanced data browsing experience in the MongoDB for Visual Studio (VS) Code extension. This new experience offers a unified workspace for developers to visually browse, query, and edit their data natively, streamlining workflows so they can manage their database right where they write their code. Evolving the developer workflow The modern developer’s workflow is incredibly fast-paced. With developers juggling an average of 14 different tools daily, the cognitive load of constantly jumping between applications can easily disrupt focus. When your application needs to evolve, working with your data shouldn’t force a break in your flow state. As the MongoDB for VS Code extension has grown to nearly 3 million downloads, we’ve seen firsthand how developers are pushing the boundaries of what an in-IDE (integrated development environment) database tool can do. While developers love accessing their data directly in the editor, we w

In high-stakes enterprise environments, outages do not wait for business hours, and neither do IT/Network Operators. A latency spike hits the dashboard, and metrics signal that the database is under pressure. The cause? Indeterminate. Meanwhile, the business impact is immediate: orders fail to process, customers can’t access accounts, transactions stall, and critical records become temporarily unavailable. Every minute of uncertainty translates into lost revenue, frustrated users, and escalating pressure. Teams often fall back on a familiar—yet time-consuming—ritual: logging into their data platform, exporting large log files, extracting compressed archives, and manually searching through thousands of lines of entries to identify the issue. What should be a quick diagnosis becomes a manual context-switching investigation. By the time the problematic query, configuration issue, or audit event is identified, users have already experienced the disruption—and the business has absorbed the

Nestled between the Irish Sea and the Wicklow Mountains, MongoDB’s Dublin office brings together people from around the world. It’s a place where you can build a meaningful career, contribute to leading global products, and feel part of a close-knit community. Located in Ballsbridge just south of Dublin city center, the office is a short walk from the Lansdowne DART station and is well-served by multiple bus routes, making it easy to plug into everything the city has to offer. Image of a wall in the MongoDB Dublin office that is painted with Dublin relevant illustrations and text that says "Build together" and "Make it matter" As MongoDB’s international headquarters, Dublin is a key hub where over 300 employees from more than 40 nationalities own critical parts of the company’s products and support customers running mission-critical systems across the globe. Established in 2012, MongoDB Dublin has long played a pivotal role in helping the company achieve its mission

In our previous post, we talked about our process of specifying MongoDB’s distributed transactions protocol and how it enabled novel analysis of its performance characteristics. In this follow-up, we talk about how the modularity of our specification also enabled us to check that the underlying storage engine implementation actually conforms to the abstract behavior defined in our formal specification. That is, we are able to formalize the interface boundary between the sharded transaction protocol and WiredTiger, the underlying key-value storage engine, and develop an automated way to generate tests for checking conformance between the semantics of the underlying storage engine layer and this abstract model. As mentioned in the previous post, a deeper exploration of the concepts covered in this post is covered in our recently published VLDB ’25 paper, Design and Modular Verification of Distributed Transactions in MongoDB. Modular, Model-Based Verification As discussed in Part 1, we ha

Who says that winter is when things slow down? MongoDB has had a busy start to the year, with a steady stream of announcements and product features—all against the backdrop of an industry moving at warp speed. It's been a lot, and it's been a blast! For example, the energy at January’s MongoDB.local San Francisco—where we announced capabilities to help teams ship production AI faster—was infectious. MongoDB isn’t just starting a new chapter in AI; we’re rewriting the book in real time. The next generation of AI companies isn't just looking for a temporary place to store data; they’re looking to build on a generational modern data platform. Indeed, the most innovative founders are moving away from rigid, legacy systems and embracing a single, fluid foundation that can grow with them. At MongoDB.local SF, our message was clear: Choose your data platform strategically in order to ship faster. From our new Voyage 4 models to the general availability of our Intelligent Assistant, we are obs