Month: March 2025

Posted on mongodb google news. Visit mongodb google news

The MongoDB PHP team released version 5.2.0 of the Laravel MongoDB integration.

#Highlights

#Laravel 12 support

• Compatibility with Laravel 12 ensures you can leverage the latest features and improvements in the Laravel framework while using MongoDB.

#Enhanced search capabilities

• Atlas Search: Atlas Search is an embedded full-text search in MongoDB Atlas that gives you a seamless, scalable experience for building relevance-based app features. Built on Apache Lucene, Atlas Search eliminates the need to run a separate search system alongside your database. The release provides native integration by including new createSearchIndex() and search() methods in the schema builder and query builder. The Laravel integration also provides the autocomplete() method to the query builder and Eloquent models. You can use the autocomplete() method to run autocomplete searches on documents in your collections.
• Vector Search: Vector Search allows you to query your data based on semantic meaning rather than just keyword matches, which helps you consider the searcher’s intent and search context to retrieve more relevant results. It enables your AI-powered applications to support use cases such as semantic search, hybrid search, and generative search, including RAG. Similar to Atlas Search, this release provides a native integration for Vector Search by adding a new vectorSearch() method in the query builder. Vector search indexes can be created using the createSearchIndex() method.

#Laravel Scout support

• Use MongoDB Atlas as a search engine with Laravel Scout. This integration provides an abstraction to create Atlas Search indexes from any MongoDB or SQL model.
  Note: If your data is already stored in MongoDB, using Scout is not required. You can create a search index directly on any collection that is managed by an Eloquent MongoDB model.
• It also enables you to automatically replicate data from MongoDB into a search engine such as Meilisearch or Algolia. You can use a MongoDB Eloquent model as the source to import and index.

#Read preference configuration

• You can now specify read preferences directly in the query or aggregation builder. This feature allows directing read operations to specific replica set members by setting preferred read preferences.

#Optimized session management

• An optimized session driver has been added to store sessions in MongoDB efficiently. This enhancement includes a new “mongodb” session driver to facilitate seamless session management within your applications.

#Compatibility updates

• MongoDB Extension 1.21: This release requires updating your MongoDB extension to version 1.21.
• Deprecated support for MongoDB 4.0: Future versions will require MongoDB 4.2 or later, as support for MongoDB 4.0 is now deprecated.

#Installation

This library can be installed or upgraded with:

composer require mongodb/laravel-mongodb:^5.2.0

#Resources

Documentation and other resources to get you started with Laravel and MongoDB database are shared below:

Give it a try today and share your thoughts! They welcome feedback on this release in the GitHub discussions, as they continue to enhance the integration.

Article originally posted on mongodb google news. Visit mongodb google news

Article originally posted on InfoQ. Visit InfoQ

Introduction – Partially Stateful Streaming Dataflow

Marzoev: I’m Alana Marzoev. I’m the co-founder and CEO of Readyset. In this talk, I’m going to be telling you about how you can use a computational model called partially stateful streaming dataflow to build a high-performance SQL cache. Partially stateful streaming dataflow is a relatively new concept that was introduced by the computer systems research community a few years ago.

The main idea is that you can represent SQL queries as these long running computational graphs, and stream data change updates through the graph to incrementally update the result that the graph emits. At Readyset, we’ve been using this computational model to build a transparent database cache that has a performance profile that’s on par with a hand-optimized, custom caching system, but that helps to alleviate a lot of the burden that you typically see with caching, so specifically around having to come up with a cache invalidation policy, rewrite your application, all of that stuff.

Roadmap

I’ll start off by talking about the problem domain that we’re going to be working within in greater depth, so you can get a sense for both the use cases and the workloads that we’re ultimately solving for. Then from there, I’m going to do a deep dive into what I call dataflow-based caching. The way I’ll approach this is by starting off by showing you a demo of Readyset in particular. You can think of it as a standard replacement for any dataflow-based caching system.

From there, I will describe what you just saw. I’ll start off by going into the interface and the specific design decisions that we made there, and how they affect the usability and programmability of this caching system. From there, I’m going to walk through the life of a query, and this will give you a better understanding of the system architecture and how requests flow through that system. Finally, I’m going to do a deep dive into dataflow. I’ll introduce what dataflow is.

Then from there, I’ll show how we can specifically apply these concepts to the land of relational databases, and how we can specifically solve cache staleness issues in an automated way using dataflow. Finally, I’m going to more explicitly walk through some of the alternative approaches that people use today to address database scaling. I’ll discuss how we see dataflow-based caching relative to these alternatives, so you can get a sense for when it’s appropriate to use and when it might not be.

Problem Domain

Without further ado, problem domain. Imagine you’re building a new web application, and at the moment, it doesn’t really have any users. It’s just you, so your goal is to get users. When you think about how you approach development in this context, the thing that you’re going to be optimizing for is reducing iteration time. If your goal is just to try out a lot of features, see what sticks, you’re not going to do anything particularly fancy with your tech stack to enable that. You’re probably going to pick a programming language that you’re already intimately familiar with. You’ll use the web framework that’s associated with that language.

Then for your database, you’re not going to do anything fancy. You’re probably going to just pick a vanilla, standard relational database hosted by a hyperscaler like AWS. Let’s say that some time passes and all of your hard work and efforts on feature development start to pay off, and suddenly you get this influx of users that you were looking for. Although this is objectively great, given your goals, it actually leads to a new set of technical challenges, most of which are at the database layer.

Concretely what tends to happen in situations like these is you haven’t spent a lot of upfront time optimizing your queries, adding indices, anything like that. When you start to see this influx of traffic, sometimes this mass of users will lead to a large number of queries being run simultaneously, so there’s a lot of contention in your database. That could lead to both slow queries, aka slow page load times, which could lead to churn, and in the worst case, database outages, just because your database has not been provisioned appropriately to solve this problem.

What specifically is happening here that makes it hard for your database to keep up? User facing applications as a broad group are really quite latency sensitive. Because there’s humans on the other end of the screen that are waiting for results, and because modern day ORMs tend to autogenerate large numbers of queries, and also inefficient queries, then a single page load could require running sometimes dozens of SQL queries behind the scenes, and page load times will be bottlenecked by the slowest of the batch. In this context, it’s really important that your tail latencies are always quite low, which is challenging with off-the-shelf databases. The other dynamic at play here is there tends to be a lot of variance in traffic.

The canonical example of this in the U.S., at least, is Black Friday. It’s the day after Thanksgiving. There’s all of these big sales, and truly companies will spend the rest of the 11 months of the year just capacity planning for this day because it’s such a big revenue generation day. You see the same dynamic at play at smaller scale. Let’s say you’re Airbnb, you could totally imagine it being the case that in certain seasons and specific regions, there’s an uptick in bookings because it’s summer vacation season, or something like that. Same could be the case with a B2B SaaS type of situation where you’re going to see the most user sign-ins on Monday through Friday during business hours. There’s a lot of fluctuations, and you have to plan accordingly.

The last is that these types of workloads that are associated with user facing applications are both read-heavy and have quite skewed data access distributions, and this is something that we could actually leverage. Pay extra attention to this one. On the read-heavy side, that’s exactly what it sounds like. There’s more reads than writes. That makes sense with our mental model of the world. When you’re going on a website, the vast majority of the time you’re not going to be actively changing the data, you’ll just be consuming it. That tends to be the case across this broader category. Similarly, the data distribution, or the data that we’re accessing is not uniformly distributed.

Normally, popularity is a dimension at play, and also how recent the content was created. If you think about a forum, for example, the front page of Hacker News, and it’s the most popularly voted forum entries. The vast majority of people that visit Hacker News are going to go just to the front page, not to page 103. Then, moreover, the vast majority of things that are posted to Hacker News never see the light of day. They briefly show up on the new page and then no one ever sees them again.

The way that people in this world like to describe that distribution is the Zipfian distribution, which is governed by Zipf’s Law, which is that, generally speaking, the nth most common term in the set is 1 over n times as popular as the most common term. You can see a visualization of that here. In the context of Hacker News, it could be the case that the second most popular entry is half as popular as the top thing on the front page of Hacker News, and so forth.

Let’s say that with all of this context in mind, you’re now starting to solution. You’re like, my database is falling over. This is an urgent problem. How am I going to approach scaling things? The first thing you’re going to try is probably just vertically scaling. You’re going to get a bigger box to run your database on, and hopefully that gets you at least something, because there is some contention that there’s a lot of queries being run simultaneously. It’s a reasonable first step, but it tends to not fully solve the problem, because, as I mentioned, nowadays, the vast majority of companies are using ORMs, which specifically abstract away the database for you. That’s kind of the point. It’s really nice from a usability perspective. A lot of the queries that they generate tend to be quite unnatural, quite inefficient, and there tends to be more of them than what’s necessary.

Given that, oftentimes just adding more cores won’t actually get you the latencies that you really need, given that page load times are bottlenecked by this. From there, you might think, now let’s take a look at what the queries I’m actually running are, and try to optimize them. That is also a perfectly reasonable solution. What we find is that a lot of people, you’re not even aware of the specific queries that your application is generating due to this ORM obfuscating things, and then they tend to be more challenging to optimize if you even have that skill set. It’s not a given that every application engineer is going to know how to optimize SQL queries. That’s a pretty domain specific thing.

Given that, one of the next solutions that you’d go to is caching, because given that it’s a read-heavy, skewed data access distribution, that has caching written all over it. Typically, what this look is you have a standalone in-memory key-value store off to the side of your database. You essentially will run the queries against your database and then store them in this in-memory key-value store, such that the next time a user comes along and requests that same entry, they’ll be there in memory. You just do a key-value lookup, and it’s really fast.

There’s a lot of different strategies for caching, but one of the most common ones, and the one that I’m going to talk primarily about is read-through caching, which is quite simple. The main idea is that, you’re always going to check the cache first to see if the thing that you’re looking for is there. If it’s not, the cache is going to trigger the query that would populate that result against the database, and then it would cache it locally before returning it to the end user, or the application that requested it. Let’s think through what our code looks like before and after introducing read-through caching. For context, this is just a random code snippet I found from a Python, SQLAlchemy, and Redis caching tutorial, but it’ll illustrate my point.

This function here, is just fetching a user from the database that’s opening up a session, using SQLAlchemy to generate the query, to pull the user info, and then just returning the user data. It’s as simple, as simple can be. This is what your code starts to look like after caching. As you can see, there’s twice as much of it for the same underlying function. The concrete new thing that’s here is this get_user_from_cache function, which is implementing the read-through logic that I previously just described. You take a look at this, and you’re like, there is another helper function. Obviously, this is just one of the places where I might want to start caching. If there’s a lot of them in my app, it’s annoying to add these helper functions. I don’t want to do that. Maybe at the end of the day, it’s not the end of the world. We can write helper functions.

The question is like, is this it? Is your caching problem solved? Are you done with this code addition? The answer to that question is, unfortunately, no, simply because cache invalidation tends to get really messy. Concretely, in every point in the application where you want to introduce caching, you have to really sit down and think through what the user expects from you for that functionality, essentially. Then from there, you have to design a cache invalidation policy that aligns with those user expectations, and implement it. To make that a little bit more concrete, let’s say you have these two settings.

The first is a Facebook News Feed, and the other is a shopping cart in an e-commerce application. In the Facebook example, let’s say that you are a user of Facebook, and so are your friends, and your friend goes to brunch and posts a photo from their brunch at some time point t. Let’s say you don’t see that until t plus 5. Five minutes have gone by, there’s no update from your friends. In the vast majority of cases, you’re going to be none the wiser. Unless you’re truly sitting next to your friend and they asked you, do you see my Facebook post? You’re not going to know that there’s a 5-minute delay between when your friend posted the photo and when you saw it.

In this case, it’s easier to cache, because you don’t have to think too hard about making sure the cache is up to date and returning fresh results to the user. Contrast that to the e-commerce example. Let’s say that you are just trying to buy a t-shirt on the internet, and you’re on an e-commerce site. You add it to your cart, and it takes 5 minutes for it to show up in your cart, and you’re ready to check out. You’re not going to wait 5 minutes under the hopes of like, I want this shirt to show up in the shopping cart. You’re going to go on Amazon, or just buy it elsewhere. These are two examples where the expectations from the user are really quite different in terms of how fresh the data needs to be, and that is going to inform your cache invalidation policy.

Right now, with caching, you have to write a lot of bespoke code for cache invalidation. There’s no automated way of doing this in the general case. You could choose something as simple as a TTL. Maybe every 5 minutes your cache entries get purged and you have to re-request all the data. Or you could do something extremely complicated and sophisticated, where you could be tracking the specific tables that are referenced in the query that’s being cached and trying to gauge, this one was updated, and therefore this cache entry likely needs to be recomputed and so forth. The world is your oyster there. There’s this fundamental tradeoff that I think it’s really important to highlight, where on one end of the spectrum, it’s like, you’re rarely ever evicting.

This is good for your cache hit rate, because when your application checks to see if an item is in the cache, it’s always going to be there because you’re rarely evicting, but in all likelihood, your data is going to be extremely stale, and so it’s not going to be appropriate. It’s not going to align with expectations of your users. On the other hand, let’s say that you’re evicting all the time because you’re like, I really need the data to be fresh. I want to provide the best user experience. Then, at that point you might as well not be using a cache at all, because you’re never really leveraging it. Figuring out exactly where on this tradeoff curve you want to live is a hard problem.

I’m sure many of you have heard this quote, “There are only two hard things in computer science, cache invalidation and naming things”. This quote is referencing this general dynamic of, caching at a high level, it’s super simple. It’s like you’re just precomputing a result set, storing it in memory. What is there to know about that? In reality, it’s actually quite messy. It’s really easy to introduce bugs. Let’s say that you have sat down, you’ve thought through the user expectations. You’ve designed an invalidation policy, and now you just have to write the code to do that. That code itself could actually be quite nuanced.

Concretely, you could accidentally introduce a distributed systems bug, like a thundering herd, where you are evicting a popular cache entry unintentionally, and that’s triggering a storm of database queries against your database, which wasn’t provisioned accordingly. Then that takes it down, which, again, at that point, why are you caching? You’re making your own problem worse and shooting yourself in the foot. When I take a step back and think through a cost-benefit analysis of caching, this is what I would broadly come up with. On the pros side, you get the best-case query latencies when you get a cache hit rate. Because you are doing all of the work before, and all you’re doing when you’re doing a read is an O(1) lookup into an in-memory, lock-free data structure. Caching asymptotically doesn’t get better than that.

Similarly, there’s a much more straightforward path to scaling, as opposed to sharding your database. Making your cache scale horizontally is a lot easier than making your source of truth scale horizontally. There’s a lot of drawbacks as well. You have to rewrite your application, which is already not ideal. Caching is quite error prone. There’s three different places at least we can get it wrong, like the user expectations level, the cache invalidation policy level, and the actual implementation. When you do make a mistake, bugs are quite obvious to the end user, or otherwise they could take down your database. The stakes are really high, and you don’t have any isolation between the cache and the database. That would lead you to potentially pause and think, do I really need a cache? Only if you really needed it, would you proceed with this plan.

If we were to wave a magic wand and elucidate specifically what we would want from an ideal caching system for this purpose, I think it would look something like this. One is, we wouldn’t have to rewrite the application. Ideally, we’re able to start caching in a way that is non-intrusive, doesn’t take a lot of engineering time, and so forth. Two is that we wouldn’t have to think so hard about cache invalidation and worry about staleness concerns, because, as I just described, it’s a pretty fraught process, and it’s really easy to make mistakes. Then, finally, the cache should absolutely never make things worse, because presumably you’re adding this to your stack, because you’re already in a bit of a pickle when it comes to databases falling over and so forth, and you really just don’t want to be making it worse by trying to make it better.

Dataflow-Based Caching: Demo

With all of that in mind, I’m going to introduce dataflow-based caching. I’m going to start off with a demo, so you can get a sense for what it actually looks like and feels like, and we can go from there. For context, we are working with an IMDb dataset, which is a real dataset that’s available on the internet, that’s scraped from the IMDb website, the movie ratings website. We are going to try to cache a query, which the natural language interpretation of is, how many movies filmed after the year 2000 had over a 5-star rating on IMDb? Behind the scenes here we have a Postgres database in a Docker container, and we have a Readyset instance. A Readyset is like this example of a dataflow-based cache. Right now, we are going to connect to the cache, and we’re going to connect to it using psql. You can see this connection string here, says Readyset in it. I’m going to go ahead and do that.

Then from there, I’m going to turn on timing so that we can see how long queries take to run. The query that I just told you about, where we’re trying to see how many movies had a rating of over 5 after 2000 is right here. I’m going to start off by just running that against the underlying database. We can see that that took 173 milliseconds, and it returned the answer, 2418. There are 2418 movies that fit that criteria. You can see, I just typed the statement, show caches. There’s currently no caches that are set up in the system. We’re going to go ahead and create one by typing in, create cache from, and then I’m going to copy and paste this query string. We can see now the cache presumably was created. We can see that that was created. Now we’re going to run the same query again, and the first time we run it, it’s going to be a cache miss.

The cache started off empty, we’re warming it up. We run it a few times, and then we can see, now we’re in business. Now it’s taking 0.75 milliseconds as opposed to 50. That’s fairly consistent. That’s pretty cool. Now what we’re going to do is essentially issue a write that should change the result that’s being returned. In this case, I’m going to say, there’s this one movie that I liked from 2003 that everyone else hated, so I think that one deserves a rating over 5. The public doesn’t agree, but I’m going to change it such that that’s the case.

Then that should presumably change the query result that we see. Let’s see if I can find that update. Right now, the rating is 2.5. I’m going to change it to 5.1. Now I’m going to run the query again. We can see, all of a sudden, the result has been refreshed. Before was 2418, now it’s 2419. Notably, the time that it took to get the state from the cache didn’t change. We didn’t just evict and recompute, because if we evicted and recomputed, it would take 50 milliseconds again. In this case, it’s just the new result, but it’s still a cache hit.

Dataflow-Based Caching: Interface

How does all of that work? That’s going to be the rest of the talk. Let’s start by talking through the interface, because that’s the most tangible part of what we just saw. We saw how to interact with this. Let’s make the decisions that we made there a tad more explicit. The first thing to know is this cache is set up as a read replica. When you start up Readyset, it is going to snapshot the tables in your database that are relevant for caching. Concretely, if you’re trying to cache two queries and they’re referencing tables A, B, and C through them, but you have 500 tables in your database that aren’t A, B, and C, then it will only snapshot the tables that you actually need for caching, so A, B, and C. Then from there, it’s going to maintain a replication slot on your primary database so that it can get the row changes that are being replicated from your database to automatically and incrementally update the cache state.

The specific way that this works will vary depending on the database. Readyset in particular supports Postgres and MySQL. In Postgres, this is logical replication. MySQL is row-based replication. The next thing to know is that it’s wire compatible with Postgres and MySQL. That’s what we saw in the demo. I was using the psql client to connect to a Readyset connection string. The goal of doing that is to prevent you from having to make large changes to your application to start using a cache. This is an ergonomics related feature.

Of course, under the hood, Readyset does not yet support all of the features of the underlying database, it just looks like one at the surface level, and it has a subtly different SQL dialect. By and large, you shouldn’t have to worry about that, because for most of the things that you’re caching, which are going to be SQL-92 type queries, like relational algebra type computations, that shouldn’t be an issue. If in your application you’re already using SQLAlchemy, or Django, and Rails, you shouldn’t have to change your application code in any meaningful way.

The next thing that I will point out, which you also saw in the demo, is that caches are specified explicitly. We have the DDL equivalents for cache management, so creation, deletion, and so forth. This wasn’t obvious from the demo, but specifically, we’re caching prepared statements, which you can think of as being parameterized SQL queries. If you have two queries that are structurally the same, they’re operating over the same data, they’re running the same computations, but the only difference is the literal in one. Let’s say the user ID that you’re asking for is 3 and the other is 5, then those are actually considered to be the same query within Readyset, and it’s going to be handled by the same cache and the same dataflow graph, which I’ll be explaining in a later section.

The next thing and last thing is that, any queries that aren’t explicitly cached will be, by default, proxied to the primary database. The same goes for writes. Readyset never tries to apply a write that you send it within the cache first, it’ll just forward it along to your database and wait for that write to show up in the replication stream later on, and then from there, it will use that to incrementally update the cache state. The reason that we chose to do this is that, it gives you fine-grained control over what’s cached or not, which is desirable, because sometimes you don’t want to cache something. Sometimes you’re running a bank transaction, and we know that we don’t want to cache in bank transactions.

Sometimes it’s just not economical to cache because maybe you’re just not running that query so much, but to get a high cache hit rate, you have to use a lot of memory. Maybe you just don’t want to. At the same time, it’s also not always desirable to have to manage multiple read-write connection strings. If you already have the infrastructure set up for read replicas, and you have reads and writes split out, then you can totally adopt it in that way. If you don’t, then you don’t have to. You can still just use a singular database connection and have the functionality be unchanged. Your app will still work, but you can still have this fine-grained control over what’s cached or not.

Dataflow-Based Caching: Life of a Query

Now I’m going to walk through the life of a query. The way I’m going to do this is by starting off with a bird’s eye view of the architecture. I’ll quickly talk through what’s happening here. Then we’ll step through a bit more carefully all the different components for both setting up a cache and for actually serving traffic from the cache that we just set up. Here’s architecture. Broadly speaking, there’s the application server up on top, which is essentially unchanged. It’s as though you’re not using a cache at all. You have the business logic, which is presumably utilizing ORM. The ORM, in turn, is using a database client to actually connect to the database and issue the queries against it. In this case, instead of connecting to the relational database directly, it’s connecting to the Readyset adapter. Within the Readyset adapter, there’s different components.

The first one that it speaks with is like the SQL shim, and it’s responsible for decoding from the binary protocol of that database into just the text that we need to essentially create an internal representation of that query. Then once we have that internal representation, the Readyset client is going to be deciding whether or not that should be sent to the primary database or if it should be sent to the Readyset server. If it is sent to the Readyset server, then the query will be resolved within a component called the reader.

Then, behind the scenes of all of this, your database is getting writes. Those data changes are being replicated to the Readyset server and being handled by a component called the replicator, which is updating the local copy of the base tables that I mentioned that we snapshotted before. Then emitting those row changes through the dataflow graph, which will be ultimately responsible for keeping the cache state in the readers up to date.

I’m going to talk through that in greater depth. We’ll start by describing how we set up the cache. At this point in time, I’m assuming that we’ve already created a Readyset cluster or instance, and it gave us the database connection string that we can use. The first thing that we want to do in our application is swap out the database URL that was previously pointing at your primary database to now point to this Readyset instance that is connected to your primary database. Again, this is describing the approach of using Readyset as a full proxy as opposed to a read replica. Both are options. It’s just a matter of what works best in your setting. The specific place in the code that you’re going to actually change this URL is going to depend on the programming language you use, the framework you use, but typically it is just swapping a connection string.

From there, you as developer need to decide which queries you want to cache. There are a lot of different ways that you can imagine doing this, either by looking at your database is slow query logs. If you’re using an APM, like Datadog, or whatever, you can check that as well. In Readyset itself, we offer some basic heuristics to help you decide as well, so things like total CPU time that that query is taking up in your database, the count, how bad the tail latencies are, that sort of thing. You have to take a look at that, and then from there decide which queries you want to cache. Once you have a list in mind, you have to go ahead and actually create those caches. You do that via the DDL-esque SQL extensions that I showed you before, like the create cache from, and then the query string or query ID. Then that will trigger a migration within Readyset to construct the dataflow graph, which is going to be responsible for keeping the cache up to date.

That process of creating the cache, it’s not going to be instantaneous. It could be really fast. It could take a few minutes, depending on how big your tables are, what indices we have to create behind the scenes, and so forth. It will let you know once the cache is ready to start serving traffic. Now let’s talk through the actual life of a query part of this. Let’s say a user requests some data, which translates to an application server, or in app logic, a query is being generated.

Again, the application is connected directly to the Readyset adapter. In this context, we’re just continuing to use the ORM and proxy everything through Readyset. That’s going to get sent to first the SQL shim, which is going to be responsible for decoding the binary representation and then converting that into this generic internal representation of the query that is the same across all database variants within Readyset. Think of this as the relational algebra representation of the query. Then that internal representation is going to be passed to a component called the Readyset client. From there, the Readyset client is going to be pattern matching this string or representation against the caches that it knows are stored and are created in Readyset server. If there’s a match, and remember, we’re doing this at the level of prepared statements, so we’re ignoring any differences in literals. We’re just looking at the queries in a structural way.

Then that’s going to be sent to the Readyset server, to the reader nodes, and if not, it’s going to be proxied to the database. The database will compute the result and return it to the application. Then, in the background, the cache is continuously being refreshed in an eager way. Concretely, let’s say you’re sending writes to your database, those are being reflected in the replication stream. The replication stream is being sent to the component within the Readyset server called the replicator, and it’s going to receive those data changes. It’s going to update the local copy of the base tables to reflect those changes. Then it’s going to propagate those changes through the dataflow graph. By doing that, the dataflow graph is able to compute an incremental update over the old cache state to reflect this new data change. Then it’s going to swap out the old version in the reader, which is the cache, for all intents and purposes, with this new, updated version.

Dataflow-Based Caching: Solving Staleness with Dataflow

In this walkthrough, dataflow was a black box. I’m going to spend the rest of the time talking through how this fancy incremental update mechanism actually works, because, in my mind, that’s the cool part. Concretely, as I just alluded to, we’re going to be figuring out how to solve cache staleness issues in an automated way using this mechanism. I’ll start off by just explaining what dataflow computing is. Dataflow is just generally a very overloaded term in computer science, but the version that I’m referring to is dataflow computing, which is also known as stream processing in a lot of cases.

The main idea is that you can represent computations as directed graphs where the nodes of the graph are considered to be operators that perform those computations over incoming data. Then data is flowing through the edges into these operators. I have this little figure here, it’s an arithmetic example. Let’s say that our goal was to compute x times y plus z. What this would look like is, you have this graph where the nodes of the graph are the computations. There’s the multiplication operator, and then there’s the addition operator. Then the inputs of the graph are the data that we’re inputting, so x, y, and z. You can see that x and y are inputs into the multiplication operator. They’ll go to the multiplication operator. The multiplication operator will multiply those two together, and then it’ll emit the result x times y out of its outgoing edge, which is leading into the addition operator.

Then the addition operator will add x times y, which it got from its parent node, to z, which is the other input into the graph, and then emit the result. One way that I like to explain this idea is in contrast to batch processing. Where, typically, when at least I think about running a computation over a dataset, essentially, you have a dataset, and then you run some compute over it.

Presumably, you’re ingesting data for some time period. The data is accumulating. Then at some point in time you’re like, let’s run this computation. There might be some delay between when the last data point was updated, or the delay between the most recent version of the dataset and the response that you’re giving. If you contrast that to stream processing, in stream processing or dataflow computing, you are continuously ingesting data, and you’re continuously running some, in many times, like incremental computation over that data to compute a response that is eagerly made, up to date.

Now let’s talk about how we can represent SQL queries as dataflow, to bring this back to the domain that we were just talking about. In this case, the nodes of the graph which are again representing the computations, are just relational algebra operators. To name a few, like SELECTs, PROJECTs, JOINs, and so forth, it almost looks like a query plan, if you’ve seen those. Then, the data that’s flowing through the edges are these row updates coming from your primary database through the replication stream. Those updates are propagating through the graph. The relational operators are computing the changes over those and emitting the results.

By the time you have the final output, that’s the query result that we are looking for. I’m going to make this more explicit with an example. I already talked a little bit about Hacker News. It’s a forum for developers. People will post things. Most of the things that get uploaded make it to the top page. Let’s say that, just for the sake of this example, we’re only dealing with two tables. There’s a stories table, which has the story ID, the author of the story, the title, and URL.

Then there’s the votes table, which has just a mapping of which users voted for which story IDs. Let’s say, in an attempt to write a query that generates the content on the front page, we’ll have this, and the natural language interpretation of this is essentially return the story content and metadata for that story, along with the vote count for the story with ID x. It’s just doing a join and joining the story info with the vote count for that story, and it’s parameterized on the story ID, so it’s a prepared statement. The way that we would represent this as dataflow would look something like this, where you have the base tables which are stored locally on disk.

Then, in the actual dataflow graph itself, you have a count group by node which is receiving input from the votes base table. Then there’s the stories base table node which is feeding into the join node. You see the join node has another input coming in from the count group by. Finally, that’s storing the cache results in the reader.

Let’s talk through how writes look in this world to make this a little bit more dynamic and complete. Let’s say that Justin upvotes story with ID 2. That’s going to be reflective of a row insert into the votes base table. Justin votes for story 2, that’s going to propagate through the dataflow graph. As you can see, the outgoing edge from this base table is into the count node. The count node is going to receive that update, and it’s going to take the prior vote count, which was 580, and increment it by 1 to reflect the fact that there’s now one more person that voted for this story. Then it’s going to emit that new vote count into the join node. The join node is going to be like, I have this new vote count. Let me update the result of the join for story ID 2 to have this new vote count, 581.

Then, finally, let’s make that available for consumption by users and update it in their reader node, which is where we’re serving all of our traffic from. Now to walk through a read. Let’s say that now we’re trying to get all the story data and vote count for story with ID 2. That’s going to just look like the query that we were just looking at before. Now, instead of being parameterized, we’re passing in the parameter too and executing the prepared statement. To perform this read, all you have to do is a key-value lookup for ID 2 in this reader node, which is just an in-memory data structure that’s storing all of the cached query results. It’s pretty on par with normal caches in that regard.

Let’s talk about how efficient this approach is as currently described, because that’s going to be really important. I’ll start by comparing read efficiency. I just alluded to this. Essentially, in both types of caches, like in the one where you just have an in-memory key-value store, and you’re evicting and recomputing and all of that. Then in this version, where it’s like a dataflow-based cache, all you’re doing is this very fast lookup into an in-memory, lock-free data structure. You get the same performance, slight code differences aside, in both contexts. Now let’s compare cache update efficiency. Again, with “traditional caches”, like this in-memory, key-value store-based model where you’re running queries against the database, storing it in the cache, and so forth. Whenever you want to invalidate the cache and update it, you are going to evict and then recompute the missing state. This recomputation could be pretty expensive. It won’t necessarily be.

Presumably, the reason you’re introducing the cache is because you’re running this computation all the time, or perhaps it’s like a complex query, so the fact that you have to invalidate by removing the state from the cache and rerun against your database could take quite a while, and that’s going to reduce your cache hit rate, because those are all going to be cache misses. With dataflow-based caches, things are different, because you aren’t ever evicting and recomputing to update the cache. You’re incrementally updating it, which tends to be a lot less compute intensive, because you’re not throwing away the old value entirely. You’re saying, I have the old value.

Then, some small amount of the data has changed since we last looked at the old value, so let’s just reuse that old computation and then just figure out how to update the old computation to reflect just these new data points, as opposed to starting from scratch. You’re doing this all within the context of the cache. You’re never running a query against your database to update the state and make it fresher, because we have the local copy of the base tables, all of that is just being resolved within the cache itself.

Now let’s talk about memory overhead. With traditional caches, the heuristic that people like to use is that you need to make sure that you have at least enough memory for your working set allocated to the cache. Because if you don’t, you’re going to have this thing called thrashing, where you’re continuously swapping items in and out of the cache, because the application needs them but there’s not enough space to hold all of them. The same dynamic is absolutely true with dataflow-based caches. You need to absolutely make sure you have enough memory allocated for the working set.

There’s this whole dataflow graph around that as well, because the working set, that’s just the reader nodes. We have all these other nodes that are also stored in memory, like the dataflow graph ones. That could actually be pretty heavy, because it’s going to depend, of course, on the base dataset sizes. It’ll depend on how complex the query is, because the more complex the query, the more graph you have. The more computations you’re going to be doing in the graph, and the more memory you’re going to have to allocate to it. It also has to do with the data distribution in this interesting way. Because let’s say you’re filtering out some of the nodes responsible for filtering out the data, you could have instances where you have the largest base tables of all time, but you’re very quickly filtering away most of that data.

Really, there’s a question of like, how much are you filtering out? How heavy are any of these nodes going to be along the way? It begs the question, is this memory overhead practical? The answer is, not always, at least as described. This is the main obstacle, as I see it, to really using this in a real-world setting.

Now I’m going to talk about how we approach solving this memory overhead blowup problem in Readyset, at least. The way we do this is via a mechanism called partial state, also known as partial materialization. The main insight here is coming back to the beginning of this talk, like we have a skewed data access distribution. It’s not the case that everything is going to be equally as popular, and we have to make sure we’re preemptively putting everything in the cache.

Rather, it’s very likely that there’s going to be a relatively small subset of items that are really popular, really recent, or whatever. It’s distributed via Zipf’s Law, so it’s going to be highly skewed. You can get a really high cache hit rate just by caching the bulk of those, as opposed to caching the full long tail of potential query results. In the context of these prepared statements, think of it this way. You don’t have to preemptively compute the results of this query for any possible input parameter, like any possible story ID, because that would be a waste of time, because, as we discussed, most people don’t go on page 103 of Hacker News.

With partial materialization or state, the main idea is that when you first create this dataflow graph, it’s going to start off entirely empty, and you’re going to fill it in an entirely lazy way on-demand, via a mechanism called an upquery. The way upqueries work is that, again, cache is starting off empty. A user requests a value from the cache, it’s going to recursively traverse up the dataflow graph to find the closest node that has the missing state and then run it through the rest of the graph to perform the update.

I will just walk through a quick visual of this. Again, let’s say we’re running this query for story ID 2, the graph is starting off completely empty. The request is going to go into the reader node. The reader node is going to be like, “I don’t have it. Let’s ask my parent node”, which is the join node. The join node is also empty because we just got started. It’s going to be like, let me ask my two parent nodes, see if we can find the missing state. This is actually happening in parallel. In this diagram, it’s happening sequentially. It’s going to ask the count node, count node is also empty. The count node is going to ask the votes base table. The votes base table is, again, this local copy of the tables on disk. It’s going to necessarily have the state that we’re looking for, and it’s going to replay all of those row entries into the count node.

Concretely, all of the rows that indicated somebody voted for story 2, that’s going to be counted up by the count node, and it’s going to then emit that to the join node. The join node had asked its stories base table parent to pull the story info for story 2, and it’s going to join the results together and store it in the reader, and then return a response. The way we deal with memory pressure is the same as normal caches, where once we hit some memory threshold, maybe just like the memory on the machine, as opposed to simply being, we’ll just evict state based on LRU, LFU, whatever. It’s pretty standard.

Dataflow-Based Caching: Comparison to Alternatives

If I think through dataflow-based caching relative to traditional caching, you can avoid a lot of the usability challenges because it’s wire compatible with the database. It has the same interface. You don’t have to rewrite the app. You don’t have to worry as much about staleness, because it’s eagerly updating the cache entries behind the scenes. Then, the cache is never going to make anything worse, because we have a local copy of the base tables. We use that to deal with misses. You’re not going to intentionally introduce distributed systems bug. The important thing to note is that this is effectively expanding the space of supported workloads. Because you’re not doing this evict and recompute, you can tolerate comparatively write-heavy workloads.

If you had a lot of writes in a normal caching setting, then you would have to continuously evict, and then you never get a high cache hit rate. Here, because we’re just updating the cache directly in-memory, and it’s not a cache miss, then you can tolerate a much larger number of writes while still getting a good cache hit rate and having the cache be worth it. Of course, you can more easily cache complex queries without having to track data provenance when it comes to doing invalidation. I compare this to query optimization, obviously, the barrier of entry is lower because you don’t need to know anything about databases to be able to do this.

Sometimes, even if you optimize a query to the max extent possible, it’s still too slow, so caching still has a role there. When I compare this to read replicas, you can essentially set up this type of cache to have the same interface as a read replica, but you don’t have to optimize queries, and because you’re doing caching, you just get lower latencies.

Conclusion, and Resources

With dataflow-based caching, you can get on par performance to hand-optimized homegrown caching systems. You don’t have to design a cache invalidation policy. That’s all handled for you. It’s useful in a wider range of settings in the database world, for example, when you have more writes. We have a GitHub. If you want to see the source code, it’s available there, just look up Readyset. Then this is based on the Noria research project from MIT, so if you want to geek out further, then there’s a whole paper on it that you can take a look at. If you just Google that, you can find it.

Questions and Answers

Participant 1: Do you have read-after-write consistency?

Marzoev: We do not. It’s actually technically possible in this model, but we haven’t productionized it. By default, it’s eventually consistent. The way that I like to think about this is, when you deal with normal caches, you have no guarantees whatsoever, and you don’t expect any guarantees. We like to compare ourselves to the best alternatives, which are regular caches, as opposed to databases. Yes, CAP theorem.

Participant 2: Actually, how big is the table size it can handle in memory? For example, there is lots of tables we are querying in. If my query has lots of large tables, and since it is going to replicate those tables into the memory, would that be efficient to keep the copy of those tables in the memory?

Marzoev: If we have really large base tables, will it be efficient to store them in memory? We never store the full base tables in memory. We store them on disk in RocksDB. The only thing that’s in memory is the computational nodes. It’s possible that you might unintentionally bring those into memory if you’re running a really hefty join, but that’s what the whole partial materialization scheme is meant to defend against, where you don’t have to materialize the whole join, you just materialize the result for queries that you’re asking for.

Participant 2: Isolations like when the read and writes happens at the same time on the tables, how is that being handled? There could be lots of cases when the dirty read would be possible, in some scenario, when one user is updating the data and another one is reading the data.

Marzoev: Is there isolation between reads and writes? Yes. Essentially, the way that works is like, we are waiting to see the writes come in from your primary database, so they’re already sorted. The reader node is separate from the dataflow graph, because we want to be able to both continuously write updates to it, while supporting reading this eventually consistent state. Then there’s a point in time where we just do a pointer swap and we’re like, we’ve written to the new version of the cache for a while, so let’s flip that to still service it to the user. They’re completely separate, like threads.

Participant 2: There is a possibility of a dirty read in between, then.

Marzoev: It depends on how you define that dirty read.

Participant 3: Can you share a little bit about spreading into other database support, rather than Postgres and MySQL?

Marzoev: There’s something fundamental about this that makes it specific to Postgres or MySQL. Obviously, there’s a big assumption we’re making that we’re dealing with relational datasets. To support a new database, we just need to write a new replicator for that database and then write a new SQL shim for that database. It’s possible. It’s just engineering work. We’re a startup so we are probably not going to expand past these two for quite some time.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

Analysis of automated testing results is a very important and challenging part of testing activities. At any given moment we should be able to tell the state of our product according to the results of automated tests, Maroš Kutschy said at QA Challenge Accepted. He presented how artificial intelligence helps them save time spent on analysis, reduce human errors, and focus on new failures.

Kutschy mentioned that they faced challenges with the analysis of automated test results, and were looking for a way to make the analysis more effective and less prone to human errors:

If you have around 4000 test scenarios running each night and if around 5% of them are failing, you need to analyse around 200 failures each day.

They introduced the tool ReportPortal which uses artificial intelligence to analyse automated test results. This tool can be installed for free as an on-prem solution, as Kutschy explained:

I am the administrator, I did the proof of concept and the integration and I solved any issues. Colleague testers who work in feature teams are using it on a daily basis.

Testers log in to ReportPortal, find the results of the job for which they are responsible, and see how many failures are in “To Investigate” status, Kutschy said. Failures that existed on the previous day (which have been analyzed previously) are already categorized by ReportPortal. For failures in the “To Investigate” status, they need to do a standard round of analysis, which means debugging the tests and finding the root cause of the failure:

ReportPortal shows the output of the analysis; you can see how many scenarios failed because of product bugs, automation bugs, environment issues and how many failures are still in “To Investigate” status.

When you start using the tool, it knows nothing about the failures, Kutschy said. Testers need to decide if the failure is a product bug, automation bug, or environmental issue. The next time the same failure arrives in the system, then the correct status will be assigned to the failure according to previous decisions, using artificial intelligence.

Kutschy mentioned that the dashboards representing the results of the analysis provide a high-level view of the testing and the state of the application. The visibility of the state of analysis is in real-time, you see who is working on which failure. This helps to decide if it is possible to release the application or not.

With the tool they save time spent on analysis, as they look only at new failures, not at all of the failures, as Kutschy explained:

The difference is that if you have 100 failures today and only 2 of them are new, you only need to look at 2 failures. If you are not using the tool, you need to look at 100 failures, Kutschy mentioned.

There are also fewer human errors, as the tool does the triage of old failures for you based on previous decisions made by you. This helps to focus attention on new failures, Kutschy said.

Artificial intelligence will make the wrong decisions if humans train it with incorrect data, Kutschy said. If you are a bad teacher, your student (ReportPortal) will perform badly:

There were situations where one of the colleagues linked failure to an incorrect Jira ticket or assigned incorrect status to the failure.

You can “unlearn” by changing the decision manually, Kutschy mentioned.

If you use artificial intelligence correctly, it can save you a lot of time and will reduce human mistakes, Kutschy said. Once you verify that it is working correctly, you can rely on it instead of you and your colleagues having to triage the failures.

InfoQ Interviewed Maroš Kutschy about using artificial intelligence for the analysis of automated testing.

InfoQ: What challenges did you face along the way and how did you deal with them?

Maroš Kutschy: We started doing a proof of concept which confirmed that we could integrate the tool into our test automation framework.

The challenge then was to get colleagues to follow the new process of analysing test results using ReportPortal. Initially, they needed to categorize all existing failures, which meant assigning them the correct status (automation issue, product bug, environmental issue) and Jira ticket.

We ran a trial period for usage in selected teams and then all teams started using it. The feedback from the trial period was positive and the testers felt good about it, as it was helping them with the investigation.

InfoQ: What have you learned?

Kutschy: You have to verify that you can trust artificial intelligence before you start relying on it.

We had to be sure that ReportPortal was making the correct decisions. The decision depended on how we handled stack traces in our test automation framework, and the settings of ReportPortal. In the case where it did not work as expected, we tried to play with the settings of ReportPortal.

Most discussions are about using artificial intelligence to create test automation code, but we learned that the analysis of automated testing results is also a very suitable area. We can use artificial intelligence (including generative artificial intelligence) for many use cases in testing.

Article originally posted on InfoQ. Visit InfoQ

Google has announced significant enhancements to its AlloyDB database service, adding inline filtering and enterprise observability features to the vector search capabilities. According to the company, these new features aim to improve the performance and manageability of vector search operations for organizations that are building generative AI applications.

AlloyDB is Google Cloud’s fully managed PostgreSQL-compatible database service designed for demanding enterprise workloads. The newly introduced inline filtering allows developers to filter vector search results directly within the database during query execution rather than performing this filtering in application code after retrieving results. The company writes in a blog post:

One of AlloyDB’s most powerful features is the ability to perform filtered vector searches directly in the database instead of post-processing on the application side. Inline filtering helps ensure that these searches are fast, accurate, and efficient, automatically combining the best of vector indexes and traditional indexes on metadata columns to achieve better query performance.

In addition, on the observability front, Google has added enterprise-grade monitoring capabilities to AlloyDB that provide detailed insights into vector search operations. These include:

• Expanded query-level metrics that show time spent on vector operations
• More detailed logs for troubleshooting and optimization
• Comprehensive operational insights for better resource management

In its announcement, Google emphasized that these enhancements address key challenges customers face implementing vector search at scale, particularly as generative AI applications become more widespread in enterprise environments.

Aurimas Griciūnas, Founder & CEO @ SwirlAI stated on X:

With the rise of GenAI, Vector Databases skyrocketed in popularity. The truth is that a Vector Database is also useful for different kinds of AI Systems outside of a Large Language Model context.

The vector database market has grown significantly recently, with significant cloud providers competing to offer robust solutions for AI-powered applications. Google’s enhancements to AlloyDB follow similar moves by competitors such as AWS (OpenSearch as a Vector Database), Microsoft Azure (Cosmos DB), and specialized vector database providers like Pincone, Weaviate, and Milvus.

Yet Santiago, a computer scientist, tweeted on X on MongoDB, offering native support for vector search:

I don’t think specialized vector databases will survive for much longer. They were a big thing for a while, but now, you have pro-grade databases like @MongoDB offering native support for vector search.

They have become a one-stop shop for AI implementations in addition to its document and non-relational model.

Lastly, these new features are generally available to all AlloyDB customers.

Posted on mongodb google news. Visit mongodb google news

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Motley Fool Transcribing, The Motley Fool

March 6, 2025 at 12:45 AM

Image source: The Motley Fool.

MongoDB (NASDAQ: MDB)
Q4 2025 Earnings Call
Mar 05, 2025, 5:00 p.m. ET

Contents:

• Prepared Remarks

• Questions and Answers

• Call Participants

Prepared Remarks:

Operator

Good day, and welcome to MongoDB’s Q4 fiscal year 2025 earnings call. At this time, all participants are in a listen-only mode. After the speakers’ presentation, there will be a question-and-answer session. [Operator instructions] Please be advised that today’s conference is being recorded.

I would now like to hand the conference over to your speaker, Brian Denyeau, from ICR. Please go ahead.

Brian Raferty Denyeau — Investor Relations

Thank you, Sherry. Good afternoon, and thank you for joining us today to review MongoDB’s fourth quarter fiscal 2025 financial results, which we announced in our press release issued after the close of the market today. Joining me on the call today are Dev Ittycheria, president and CEO of MongoDB; and Serge Tanjga, MongoDB’s interim CFO. During this call, we will make forward-looking statements, including statements related to our market and future growth opportunities, our opportunity to win new business, our expectations regarding Atlas consumption growth, the impact of our non-Atlas business, the long-term opportunity of AI, the opportunity of application monetization, our expectations regarding our win rates and sales force productivity, our financial guidance and underlying assumptions, and our plan to invest in growth opportunities in AI.

These statements are subject to a variety of risks and uncertainties, including the results of operations and financial condition that cause actual results to differ materially from our expectations. For a discussion of material risks and uncertainties could affect our actual results, please refer to the risks described in our quarterly report on Form 10-Q for the quarter ended October 31st, 2024, filed with the SEC on December 10th, 2024. Any forward-looking statements made on this call reflect our use only as of today, and we undertake no obligation to update them, except as required by law. Initially, we will discuss non-GAAP financial measures on this conference call.

Don’t miss this second chance at a potentially lucrative opportunity

Ever feel like you missed the boat in buying the most successful stocks? Then you’ll want to hear this.

On rare occasions, our expert team of analysts issues a “Double Down” stock recommendation for companies that they think are about to pop. If you’re worried you’ve already missed your chance to invest, now is the best time to buy before it’s too late. And the numbers speak for themselves:

• Nvidia: if you invested $1,000 when we doubled down in 2009, you’d have $300,764!*

• Apple: if you invested $1,000 when we doubled down in 2008, you’d have $44,730!*

• Netflix: if you invested $1,000 when we doubled down in 2004, you’d have $524,504!*

Right now, we’re issuing “Double Down” alerts for three incredible companies, and there may not be another chance like this anytime soon.

Continue »

*Stock Advisor returns as of March 3, 2025

Please refer to the table in the earnings release on the investor relations portion of our website for a reconciliation of these measures to the most directly comparable GAAP financial measure. With that, I’d like to turn the call over to Dev.

Dev C. Ittycheria — President and Chief Executive Officer

Thanks, Brian, and thank you to everyone for joining us today. I’m pleased to report that we had a good quarter and executed well against our large market opportunity. Let’s begin by reviewing our fourth quarter results before giving you a broader company update. We generated revenue of 548.4 million, a 20% year over year increase and above the high end of our guidance.

Atlas revenue grew 24% year over year, representing 71% of revenue. We generated non-GAAP operating income of 112.5 million for a 21% non-GAAP operating margin. We ended the quarter with over 54,500 customers. For the full year, we crossed the 2 billion revenue mark, while growing 19% and are roughly 20 times the size we were the year before we went public.

Overall, we were pleased with our fourth quarter performance. We had a healthy new business quarter led by continued strength in new workload acquisition within the existing Atlas customers. In addition, we again benefited from a greater than expected contribution from multiyear non-Atlas deals. Moving on to Atlas consumption.

The quarter played out better than our expectations with consumption growth stable compared to the year-ago period. Serge will discuss consumption trends in more detail. Finally, retention rates remained strong in Q4, demonstrating the quality of our product and the mission criticality of our platform. As I look into fiscal ’26, let me share with you what I see as the main drivers of our business.

First, we expect another strong year of new workload acquisition. As we said many times in the past, in today’s economy, companies build competitive advantage through custom built software. In fiscal ’26, we expect that customers will continue to gravitate toward building their competitive differentiation on MongoDB. Second, we expect to see stable consumption growth for Atlas in fiscal ’26 compared to fiscal ’25.

Usage growth to start fiscal ’26 is consistent with the environment we have seen in recent quarters. This consistency, coupled with an improved fiscal ’25 cohort of workloads gives us confidence that Atlas will continue to see robust growth as it approaches a $2 billion run rate this year. Third, as Serge will cover in more detail, we expect our non-Atlas business will represent a meaningful headwind to our growth in fiscal ’26 because we expect fewer multiyear deals and because we see that historically non-Atlas customers are deploying more of the incremental workloads on Atlas. Fourth, we are very excited about our long-term opportunity in AI, as I will explain a bit later.

In fiscal ’26, we expect our customers will continue on their AI journey from experimenting with new technology stacks to building prototypes to deploying apps in production. We expect the progress to remain gradual as most enterprise customers are still developing in-house skills to leverage AI effectively. Consequently, we expect the benefits of AI to be only modestly incremental to revenue growth in fiscal ’26. Fifth, we’ll continue scaling our application modernization efforts.

Historically, this segment of the market was not widely available to us because of the effort, cost, and risk of modernizing old and complex custom applications. In fiscal ’25, our pilots demonstrated that AI tooling combined with services can reduce the cycle time of modernization. This year, we’ll expand our customer engagements so that app monetization can meaningfully contribute to our new business growth in fiscal ’27 and beyond. To start with, and based on customer demand, we are specifically targeting Java apps running on Oracle, which often have thousands of complex store procedures that need to be understood, converted, and tested to successfully monetize the application.

We addressed this through a combination of AI tools and agents along with inspection verification by delivery teams. Though the complexity of this work is high, the revenue obtained for modernizing those applications is significant. For example, we successfully modernize our financial application for one of the largest ISVs in Europe, and we’re now in talks to modernize the majority of the legacy estate. As I take a step back, I see fiscal ’26 as a year of solid Atlas growth, enabled by a large market, superior product, and strong go-to-market execution.

We expect continued strong win rates as we acquire incremental workloads across our customer base. We will continue building on our core land expand go-to-market motion to further accelerate workload acquisition. In fiscal ’25, we saw improved sales force productivity, and we are forecasting continued improvements in fiscal ’26. In addition, we will continue investing to become a standard in more of our accounts.

We are not market constrained and even our largest accounts. For example, we finished the year with 320 customers with over $1 million in ARR, a year-over-year growth rate of 24%. This reinforces our move up market. To that end, in fiscal ’26, we will make significant incremental investments in our strategic accounts program.

Looking beyond fiscal ’26, I’m incredibly excited about our long-term opportunity, particularly our opportunity to address the expanded requirements of a database in the AI era. Let me tell you what we’re seeing in our customer base as they work to adopt AI. AI is ushering in a new era of accelerated change and every company will have to adapt. We are witnessing a once in a generation shift that will fundamentally reshape industries, accelerate the pace of innovation and redefine competitive dynamics in ways we’ve never seen before.

We joke that the world will move so fast that tomorrow’s plans will happen yesterday. The winners will be those companies that can transform and adapt quickly to the new pace of change. Those cannot, will fall rapidly behind. AI is transforming software from a static tool into a dynamic decision-making partner.

No longer limited to pre-defined tasks, AI powered applications will continuously learn from real time data, but this software can only adapt as fast as the data infrastructure is built on, and legacy systems simply cannot keep up. Legacy technology stacks were not designed for continuous adaptation. Complex architectures, batch processing, and rigid data models create friction at every step, slowing development, limiting organization’s ability to act quickly and making even small updates time consuming and risky. AI will only magnify these challenges.

MongoDB was built for change. MongoDB was designed from the outset to remove the constraints of legacy databases, enabling businesses to scale, adapt and innovate at AI speed. Our flexible document model handles all types of data while seamless scalability ensures high performance for unpredictable workloads. With the Voyage AI acquisition, MongoDB makes AI applications more trustworthy by pairing real time data and sophisticated embedding and retrieval models that ensure accurate and relevant results.

We also simplify AI development by natively, including vector and text search directly in the database, providing a seamless developer experience that reduces cognitive load, system complexity, risk, and operational overhead, all with the transactional, operational, and security benefits intrinsic to MongoDB. But technology alone isn’t enough. MongoDB provides a structured solution oriented approach that addresses the challenges customers have with the rapid evolution of AI technology, high complexity, and a lack of in-house skills. We are focused on helping customers move from AI experimentation to production faster with best practices that reduce risk and maximize impact.

Our decision to acquire Voyage AI addresses one of the biggest problems customers have when building and deploying AI applications, the risk of hallucinations. AI-powered applications excel where traditional software often falls short, particularly in scenarios that require nuanced understanding, sophisticated reasoning, and interaction and natural language. This means they are uniquely capable of handling tasks that are more complex and open ended. But because AI models are probabilistic and not deterministic, that can hallucinate or generate falls from misleading information.

This creates serious risks. Imagine a financial services agent that autonomously allocates capital on behalf of its customers or a cancer screening application in the hospital that analyzes scans to detect early signs of pancreatic cancer. For any mission-critical application, inaccurate or low quality results are simply not acceptable. The best way to ensure accurate results is through high quality data retrieval, which ensures that not only the most relevant information is extracted from an organization’s data with precision.

High-quality retrieval is enabled by vector embedding and reranking models. Voyage AI’s embedding and reranking models are among the highest rated in the Hugging Face community for retrieval, classification, clustering, and reranking, and are used by AI leaders like Anthropic, LangChain, Harvey and Replit. Voyage AI led by Stanford professor, Tengyu Ma, who has assembled a world-class AI research team from AI labs at Stanford, MIT, Berkeley, and Princeton. With this acquisition, MongoDB will offer best-in-class embedding and reranking miles to power native AI retrievable.

Put simply, MongoDB democratizes the process of building trustworthy AI applications right out of the box. Instead of cobbling together all the necessary piece parts, an operational data store, a vector database, and embedding and reranking models, MongoDB delivers all of it with a compelling developer experience. As a result, MongoDB has redefined the database for the AI era. Now, I’d like to spend a few minutes reviewing the adoption trends of MongoDB across our customer base.

Customers across industries and around the world are running mission-critical projects in Atlas, leveraging the full power of our platform, including Informatica, Sonos, Zebra Technologies, and Grab. Grab, Southeast Asia’s leading super app, which provides everyday services like deliveries, mobility, digital financial services, and serves over 700 cities in eight Southeastern Asian countries, successfully migrated its key app, Grab Kiosk, to Atlas. Atlas provide Grab with automated, scalable and secure platform, which empowers engineering teams to focus on product development to accommodate Grab’s rapid growth. By leveraging Atlas, Grab achieved significant efficiency gains, saving around 50% of the time previously spent on database maintenance.

The Associated Press, the Catalan Department of Health, Urban Outfitters, and Lombard Odier are turning to MongoDB to modernize applications.Urban Outfitters chose MongoDBS’ database platform to provide a flexible, scalable foundation for its infrastructure with the vision of integrating data across systems for elevated and consistent customer experiences, the retailer found legacy database inadequate. By adopting Atlas and a flexible document model, Urban Outfitters accelerated development, boosted scalability, while seamlessly integrating data. This transformation facilitated the introduction of AI-driven personalization and cutting-edge search features enriching the shopping experience across both digital and physical spaces. Mature companies and start-ups alike are using MongoDB to help deliver the next wave of AI-powered applications to their customers, including Swisscom, NTT Communications, and Paychex.

Swisscom, Switzerland’s leading provider of mobile, Internet and TV services, deployed in new gen AI app in just 12 weeks using Atlas. Swisscom implemented Atlas to power a rag application for the East Foresight library, transforming unstructured data such as reports, recordings and graphics into vector embeddings that large language models can interpret. This enables Vector Search to find any relevant context resulting in more accurate and tailored responses for users. In summary, we had a healthy Q4.

We saw stabilizing Atlas consumption growth along with a strong new business quarter and we remain confident in our ability to execute on a long-term opportunity. Fiscal ’26 is a transition year as we execute on our go-to-market motion, while investing to prepare to capture the AI opportunity, both through greenfield AI applications and AI-assisted modernization of legacy applications, we want to capitalize on a once in a generation opportunity. With that, here’s Serge.

Serge Tanjga — Interim Chief Financial Officer

Thanks, Dev. I’ll begin with a detailed review of our fourth quarter results and then finish with our outlook for the first quarter and full fiscal year 2026. First, I will start with our fourth quarter results. Total revenue in the quarter was $548.4 million, up 20% year over year and above the high end of our guidance.

Shifting to our product mix, let’s start with Atlas. Atlas grew 24% in the quarter compared to the previous year and now represents 71% of total revenue compared to 68% in the fourth quarter of fiscal 2024 and 68% last quarter. Atlas revenue is recognized primarily based on customer consumption of our platform, and that consumption is closely related to end-user activity of their applications/ Let me provide some context on Atlas consumption in the quarter. In Q4, consumption was ahead of our expectations.

If we compare this year’s Q4 with Q4 fiscal year ’24, both usage and consumption growth were stable on a year-over-year basis. While this is only one quarter and consumption trends around the holidays can be particularly volatile, we are encouraged to see signs of stability and consumption growth. Turning to non-Atlas revenue, non-Atlas came in ahead of our expectations, in part due to greater than expected contribution from multiyear deals, as Dev mentioned. As you know, due to ASC 606, we recognized the entire term license component of a multiyear contract at the start of that contract.

This multiyear license revenue benefit was over $10 million more than was contemplated in our Q4 guidance. We realize that ASC 606 introduces increased variability into our non-Atlas revenue, making it harder to understand underlying trends. To address that, we wanted to provide some incremental color. If we look at non-Atlas ARR growth rather than revenue, in Q4 of fiscal year ’25, the growth was in the mid single digits year over year compared to low double-digit growth in the year ago period.

We observed that customers who are predominantly non-Atlas historically are deploying a growing share of incremental workloads on Atlas. In other words, the revenue growth of those customers is increasingly showing up in out. Turning to customer growth, during the fourth quarter, we grew our customer base by approximately 1,900 sequentially, bringing our total customer count to over 54,500, which is up from over 47,800 in the year-ago period. Of our total customer count, over 7,500 are direct sales customers, which compares to over 7,000 in the year-ago period.

The growth in our total customer count is being driven primarily by Atlas, which had over 53,100 customers at the end of the quarter compared to over 46,300 in the year-ago period. It’s important to keep in mind the growth in our Atlas customer count reflects new customers to MongoDB in addition to existing EA customers adding incremental Atlas workloads. In Q4, our net ARR expansion rate was approximately 118%. The decline versus historical period is attributable to a smaller contribution from expanding customers.

We ended the quarter with 2,396 customers with at least $100,000 in ARR and annualized MRR, up from 2,052 in the year ago period. As Dev mentioned, we also finished the year with 320 customers spending $1 million or more annualized on our platform compared to 259 a year ago. Moving down the income statement. I will be discussing our results on a non-GAAP basis, unless otherwise noted.

Gross profit in the quarter was $411.7 million, representing a gross margin of 75%, which is down from 77% in the year-ago period. Our year-over-year gross margin decline is driven in part by Atlas growing as a percent of the overall business. Our income from operations was $112.5 million or a 21% operating margin for the fourth quarter compared to a 15% margin in the year ago period. Our operating income results versus guidance benefited from our revenue outperformance.

In addition, we benefited from timing of hiring around year-end. Net income in the fourth quarter was $108.4 million, or $1.28 per share based on 84.6 million diluted weighted average shares outstanding. This compares to a net income of $71.1 million or $0.86 per share on 82.9 million diluted weighted average shares outstanding in the year-ago period. Turning to the balance sheet and cash flow.

We ended the fourth quarter with $2.3 billion in cash, cash equivalents, short-term investments, and restricted cash. During Q4, we also completed the redemption of our 2026 convertible notes, and as a result, our balance sheet is debt free. Operating cash flow in the fourth quarter was $50.5 million, after taking into consideration approximately $27.6 million in capital expenditures and principal repayments of finance lease liabilities, free cash flow was $22.9 million in the quarter. This compares to free cash flow of $50.5 million in the year-ago period.

Our Q4 capex included approximately $24 million for purchase of IPv4 addresses, as we discussed previously. This concludes our IPv4 address purchases. I’d now like to turn to our outlook for the first quarter and full fiscal year 2026. For the first quarter, we expect revenue to be in the range of $524 million to $529 million.

We expect non-GAAP income from operations to be in the range of $54 million to $58 million, and non-GAAP net income per share to be in the range of $0.63 to $0.67 based on 86 million estimated diluted weighted average shares outstanding. For the full fiscal year 2026, we expect revenue to be in the range of $2.24 billion to $2.28 billion, non-GAAP income from operations to be in the range of $210 million to $230 million and non-GAAP net income per share to be in the range of $2.44 and $2.62 based on 87.3 million estimated diluted weighted average shares outstanding. Note that the non-GAAP net income per share guidance for the first quarter and full fiscal year 2026 include a non-GAAP tax provision of approximately 20%. I’ll now provide some more context on our guidance, starting with the full year.

First, as Dev mentioned, we expect roughly stable Atlas consumption growth compared to fiscal year ’25. Atlas consumption will benefit from stronger contributions from workloads acquired in fiscal year ’25 compared to the contribution that fiscal year ’24 workloads had last year. As you know, we made changes to sales compensation plans at the start of last year to focus more on the size of new workloads acquired, and we believe that those changes are having the desired impact. Second, we expect our non-Atlas subscription revenue will be down in the high-single digits for the year.

The primary reason is that we expect an approximately $50 million headwind from multiyear license revenue in fiscal year ’26, an estimate that is based on a bottoms-up analysis of our non-Atlas renewal base. Simply put, after two years of very strong multiyear performance, we expect the mix of multiyear non-Atlas revenue to not only be lower than the last two years, but also below the historical trends. This is due to the fact that in fiscal year ’26, we have a more limited set of large non-Atlas accounts that can sign multiyear deals. Finally, I wanted to provide some context to better understand our operating margin guidance.

We expect operating margin of 10% at the midpoint of the range, down from 15% that we reported in fiscal year ’25. There are three primary reasons for the margin decline. First, the $50 million of fiscal year ’25 multiyear license revenue that won’t repeat in fiscal year ’26 is very high margin, making for a difficult margin compare. This will primarily impact the second half of the year.

Second, we are investing aggressively in R&D, inclusive of the recently announced acquisition of Voyage AI. We see an opportunity to further distance ourselves from the competition in terms of performance and scalability and to redefine what it means to be a database in the age of AI. Third, we are increasing our marketing investments, specifically to drive improved awareness and understanding of MongoDB’s capabilities. Our goal is to better educate new and existing customers on the full power of our platform and highlight the widening gap between us and the legacy competitors.

Moving on to our Q1 guidance, a few things to keep in mind. First, we expect Atlas revenue to be flat to slightly up sequentially. Please keep in mind that Q1 has three fewer days than Q4. Also, the typical seasonally slower Atlas consumption growth during the holidays has a bigger impact on incremental Q1 revenue that it did in Q4, thereby negatively impacting sequential revenue growth.

Second, we expect to see a meaningful sequential decline in EA revenue. As discussed in the past, Q4 is our seasonally highest quarter in terms of our EA renewal base, which is a strong indicator of our ability to win new EA business. In Q1, the EA renewal base is sequentially much lower. Third, we expect operating income to decline sequentially due to the lower revenue, as well as our increased pace of hiring.

Finally, let me address how the acquisition of Voyage AI will impact our financials. We disclosed last week that the total consideration was $220 million. Most Voyage shareholders received a consideration in MongoDB stock with only $20 million being paid out in cash. To offset the dilutive impact of the acquisition, today, we are announcing that our board has authorized a $200 million stock buyback.

In fiscal year ’26, we expect an immaterial amount of revenue from the acquisition as we work to expand the reach of the technology and integrate it into the MongoDB database. On the expense side, we attempt to grow the Voyage team to accelerate innovation and help with integration. These expenses will show up in the R&D line in our income statement and will be modestly dilutive to operating margin for the year. To summarize, MongoDB delivered strong fourth quarter results.

We are pleased with our ability to win new business and see stable consumption trends in Atlas. We remain incredibly excited about the opportunity ahead, and we’ll continue to invest responsibly to maximize our long-term value. With that, I would like to open it up for questions. Operator?

Questions & Answers:

Operator

And our first question will come from the line of Raimo Lenschow with Barclays. Your line is open.

Raimo Lenschow — Analyst

Perfect. Thank you, and two quick questions from me. One is on the multiyear guidance or the multiyear situation, like, if you look like this quarter and the quarters before, you overperformed there. The guidance is, obviously, your expenses were slightly, you know, weaker because you have a lower renewal portfolio.

Is it just a portfolio or do you see a change in trend there? So, is it just a mechanical problem or like — or mechanical situation or is there also a change in behavior? And then, I had one follow-up.

Serge Tanjga — Interim Chief Financial Officer

Yeah. So, Raimo, why don’t I take that one. Thank you for the question. So, let me just make sure that I repeat and level set.

So, in fiscal year ’24, we had exceptionally strong multiyear performance led by our Alibaba deal. And going into fiscal year ’25, we expected a $40 million headwind based on the assumption that fiscal year ’25 would be in line with long-term trends. Instead, after a strong Q3 and Q4, the ultimate headwind was significantly lower than that $40 million. And that creates the renewal base effect that sets us up for fiscal year ’26.

So, what I mean by that is, because we’ve done so many more multiyear deals in fiscal year ’24 and ’25, the renewal base and the opportunity is just much lower to begin with. So, it’s not a change in trends. In fact, we assume same conversion rates as historically is just the opportunity set is lower in fiscal year ’26.

Raimo Lenschow — Analyst

OK. Perfect. And then if you think about the Voyage acquisition, like, how do you need to think about that in terms of getting that into the organization and into the market? Is that kind of going to be like an attachment to what you were doing? Or do you think it’s going to be sold broader than just into the MongoDB installed base? Thank you.

Dev C. Ittycheria — President and Chief Executive Officer

Thanks, Raimo. I’ll take that question. Today, Voyage AI does offer its models to other third parties, and we will continue to do that. We think it’s important for people to have access to the best-in-class models.

We also believe that, that will be a great way to bring people new to MongoDB into the MongoDB, you know, sphere, and that’s a way for us, that will be, in the short to medium term, a better-together story where we will basically integrate Voyage AI into the MongoDB platform and do things like auto embeddings where data will be embedded as soon as it’s basically entered into a MongoDB platform, which will make a developer’s life that much easier versus having to go to some third party to get the data embedded and then to use our vector store. And then, we have a bunch of other things that we plan to do in terms of the product road map in terms of more sophisticated model, more domain-specific models, etc. And we’ll talk about that in future calls. But we do want to make this available to all customers, including people who are not MongoDB customers today, and we think that’s good for the business long term.

Operator

Thank you. One moment for our next question. And that will come from the line of Sanjit Singh with Morgan Stanley. Your line is open.

Unknown speaker — — Analyst

Great. Thank you, guys. You got [Inaudible] on for Sanjit. Maybe with my first question, building on Raimo’s question on Voyage AI, when you think about the decision to acquire Voyage AI, could you sort of double click again on the reasons — and particularly, with a look on your portfolio, what were the aspects that either existing or new customers couldn’t do with your portfolio that they can now pursue with the technology that you acquired through the Voyage AI? And then, as a second question, as it relates to your operating expense guidance that’s implied in your investments there.

Last quarter, you talked a lot about reallocating investments. So, I’d be curious just if you can double click on what’s changed over the last 90 days that really pushed you to make those incremental investments from — I appreciate the reasons that you gave, some of those like the $50 million multiyear, Dev, you probably had some visibility on that 90 days ago. So, sort of what has changed in those 90 days that pushed you to make those incremental investments?

Dev C. Ittycheria — President and Chief Executive Officer

So great. I’ll start — I’ll address the Voyage AI question, and then I’ll hand it off to Serge to talk about opex. So, stepping back and just thinking from a customer’s perspective, one of the main reasons what gives customers pause in terms of deploying mission-critical AI use cases is the risk of hallucinations. Because AI systems are probilistic, you can’t always guarantee what the output will be.

And if you’re in a regulated industry, whether it’s financial services or healthcare or other industries where precision of the response or the quality of response really matters, it really prevents people from deploying these production level AI use cases. So, the reason we acquired Voyage AI is to provide what’s called embedding and reranking models. And let me just explain, you know, how this all works. So, think about the LLM as the brain.

Think about the dat;abase is about your memory and the state of where how things are. And so — and then think about embedding as an ability to find, you know, the right information for the right question. So, imagine you have a very smart person, say, like, Albert Einstein on your staff and you’re asking him, in this case, the LLM, a particular question. While Einstein still needs to go, you know, do some homework based on what the question is about finding some information before he can formulate an answer, rather than reading every book in a library, what the embedding models do is essentially act like a library and pointing Einstein to the right section, the right aisle, the right shelf, the right books, and the right chapter on the right page, to get the exact information to formulate an accurate and high-quality response.

So, the performance gains you get by leveraging embedding models is significant. And even embedding models themselves have different qualities, and Voyage AIs embedding models are typically the top rank models on Hugging Face. So, we know a lot of ISVs have already reached out to us since the acquisition saying they switched to Voyage from other model providers and they got far better performance. So, the value of Voyage is being able to increase the quality and hence the trustworthiness of these AI applications that people are building in order to serve the most demanding and mission-critical use cases.

Serge Tanjga — Interim Chief Financial Officer

Yeah. And I’ll take the opex question. So, you’re absolutely right. We are both reallocating and reinvesting at the same time.

And so, 90 days ago, we talked about some reallocations in our sales and marketing line where we’re reducing our investment in the mid-market in order to deploy those resources in the upmarket. And then, we also talked about discontinuing or deemphasizing a few products so that we can focus more on the remaining portfolio where we see the traction and the opportunity. We are investing over and above what we’re reallocating, and that was the plan all along. And the reason for that is because of the opportunity that we see.

You’ve heard Dev talked in his prepared remarks about the unique opportunity that AI will present for people to revisit their infrastructure stack. And we see that as a unique once in a lifetime opportunity that we want to capitalize on. And what we don’t want to do as a management team is sit here five years from now and wonder whether we invested enough to fully maximize our long-term opportunity. And what gives us comfort in this investment is, frankly, our margins track record.

So, if you go back and take a step back and go back as far as the IPO, our margins went in the negative 30%, and obviously, we’ve come a long way in terms of growth and margin expansion at the same time. And even if you look more recently over the last couple of years, at the moments when we slowed investments, we saw margin spike, including, frankly, in Q4, where we printed 21% operating margin, which is in line with our long-term guidance. So, we have confidence that the economics of the business are strong and that the business scales, but it’s about investing at the right moment in time and the conviction that we have to really play offense and optimize on our opportunity.

Operator

Thank you. One moment for our next question. And that will come from the line of Mike Cikos with Needham. Your line is open.

Mike Cikos — Analyst

Hey, guys. Thanks for taking the questions here. I wanted to come back — I know we’re talking about the Atlas consumption trends and how they’re shaking out, where we sit today. Just curious, when we think about the full year, you guys are talking about taking most recent couple of quarters as far as how that consumption has played out.

And is there anything specific to Q4 consumption that started to drive this dynamic on the growth? I’m interested in what you would point to. Was it the improving sales initiatives in the cohort you guys are capturing or, is there something else you could point us to on that for?

Serge Tanjga — Interim Chief Financial Officer

Yeah. I’ll take the first one on that, Mike. So, when it comes to Q4, first of all, as we’ve discussed in the past, it’s sort of the seasonally slowest quarter of the year in terms of consumption growth because we do see both usage and consumption slowdown around the holidays, and we saw that happen. Q4 consumption was lower than Q3.

[Technical difficulty] apparent volatility when it comes to the holiday season. When it comes to stable consumption growth in fiscal year ’26 though, I would [Technical difficulty] consumption in three components. So, the first [Inaudible] is the base itself, which is obviously the largest, but it drove the percentage rate because, you know, it just the oldest workload. That’s layer one.

Now layer two is workload the prior year. Those workloads in the current year are meaningful and are still growing [Technical difficulty] in any given year, we need the workloads of the prior year and the workloads of the current year to basically offset the growing base effect. And so, last year, we were not able to do that, you know, for three reasons. Number one is, the base itself slowed down, which was a macro phenomenon that we called out in Q1.

Secondly, fiscal year ’24 workloads didn’t meet our expectations going into fiscal year ’25. And then, new workloads in fiscal year ’25, we’re off to a slow start slightly for operational reasons, and that kind of was a headwind that we face for the rest of the year. So, now turning the calendar forward for this year, we are calling for a stable macro environment and usage growth in the base. Obviously, we don’t have a crystal ball, but that’s what we see currently.

Then we’re expecting more from fiscal year ’25 workloads. We’re optimistic than those are doing better based on the data that we have. And because of our move upmarket, we expect to get more new workload ARR and sales productivity in fiscal year ’26 cohort. And those two things offset the fact that the base is again larger than it was a year ago and result in stable consumption growth.

Mike Cikos — Analyst

Thank you for that, Serge. Really appreciated. And for a follow-up here. I know that we’re citing this $50 million multiyear headwind as it relates to the non-Atlas business.

Can you kind of chunk that up? Is — like, if I’m thinking about Q1, Q2, is there any way you can help us get a sense of what those headwinds are on a quarter-by-quarter basis?

Serge Tanjga — Interim Chief Financial Officer

It’s sort of the mirror image of the outperformance that we’ve seen here in Q3 and Q4 that we called out. And so, I would think of it as a back half weighted phenomenon.

Mike Cikos — Analyst

Got it. Thank you so much, guys.

Operator

Thank you. One moment for our next question. And that will come from the line of Brent Bracelin with Piper Sandler. Your line is open.

Brent Bracelin — Analyst

Thank you. Good afternoon. I wanted to double click into Atlas. If we normalize for the unused credits last year, the implied Atlas growth here in the low-20s is actually a bit of a bigger step down in growth.

So, could you just revisit the growth levers as we think about Atlas here? I know, it’s a larger business going into this year than last, but it does look like normalized growth after accounting for the unused credits last year is decelerating a little bit more. Just curious why.

Serge Tanjga — Interim Chief Financial Officer

Yeah. So, I’m going to go through the puts and takes a little bit, but I think it will help with the math. So, the first thing I would reiterate is that on average, we expect consumption growth in fiscal year ’26 to be stable with what we’ve seen in fiscal year ’25. So, that’s point number one.

Point number two is you have the total guidance. And then, you can take the high-single digit rate of decline in the non-Atlas business. And that will give you a sense of what is — what’s left in Atlas, and that fits with the roughly stable Atlas consumption growth in fiscal year ’26. The final thing I would say is, as you think about the growth in fiscal year ’25, just a reminder that what matters is the exit rate as opposed to the average throughout the year because we have seen revenue slow down on a year over year basis because we have had slower assumption in all quarters — consumption growth in all quarters, except Q4 of last year.

Brent Bracelin — Analyst

Got it. And then, Dev, as a follow-up for you. We’ve seen AI workloads, I would argue, in the experimental phase for the last two years. We’re now seeing AI go into production, starting to see early signs of some of these agentic functions show up in revenue.

What’s your expectation as you think about customer conversations, customers that are in experimentation going to production? When do you expect to see a bit of a lift there on your business?

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. So, again, we do see — I mean, we have some high-profile AI companies who are building on top of Atlas. I’m not at liberty to name who they are, but in general, I would say that the AI journey for customers is going to be gradual. I would say one is a lack of AI skills in their organizations.

They really don’t have a lot of experience and it’s compounded by the rapid evolution of AI technology that they feel like it’s very hard for them to kind of think about like what’s stack to use and so on and so forth. The second, as I mentioned earlier, on the Voyage question, there’s also a real worry about the trustworthiness of a lot of these applications. So, I would say, the use cases you’re seeing are fairly simplistic, customer chatbots, maybe document summarization, maybe some very simple agentic workflows. But I do think that that, you know, we are in the early innings, and I expect that sophistication to increase as people get more and more comfortable.

We think architecturally, we have a huge advantage of the competition. One, the document model really supports different types of data, you know, structured, semi-structured, and unstructured. We embed, you know, a search and Vector Search onto a platform. No one else does that.

But then, we’ve now — with the Voyage AI, we have the most accurate embedding and reranking models to really address the quality and trust issue. And all this is going to be put together in a very elegant developer experience that reduces friction and enables them to move fast. So, we feel we are really well positioned for this opportunity. And we’re really excited.

We are already obviously excited about what Voyage brings to us and excited by what customers are telling us. But we do think it’s going to take some time because customers, again, are naturally, you know, getting their arms around this technology and starting slowly.

Operator

Thank you. One moment for our next question. And that will come from the line of Karl Keirstead with UBS. Your line is open.

Karl Keirstead — Analyst

Thanks. Dev, on the last call and even the prior one, you talked quite a bit about this go-to-market pivot where you were pushing MongoDB to go after more opportunities upmarket. To what extent is that go-to-market transition reflected in your guidance? Are you assuming some upside from that effort in your revenue guidance? And conversely, does that require a decent amount of sales investments that might be a factor in your margin guidance? And how is that effort going at a high level? Thank you.

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. Thanks for the question, Karl. We’re really pleased with the progress we’re making as evidenced by just even the data point we shared on the $1 million customers. I mean, that customer count is growing faster than our — the rest of our customer base.

So, we’re already seeing dividends from the investors were making up market. And we did see sales productivity gains last year from the move-up market, and so we expect even further sales productivity gains this year. In terms of the margin, we actually reallocated investments in sales, moving resources from the midmarket to the upmarket. So, I wouldn’t say that there was a demonstrable increase in sales investments.

The investments are really more in R&D and driving more awareness of our platform and educating — spending more time in educating customers because you still find that a lot of people are still not completely aware of MongoDB’s full capabilities and also — don’t necessarily have the skills to use all of our capabilities. So, you’re seeing a lot of investments going there. And that’s what we’re really focused on. But in terms of the move-up market, we’re really happy with the results we’re seeing.

Serge Tanjga — Interim Chief Financial Officer

And, Karl, the only thing I would add is that that increased productivity is definitely a part of the guidance.

Karl Keirstead — Analyst

OK. Terrific. Thank you, both.

Operator

Thank you. One moment for our next question. And that will come from the line of Kingsley Crane with Canaccord Genuity. Your line is open.

Kingsley Crane — Analyst

Hi. Thanks for taking the question. So, again, on Voyage AI, you mentioned that technology is not enough in the prepared remarks. So, to what extent do you think feature sets like that Voyage can drive workload creation within AI apps or is that more market oriented? And then, is Voyage additive in its ability to reduce vector storage costs similar to your efforts and quantitation?

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. So, a couple of points. I’m just stepping back. We see two big challenges that customers have.

They have a skills gap, and then they have a trust gap with AI. Voyage AI addresses the trust gap, enabling to build high-quality AI applications where the results — they have a high degree of confidence in. But the skills gap is still inherent to these organizations. So, what we are doing is not just bringing technology but we’re really taking a solutions approach where we come in together with the combination of technology, best practices, experience so that we can really help customers deal with their business problems, not just throw technology at them.

And customers really appreciate this approach. And so, you’ll see us really take more of a solution approach to help, for example, in modernizing their existing legacy applications, as well as helping them build new AI applications. In terms of storage, yes, the advances we made in the quantization really reduced the storage cost and improves the performance of our Vector store. I would say with these embedding models are slightly different.

What that’s doing is essentially helping really quickly find the precise information needed based on the query being posted to the application or to the underlying LLM to get the best quality answer. So, we really feel like this is all about like increasing the trustworthiness and the accuracy — through the accuracy of the results that are generated from these AI applications.

Kingsley Crane — Analyst

Great. Really helpful. And a quick follow-up. How did GCP partner influenced deals far in the quarter? You called out strength last quarter and that you were looking to do more of them in Q4.

I also saw that they made some cuts more recently. Thanks.

Dev C. Ittycheria — President and Chief Executive Officer

No. Our relationship with Google Cloud is still very constructive and productive. I mean, generally, I would say, our relationship with all the hyperscalers is very positive. And so, we’re working with them depending on the customers.

I see some customers have relations with only one hyperscaler, sometimes they have relationships with multiple hyperscalers. And we work closely with GCP, as well as AWS and Azure, and I would say, all three are actually quite productive.

Operator

Thank you. One moment for our next question. And that will come from the line of Pat Walravens with Citizens Bank. Your line is open.

Patrick Walravens — Analyst

Great. Thank you. I was wondering if you could just step back for us and give us sort of the five year trajectory on non-Atlas, because I look at the growth rates going back, ’21 was 23%; ’22, 19%; ’23, 25%; [Inaudible] so was there a period there where it exceeded your expectations? And then, where it came in below, what you thought. Sort of what was the ebb and flow of non-Atlas?

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. I wanted to say, we don’t really manage the business necessarily by product. We manage it by channel and really work from a customer orientation working backwards. What we do see at the high end of the customer mark — segment is that customers do like choice.

They don’t necessarily believe that every workload will go to the cloud. And in many cases, some customers are still very much focused on building their technology stack on-prem. In fact, a lot of large banks in Europe and actually a number of banks here in the U.S. have pre-dispositions and workloads on-prem.

So, it’s really about serving the customers’ needs. The customers do like the ability to have choice on how they run their workloads. And — but we do also see it, and this is what’s called out in the prepared remarks, for those customers who start with EA who have a significant amount of EA, we are seeing them — seeing more of those incremental workloads move to Atlas. And some of these new capabilities, like, Voyage now that will be available only on Atlas.

And so, there are some things that we’re doing that you’ll see customers probably inherently do more on Atlas. And I’ll hand — you know, I’ll let Serge comment on your question on the guide.

Serge Tanjga — Interim Chief Financial Officer

Yeah. So, I think that — I would just stress a couple of things, Pat. One is, we talked in prepared remarks about non-Atlas ARR growth being in the mid single digits year over year in Q4 and that being slowed down from double digits growth in Q4 of fiscal year ’24. And that’s the phenomenon that Dev is talking about, which is that, we are seeing increasingly customers who are historically not-Atlas deploying incremental workloads on Atlas.

They do deploy incremental workloads on EA, that’s why that line item continues growing, and we expect it to continue growing. But we see more and more of it actually coming on Atlas. So, if you look at the ARR of those customers, it’s actually growing more than what the just the non-Atlas component would suggest, and that’s baked into both the Atlas and the non-Atlas portion of the guide.

Patrick Walravens — Analyst

OK. And then just as a follow-up, and you might not be able to comment on this. But as we look out past ’26, I know you don’t run the business this way, but we do model it this way. So, as we look out past ’26, should we expect the growth to stay really muted?

Serge Tanjga — Interim Chief Financial Officer

Yeah. So, I would say two things. One is, the puts and takes are the following. We do still have low market share even in those customers who are predominantly non-Atlas.

So, we do expect to continue growing workloads that we can acquire in EA, number one. Number two, we do expect to move to the cloud to continue. So, we do expect those customers for us to gain even more share in those customers by getting incremental Atlas workloads. And then, a bit of a question mark at this point is, sort of, how the app modernization initiative is going to play out.

We think that will benefit both Atlas and non-Atlas — or EA rather,. And so obviously, that’s still nascent and it’s sort of hard to ascertain, but that actually all to be helpful across the board.

Operator

Thank you. One moment for our next question. And that will come from the line of Brad Sills with Bank of America. Your line is open.

Brad Sills — Analyst

Great. Thank you so much. A question for you, Dev. You mentioned fiscal ’26 kind of being a year of transition.

I wanted to get your thoughts on what that means exactly. It seems to me that the consumption patterns are stabilizing. You’re seeing some traction with new workloads. Last year was a year of kind of go-to-market changes.

It feels like this would be the year where you would start to see some progress on some of the transition items you saw last year. So, maybe transition is a little bit strong as a way to describe this year, but I just wanted to kind of double-click on your thoughts on that.

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. So, let me be clear. I feel very bullish about the future of this business. I have not been excited like this for a long time.

I think the way people are building these new AI locations are already made for a platform like MongoDB in terms of ability to handle different data types, the scalability of the platform to be able to natively support lexical semantics search and obviously now to be able to also give a very elegant experience to be able to leverage embedding and reranking models. So, that’s — I feel very bullish. And I think this business can grow meaningfully faster than it is today. But we are obviously making the right investments.

We believe the right investments to kind of position the company for that growth. We’re pleased to see that the Atlas business is stabilizing, and that was obviously mentioned by both myself and Serge in the prepared remarks. I know that’s been a question for a lot of investors. I think obviously, with the EA business, there’s the puts and takes with this multiyear, but the long-term trends are in our favor.

It’s a big market. We’re going after, you know, essentially a big opportunity because customers are essentially looking to run their business through custom software. And I believe that, you know, when you think about like a competitive differentiation against the other players in the space, I think we are very, very differentiated and that will show up in the numbers over time.

Serge Tanjga — Interim Chief Financial Officer

Yeah. The only thing I would add, Brad, is that it’s a transition year in a sense that some of our largest initiatives and focus areas, those being application modernization and then generally winning the AI stack are going to only incrementally be beneficial to our revenue this year, but we expect them to be meaningful growth drivers in years beyond.

Brad Sills — Analyst

Wonderful. Thanks for that. And then, would love to get your thoughts on where you’re seeing new workloads strength that you called out. Any categories in particular? Thank you.

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. Actually, the short answer is, we’re seeing it everywhere. We’re seeing it both at the high end of the market, as well as at the low end of the market. If you see our customer count, our customer count — new customer count for this quarter, this past quarter was quite strong.

And so — and as we called out, our move upmarket is generating our $1 million customer count is actually growing faster than our overall customer base. So, we’re seeing results at both the top end and the bottom end of the market.

Operator

Thank you. One moment for our next question. And that will come from the line of Patrick Colville with Scotiabank. Your line is open.

Patrick Colville — Analyst

Thanks so much for taking my question. I guess, Dev, this one’s for you, please. So, MongoDB is obviously doing a lot of things right. So, I guess, I just want to ask around the competitive environment as of today.

How is MongoDB competing with the hyperscalers and Postgres as of today? And is there any difference to the competitive environment, call it, this time of year about March 2024. Thank you.

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. Well, I’ll say that — I’ll make two main points, and I’ll explain what they are. One, a lot of people do compare MongoDB to Postgres. And I think that’s actually a false comparison because Postgres is just an OLTP database.

With MongoDB, the right comparison is Postgres plus Elastic plus something like Pinecone plus maybe like an embedding model from like either like Open AI or Cohere. So, when you package all those components together, you get a like-for-like comparison with MongoDB. And I think obviously, customers much prefer to have a much more elegant solution than trying to cobble all these pieces together and try and figure out how to make it all work. The second point I’d say is, MongoDB is frankly a much better OLTP database than Postgres.

Postgres is based on the relational architecture. It’s very rigid. It doesn’t handle unstructured data well. It claims to support JSON data, but the performance of anything north of like 2 kilobytes of JSON data, the performance of Postgres really suffers.

And it’s not very scalable. And I think what Postgres is the beneficiary of is the lift and shift of Oracle and Sybase and SQL Server because they’re the open source relational standard, but they’re not exactly competing for the same workloads as we are. Our win rates against Postgres are very high. When we talk to our salespeople, when we can explain the value proposition of MongoDB against Postgres, our win rates are incredibly high.

We just want to get into more battles. And what we recognize is people who don’t know MongoDB may just gravitate to Postgres as their solution because they just don’t know how to use MongoDB. And that’s what we’re working on in terms of generating more awareness and infusing more skills into our existing customers as well as the new customers who want — we want to come to our platform.

Patrick Colville — Analyst

Very helpful. And I guess, just touch on the hyperscalers briefly.

Dev C. Ittycheria — President and Chief Executive Officer

The hyperscale is — they have their own variants of Postgres offerings, and they have the clones. I mean we haven’t seen the clones as much lately. Our win rates against the clones are very, very high. This is something we should talk about for a few years ago, but we seem to — our relations with the hyperscalers, as I mentioned on the previous question, is actually very positive.

Our salespeople partner with the hyperscalers all around the world, and what we find is that together, we win more business. And yes, there may be situations where they try and leave with the first-party services. But usually, we find that, you know, when we partner with them that they’re very accommodating and we all can do well working together. So, I would say, there’s no structural issue with the hyperscalers.

Operator

Thank you. One moment for our next question. And that will come from the line of Rishi Jaluria with RBC Capital Markets. Your line is open.

Rishi Jaluria — Analyst

Wonderful. Thanks so much for taking my question. Dev, I want to follow up on a comment you made, which is a lot of the Postgres success is from lift and shift of existing SQL applications. And we’re seeing the same thing in our own checks.

What needs to happen as companies think about net new generative AI applications for them to think about kind of reconstructing or rearchitecting those solutions from scratch, especially when they want to leverage unstructured data? And what role can you play in kind of driving that conversation more toward rebuild rather than just lift and shift?

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. That’s a good question. I mean, we think AI has fundamentally changed the game. And the reason it’s changed the game is that if we thought change was happening fast today, it’s going to happen even faster in the world of AI, that means every business will have to make sure that software is incredibly flexible and adaptable as they deal with all these new different modalities, as the use cases change — you know, to change in terms of being able to address use cases that traditional software could not.

And what that means is that you need a data infrastructure and a data foundation that’s designed to enable change. MongoDB was built for change. The whole notion of our document model was enabled to have a very flexible schema, so you can make changes quickly. Then obviously, over time, we added lexical search and then semantic search through our Vector database functionality.

So, all of that comes out of the box. And now with the Voyage AI acquisition, we bring all these piece parts together. And we feel that staying on a relational database will no longer be a viable option just given the rate of change that every business will have to deal with, and they need a very flexible and adaptable data foundation, and that’s where we come in. Obviously, our job is to educate those customers on our advantages, but we feel — and that’s what we feel so bullish about our future because I think the pockets is actually coming to us just given our architectural advantages in this space.

Rishi Jaluria — Analyst

Yeah. That’s really helpful, Dev. And then, maybe just related to that, you about the opportunity with relational migrator in the past and really how AI can help in accelerating that, remapping the data schema, etc. What sort of momentum have you seen with relational migrator.

And maybe how should we be thinking about that as a growth driver going forward? Thank you.

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. Our confidence and bullish in the space is even higher today than it was before. I do want to say that what we’re going after is a very hard problem. And I should say, we knew this from the start, right? For example, when you’re looking at a legacy app that’s got hundreds — tens of thousands, if not thousands, not tens of thousands of store procedures being able to reason about that code, being able to decipher that code and then ultimately to convert that code takes — is a lot of effort.

And — but the good news is that we are seeing a lot of progress in that area. We see a lot of interest from our customers in this area because they are in so much pain with all the technical debt they’ve assumed. Second is that when they think about the future and how they enable AI in these applications, there’s no way they can do this on their legacy platforms. And so they’re motivated to try and modernize as quickly as possible.

We are initially focused on Java apps running on Oracle because that seems to be the most pain that customers are seeing. And we feel like FY ’26, this year is we’re going to scale out this work and then it’s really going to start showing up in our numbers in FY ’27.

Operator

Thank you. That is all the time we have for today’s question-and-answer session. I would now like to turn the call back over to Dev Ittycheria for any closing remarks.

Dev C. Ittycheria — President and Chief Executive Officer

Thank you. Thank you for everyone for joining us today. I just want to remind and to summarize that we had a really strong quarter in the year as we executed on a large opportunity. We expect this coming fiscal year to play out similar to last year with healthy new business and stable Atlas consumption trends.

We are more excited than ever about the long-term outlook, particularly around our opportunity to address expanded requirements of a database in the AI era, and we’ll continue to invest judiciously to focus on our execution — and focus on our execution to capture the long-term opportunity ahead of us. So, thank you for joining us, and we’ll talk to you soon. Take care.

Operator

This concludes today’s program. Thank you all for participating. [Operator signoff]

Duration: 0 minutes

Call participants:

Brian Raferty Denyeau — Investor Relations

Dev C. Ittycheria — President and Chief Executive Officer

Serge Tanjga — Interim Chief Financial Officer

Raimo Lenschow — Analyst

Dev Ittycheria — President and Chief Executive Officer

Unknown speaker — — Analyst

Mike Cikos — Analyst

Brent Bracelin — Analyst

Karl Keirstead — Analyst

Kingsley Crane — Analyst

Patrick Walravens — Analyst

Pat Walravens — Analyst

Brad Sills — Analyst

Patrick Colville — Analyst

Rishi Jaluria — Analyst

More MDB analysis

All earnings call transcripts

This article is a transcript of this conference call produced for The Motley Fool. While we strive for our Foolish Best, there may be errors, omissions, or inaccuracies in this transcript. As with all our articles, The Motley Fool does not assume any responsibility for your use of this content, and we strongly encourage you to do your own research, including listening to the call yourself and reading the company’s SEC filings. Please see our Terms and Conditions for additional details, including our Obligatory Capitalized Disclaimers of Liability.

The Motley Fool has positions in and recommends MongoDB. The Motley Fool has a disclosure policy.

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Shares of MongoDB Inc. (MDB) plummeted by over 26% in after-hours trade on Wednesday after the company’s 2025 guidance missed Wall Street expectations.

MongoDB reported earnings per share (EPS) of $1.28 in Q4, comfortably higher than the expected $0.66. Revenue for the quarter stood at $548.4 million, ahead of estimates of $519.84 million.

“MongoDB delivered a strong end to fiscal 2025 with 24% Atlas revenue growth and significant margin expansion. Atlas consumption in the quarter was better than expected and we continue to see good performance in new workload wins,” said CEO Dev Ittycheria.

However, what tanked the stock in after-hours trade was MongoDB’s guidance for fiscal year 2025. The company guided for revenue to be between $2.24 billion and $2.28 billion – even at the upper end, this is lower than the consensus estimates of $2.32 billion.

Its earnings guidance was worse – the company forecast EPS to be between $2.44 and $2.62, significantly lower than the expected $3.39.

MongoDB also announced a $200 million share buyback plan.

Despite the stock tanking in after-hours, retail investors on Stocktwits remained ‘extremely bullish’ about MongoDB’s prospects, primarily due to its strong Q4 performance.

One user thinks the stock could touch the $300 mark imminently.

Another user called the after-market decline an “overreaction.”

MongoDB’s stock has witnessed volatility recently, with the stock falling over 6% in the last six months. Its one-year performance is worse, with a decline of 36%.

For updates and corrections, email newsroom[at]stocktwits[dot]com.

Also See: Rigetti Computing Stock Nosedives On Q4 Earnings Miss, Retail’s Feeling Bearish

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

MongoDB(NASDAQ: MDB)
Q4 2025 Earnings Call
Mar 05, 2025, 5:00 p.m. ET

Contents:

• Prepared Remarks
• Questions and Answers
• Call Participants

Prepared Remarks:

Operator

Good day, and welcome to MongoDB’s Q4 fiscal year 2025 earnings call. At this time, all participants are in a listen-only mode. After the speakers’ presentation, there will be a question-and-answer session. [Operator instructions] Please be advised that today’s conference is being recorded.

I would now like to hand the conference over to your speaker, Brian Denyeau, from ICR. Please go ahead.

Brian Raferty Denyeau — Investor Relations

Thank you, Sherry. Good afternoon, and thank you for joining us today to review MongoDB’s fourth quarter fiscal 2025 financial results, which we announced in our press release issued after the close of the market today. Joining me on the call today are Dev Ittycheria, president and CEO of MongoDB; and Serge Tanjga, MongoDB’s interim CFO. During this call, we will make forward-looking statements, including statements related to our market and future growth opportunities, our opportunity to win new business, our expectations regarding Atlas consumption growth, the impact of our non-Atlas business, the long-term opportunity of AI, the opportunity of application monetization, our expectations regarding our win rates and sales force productivity, our financial guidance and underlying assumptions, and our plan to invest in growth opportunities in AI.

These statements are subject to a variety of risks and uncertainties, including the results of operations and financial condition that cause actual results to differ materially from our expectations. For a discussion of material risks and uncertainties could affect our actual results, please refer to the risks described in our quarterly report on Form 10-Q for the quarter ended October 31st, 2024, filed with the SEC on December 10th, 2024. Any forward-looking statements made on this call reflect our use only as of today, and we undertake no obligation to update them, except as required by law. Initially, we will discuss non-GAAP financial measures on this conference call.

Don’t miss this second chance at a potentially lucrative opportunity

Ever feel like you missed the boat in buying the most successful stocks? Then you’ll want to hear this.

On rare occasions, our expert team of analysts issues a “Double Down” stock recommendation for companies that they think are about to pop. If you’re worried you’ve already missed your chance to invest, now is the best time to buy before it’s too late. And the numbers speak for themselves:

• Nvidia:if you invested $1,000 when we doubled down in 2009,you’d have $300,764!*
• Apple: if you invested $1,000 when we doubled down in 2008, you’d have $44,730!*
• Netflix: if you invested $1,000 when we doubled down in 2004, you’d have $524,504!*

Right now, we’re issuing “Double Down” alerts for three incredible companies, and there may not be another chance like this anytime soon.

Continue »

*Stock Advisor returns as of March 3, 2025

Please refer to the table in the earnings release on the investor relations portion of our website for a reconciliation of these measures to the most directly comparable GAAP financial measure. With that, I’d like to turn the call over to Dev.

Dev C. Ittycheria — President and Chief Executive Officer

Thanks, Brian, and thank you to everyone for joining us today. I’m pleased to report that we had a good quarter and executed well against our large market opportunity. Let’s begin by reviewing our fourth quarter results before giving you a broader company update. We generated revenue of 548.4 million, a 20% year over year increase and above the high end of our guidance.

Atlas revenue grew 24% year over year, representing 71% of revenue. We generated non-GAAP operating income of 112.5 million for a 21% non-GAAP operating margin. We ended the quarter with over 54,500 customers. For the full year, we crossed the 2 billion revenue mark, while growing 19% and are roughly 20 times the size we were the year before we went public.

Overall, we were pleased with our fourth quarter performance. We had a healthy new business quarter led by continued strength in new workload acquisition within the existing Atlas customers. In addition, we again benefited from a greater than expected contribution from multiyear non-Atlas deals. Moving on to Atlas consumption.

The quarter played out better than our expectations with consumption growth stable compared to the year-ago period. Serge will discuss consumption trends in more detail. Finally, retention rates remained strong in Q4, demonstrating the quality of our product and the mission criticality of our platform. As I look into fiscal ’26, let me share with you what I see as the main drivers of our business.

First, we expect another strong year of new workload acquisition. As we said many times in the past, in today’s economy, companies build competitive advantage through custom built software. In fiscal ’26, we expect that customers will continue to gravitate toward building their competitive differentiation on MongoDB. Second, we expect to see stable consumption growth for Atlas in fiscal ’26 compared to fiscal ’25.

Usage growth to start fiscal ’26 is consistent with the environment we have seen in recent quarters. This consistency, coupled with an improved fiscal ’25 cohort of workloads gives us confidence that Atlas will continue to see robust growth as it approaches a $2 billion run rate this year. Third, as Serge will cover in more detail, we expect our non-Atlas business will represent a meaningful headwind to our growth in fiscal ’26 because we expect fewer multiyear deals and because we see that historically non-Atlas customers are deploying more of the incremental workloads on Atlas. Fourth, we are very excited about our long-term opportunity in AI, as I will explain a bit later.

In fiscal ’26, we expect our customers will continue on their AI journey from experimenting with new technology stacks to building prototypes to deploying apps in production. We expect the progress to remain gradual as most enterprise customers are still developing in-house skills to leverage AI effectively. Consequently, we expect the benefits of AI to be only modestly incremental to revenue growth in fiscal ’26. Fifth, we’ll continue scaling our application modernization efforts.

Historically, this segment of the market was not widely available to us because of the effort, cost, and risk of modernizing old and complex custom applications. In fiscal ’25, our pilots demonstrated that AI tooling combined with services can reduce the cycle time of modernization. This year, we’ll expand our customer engagements so that app monetization can meaningfully contribute to our new business growth in fiscal ’27 and beyond. To start with, and based on customer demand, we are specifically targeting Java apps running on Oracle, which often have thousands of complex store procedures that need to be understood, converted, and tested to successfully monetize the application.

We addressed this through a combination of AI tools and agents along with inspection verification by delivery teams. Though the complexity of this work is high, the revenue obtained for modernizing those applications is significant. For example, we successfully modernize our financial application for one of the largest ISVs in Europe, and we’re now in talks to modernize the majority of the legacy estate. As I take a step back, I see fiscal ’26 as a year of solid Atlas growth, enabled by a large market, superior product, and strong go-to-market execution.

We expect continued strong win rates as we acquire incremental workloads across our customer base. We will continue building on our core land expand go-to-market motion to further accelerate workload acquisition. In fiscal ’25, we saw improved sales force productivity, and we are forecasting continued improvements in fiscal ’26. In addition, we will continue investing to become a standard in more of our accounts.

We are not market constrained and even our largest accounts. For example, we finished the year with 320 customers with over $1 million in ARR, a year-over-year growth rate of 24%. This reinforces our move up market. To that end, in fiscal ’26, we will make significant incremental investments in our strategic accounts program.

Looking beyond fiscal ’26, I’m incredibly excited about our long-term opportunity, particularly our opportunity to address the expanded requirements of a database in the AI era. Let me tell you what we’re seeing in our customer base as they work to adopt AI. AI is ushering in a new era of accelerated change and every company will have to adapt. We are witnessing a once in a generation shift that will fundamentally reshape industries, accelerate the pace of innovation and redefine competitive dynamics in ways we’ve never seen before.

We joke that the world will move so fast that tomorrow’s plans will happen yesterday. The winners will be those companies that can transform and adapt quickly to the new pace of change. Those cannot, will fall rapidly behind. AI is transforming software from a static tool into a dynamic decision-making partner.

No longer limited to pre-defined tasks, AI powered applications will continuously learn from real time data, but this software can only adapt as fast as the data infrastructure is built on, and legacy systems simply cannot keep up. Legacy technology stacks were not designed for continuous adaptation. Complex architectures, batch processing, and rigid data models create friction at every step, slowing development, limiting organization’s ability to act quickly and making even small updates time consuming and risky. AI will only magnify these challenges.

MongoDB was built for change. MongoDB was designed from the outset to remove the constraints of legacy databases, enabling businesses to scale, adapt and innovate at AI speed. Our flexible document model handles all types of data while seamless scalability ensures high performance for unpredictable workloads. With the Voyage AI acquisition, MongoDB makes AI applications more trustworthy by pairing real time data and sophisticated embedding and retrieval models that ensure accurate and relevant results.

We also simplify AI development by natively, including vector and text search directly in the database, providing a seamless developer experience that reduces cognitive load, system complexity, risk, and operational overhead, all with the transactional, operational, and security benefits intrinsic to MongoDB. But technology alone isn’t enough. MongoDB provides a structured solution oriented approach that addresses the challenges customers have with the rapid evolution of AI technology, high complexity, and a lack of in-house skills. We are focused on helping customers move from AI experimentation to production faster with best practices that reduce risk and maximize impact.

Our decision to acquire Voyage AI addresses one of the biggest problems customers have when building and deploying AI applications, the risk of hallucinations. AI-powered applications excel where traditional software often falls short, particularly in scenarios that require nuanced understanding, sophisticated reasoning, and interaction and natural language. This means they are uniquely capable of handling tasks that are more complex and open ended. But because AI models are probabilistic and not deterministic, that can hallucinate or generate falls from misleading information.

This creates serious risks. Imagine a financial services agent that autonomously allocates capital on behalf of its customers or a cancer screening application in the hospital that analyzes scans to detect early signs of pancreatic cancer. For any mission-critical application, inaccurate or low quality results are simply not acceptable. The best way to ensure accurate results is through high quality data retrieval, which ensures that not only the most relevant information is extracted from an organization’s data with precision.

High-quality retrieval is enabled by vector embedding and reranking models. Voyage AI’s embedding and reranking models are among the highest rated in the Hugging Face community for retrieval, classification, clustering, and reranking, and are used by AI leaders like Anthropic, LangChain, Harvey and Replit. Voyage AI led by Stanford professor, Tengyu Ma, who has assembled a world-class AI research team from AI labs at Stanford, MIT, Berkeley, and Princeton. With this acquisition, MongoDB will offer best-in-class embedding and reranking miles to power native AI retrievable.

Put simply, MongoDB democratizes the process of building trustworthy AI applications right out of the box. Instead of cobbling together all the necessary piece parts, an operational data store, a vector database, and embedding and reranking models, MongoDB delivers all of it with a compelling developer experience. As a result, MongoDB has redefined the database for the AI era. Now, I’d like to spend a few minutes reviewing the adoption trends of MongoDB across our customer base.

Customers across industries and around the world are running mission-critical projects in Atlas, leveraging the full power of our platform, including Informatica, Sonos, Zebra Technologies, and Grab. Grab, Southeast Asia’s leading super app, which provides everyday services like deliveries, mobility, digital financial services, and serves over 700 cities in eight Southeastern Asian countries, successfully migrated its key app, Grab Kiosk, to Atlas. Atlas provide Grab with automated, scalable and secure platform, which empowers engineering teams to focus on product development to accommodate Grab’s rapid growth. By leveraging Atlas, Grab achieved significant efficiency gains, saving around 50% of the time previously spent on database maintenance.

The Associated Press, the Catalan Department of Health, Urban Outfitters, and Lombard Odier are turning to MongoDB to modernize applications.Urban Outfitters chose MongoDBS’ database platform to provide a flexible, scalable foundation for its infrastructure with the vision of integrating data across systems for elevated and consistent customer experiences, the retailer found legacy database inadequate. By adopting Atlas and a flexible document model, Urban Outfitters accelerated development, boosted scalability, while seamlessly integrating data. This transformation facilitated the introduction of AI-driven personalization and cutting-edge search features enriching the shopping experience across both digital and physical spaces. Mature companies and start-ups alike are using MongoDB to help deliver the next wave of AI-powered applications to their customers, including Swisscom, NTT Communications, and Paychex.

Swisscom, Switzerland’s leading provider of mobile, Internet and TV services, deployed in new gen AI app in just 12 weeks using Atlas. Swisscom implemented Atlas to power a rag application for the East Foresight library, transforming unstructured data such as reports, recordings and graphics into vector embeddings that large language models can interpret. This enables Vector Search to find any relevant context resulting in more accurate and tailored responses for users. In summary, we had a healthy Q4.

We saw stabilizing Atlas consumption growth along with a strong new business quarter and we remain confident in our ability to execute on a long-term opportunity. Fiscal ’26 is a transition year as we execute on our go-to-market motion, while investing to prepare to capture the AI opportunity, both through greenfield AI applications and AI-assisted modernization of legacy applications, we want to capitalize on a once in a generation opportunity. With that, here’s Serge.

Serge Tanjga — Interim Chief Financial Officer

Thanks, Dev. I’ll begin with a detailed review of our fourth quarter results and then finish with our outlook for the first quarter and full fiscal year 2026. First, I will start with our fourth quarter results. Total revenue in the quarter was $548.4 million, up 20% year over year and above the high end of our guidance.

Shifting to our product mix, let’s start with Atlas. Atlas grew 24% in the quarter compared to the previous year and now represents 71% of total revenue compared to 68% in the fourth quarter of fiscal 2024 and 68% last quarter. Atlas revenue is recognized primarily based on customer consumption of our platform, and that consumption is closely related to end-user activity of their applications/ Let me provide some context on Atlas consumption in the quarter. In Q4, consumption was ahead of our expectations.

If we compare this year’s Q4 with Q4 fiscal year ’24, both usage and consumption growth were stable on a year-over-year basis. While this is only one quarter and consumption trends around the holidays can be particularly volatile, we are encouraged to see signs of stability and consumption growth. Turning to non-Atlas revenue, non-Atlas came in ahead of our expectations, in part due to greater than expected contribution from multiyear deals, as Dev mentioned. As you know, due to ASC 606, we recognized the entire term license component of a multiyear contract at the start of that contract.

This multiyear license revenue benefit was over $10 million more than was contemplated in our Q4 guidance. We realize that ASC 606 introduces increased variability into our non-Atlas revenue, making it harder to understand underlying trends. To address that, we wanted to provide some incremental color. If we look at non-Atlas ARR growth rather than revenue, in Q4 of fiscal year ’25, the growth was in the mid single digits year over year compared to low double-digit growth in the year ago period.

We observed that customers who are predominantly non-Atlas historically are deploying a growing share of incremental workloads on Atlas. In other words, the revenue growth of those customers is increasingly showing up in out. Turning to customer growth, during the fourth quarter, we grew our customer base by approximately 1,900 sequentially, bringing our total customer count to over 54,500, which is up from over 47,800 in the year-ago period. Of our total customer count, over 7,500 are direct sales customers, which compares to over 7,000 in the year-ago period.

The growth in our total customer count is being driven primarily by Atlas, which had over 53,100 customers at the end of the quarter compared to over 46,300 in the year-ago period. It’s important to keep in mind the growth in our Atlas customer count reflects new customers to MongoDB in addition to existing EA customers adding incremental Atlas workloads. In Q4, our net ARR expansion rate was approximately 118%. The decline versus historical period is attributable to a smaller contribution from expanding customers.

We ended the quarter with 2,396 customers with at least $100,000 in ARR and annualized MRR, up from 2,052 in the year ago period. As Dev mentioned, we also finished the year with 320 customers spending $1 million or more annualized on our platform compared to 259 a year ago. Moving down the income statement. I will be discussing our results on a non-GAAP basis, unless otherwise noted.

Gross profit in the quarter was $411.7 million, representing a gross margin of 75%, which is down from 77% in the year-ago period. Our year-over-year gross margin decline is driven in part by Atlas growing as a percent of the overall business. Our income from operations was $112.5 million or a 21% operating margin for the fourth quarter compared to a 15% margin in the year ago period. Our operating income results versus guidance benefited from our revenue outperformance.

In addition, we benefited from timing of hiring around year-end. Net income in the fourth quarter was $108.4 million, or $1.28 per share based on 84.6 million diluted weighted average shares outstanding. This compares to a net income of $71.1 million or $0.86 per share on 82.9 million diluted weighted average shares outstanding in the year-ago period. Turning to the balance sheet and cash flow.

We ended the fourth quarter with $2.3 billion in cash, cash equivalents, short-term investments, and restricted cash. During Q4, we also completed the redemption of our 2026 convertible notes, and as a result, our balance sheet is debt free. Operating cash flow in the fourth quarter was $50.5 million, after taking into consideration approximately $27.6 million in capital expenditures and principal repayments of finance lease liabilities, free cash flow was $22.9 million in the quarter. This compares to free cash flow of $50.5 million in the year-ago period.

Our Q4 capex included approximately $24 million for purchase of IPv4 addresses, as we discussed previously. This concludes our IPv4 address purchases. I’d now like to turn to our outlook for the first quarter and full fiscal year 2026. For the first quarter, we expect revenue to be in the range of $524 million to $529 million.

We expect non-GAAP income from operations to be in the range of $54 million to $58 million, and non-GAAP net income per share to be in the range of $0.63 to $0.67 based on 86 million estimated diluted weighted average shares outstanding. For the full fiscal year 2026, we expect revenue to be in the range of $2.24 billion to $2.28 billion, non-GAAP income from operations to be in the range of $210 million to $230 million and non-GAAP net income per share to be in the range of $2.44 and $2.62 based on 87.3 million estimated diluted weighted average shares outstanding. Note that the non-GAAP net income per share guidance for the first quarter and full fiscal year 2026 include a non-GAAP tax provision of approximately 20%. I’ll now provide some more context on our guidance, starting with the full year.

First, as Dev mentioned, we expect roughly stable Atlas consumption growth compared to fiscal year ’25. Atlas consumption will benefit from stronger contributions from workloads acquired in fiscal year ’25 compared to the contribution that fiscal year ’24 workloads had last year. As you know, we made changes to sales compensation plans at the start of last year to focus more on the size of new workloads acquired, and we believe that those changes are having the desired impact. Second, we expect our non-Atlas subscription revenue will be down in the high-single digits for the year.

The primary reason is that we expect an approximately $50 million headwind from multiyear license revenue in fiscal year ’26, an estimate that is based on a bottoms-up analysis of our non-Atlas renewal base. Simply put, after two years of very strong multiyear performance, we expect the mix of multiyear non-Atlas revenue to not only be lower than the last two years, but also below the historical trends. This is due to the fact that in fiscal year ’26, we have a more limited set of large non-Atlas accounts that can sign multiyear deals. Finally, I wanted to provide some context to better understand our operating margin guidance.

We expect operating margin of 10% at the midpoint of the range, down from 15% that we reported in fiscal year ’25. There are three primary reasons for the margin decline. First, the $50 million of fiscal year ’25 multiyear license revenue that won’t repeat in fiscal year ’26 is very high margin, making for a difficult margin compare. This will primarily impact the second half of the year.

Second, we are investing aggressively in R&D, inclusive of the recently announced acquisition of Voyage AI. We see an opportunity to further distance ourselves from the competition in terms of performance and scalability and to redefine what it means to be a database in the age of AI. Third, we are increasing our marketing investments, specifically to drive improved awareness and understanding of MongoDB’s capabilities. Our goal is to better educate new and existing customers on the full power of our platform and highlight the widening gap between us and the legacy competitors.

Moving on to our Q1 guidance, a few things to keep in mind. First, we expect Atlas revenue to be flat to slightly up sequentially. Please keep in mind that Q1 has three fewer days than Q4. Also, the typical seasonally slower Atlas consumption growth during the holidays has a bigger impact on incremental Q1 revenue that it did in Q4, thereby negatively impacting sequential revenue growth.

Second, we expect to see a meaningful sequential decline in EA revenue. As discussed in the past, Q4 is our seasonally highest quarter in terms of our EA renewal base, which is a strong indicator of our ability to win new EA business. In Q1, the EA renewal base is sequentially much lower. Third, we expect operating income to decline sequentially due to the lower revenue, as well as our increased pace of hiring.

Finally, let me address how the acquisition of Voyage AI will impact our financials. We disclosed last week that the total consideration was $220 million. Most Voyage shareholders received a consideration in MongoDB stock with only $20 million being paid out in cash. To offset the dilutive impact of the acquisition, today, we are announcing that our board has authorized a $200 million stock buyback.

In fiscal year ’26, we expect an immaterial amount of revenue from the acquisition as we work to expand the reach of the technology and integrate it into the MongoDB database. On the expense side, we attempt to grow the Voyage team to accelerate innovation and help with integration. These expenses will show up in the R&D line in our income statement and will be modestly dilutive to operating margin for the year. To summarize, MongoDB delivered strong fourth quarter results.

We are pleased with our ability to win new business and see stable consumption trends in Atlas. We remain incredibly excited about the opportunity ahead, and we’ll continue to invest responsibly to maximize our long-term value. With that, I would like to open it up for questions. Operator?

Questions & Answers:

Operator

And our first question will come from the line of Raimo Lenschow with Barclays. Your line is open.

Raimo Lenschow — Analyst

Perfect. Thank you, and two quick questions from me. One is on the multiyear guidance or the multiyear situation, like, if you look like this quarter and the quarters before, you overperformed there. The guidance is, obviously, your expenses were slightly, you know, weaker because you have a lower renewal portfolio.

Is it just a portfolio or do you see a change in trend there? So, is it just a mechanical problem or like — or mechanical situation or is there also a change in behavior? And then, I had one follow-up.

Serge Tanjga — Interim Chief Financial Officer

Yeah. So, Raimo, why don’t I take that one. Thank you for the question. So, let me just make sure that I repeat and level set.

So, in fiscal year ’24, we had exceptionally strong multiyear performance led by our Alibaba deal. And going into fiscal year ’25, we expected a $40 million headwind based on the assumption that fiscal year ’25 would be in line with long-term trends. Instead, after a strong Q3 and Q4, the ultimate headwind was significantly lower than that $40 million. And that creates the renewal base effect that sets us up for fiscal year ’26.

So, what I mean by that is, because we’ve done so many more multiyear deals in fiscal year ’24 and ’25, the renewal base and the opportunity is just much lower to begin with. So, it’s not a change in trends. In fact, we assume same conversion rates as historically is just the opportunity set is lower in fiscal year ’26.

Raimo Lenschow — Analyst

OK. Perfect. And then if you think about the Voyage acquisition, like, how do you need to think about that in terms of getting that into the organization and into the market? Is that kind of going to be like an attachment to what you were doing? Or do you think it’s going to be sold broader than just into the MongoDB installed base? Thank you.

Dev C. Ittycheria — President and Chief Executive Officer

Thanks, Raimo. I’ll take that question. Today, Voyage AI does offer its models to other third parties, and we will continue to do that. We think it’s important for people to have access to the best-in-class models.

We also believe that, that will be a great way to bring people new to MongoDB into the MongoDB, you know, sphere, and that’s a way for us, that will be, in the short to medium term, a better-together story where we will basically integrate Voyage AI into the MongoDB platform and do things like auto embeddings where data will be embedded as soon as it’s basically entered into a MongoDB platform, which will make a developer’s life that much easier versus having to go to some third party to get the data embedded and then to use our vector store. And then, we have a bunch of other things that we plan to do in terms of the product road map in terms of more sophisticated model, more domain-specific models, etc. And we’ll talk about that in future calls. But we do want to make this available to all customers, including people who are not MongoDB customers today, and we think that’s good for the business long term.

Operator

Thank you. One moment for our next question. And that will come from the line of Sanjit Singh with Morgan Stanley. Your line is open.

Unknown speaker — — Analyst

Great. Thank you, guys. You got [Inaudible] on for Sanjit. Maybe with my first question, building on Raimo’s question on Voyage AI, when you think about the decision to acquire Voyage AI, could you sort of double click again on the reasons — and particularly, with a look on your portfolio, what were the aspects that either existing or new customers couldn’t do with your portfolio that they can now pursue with the technology that you acquired through the Voyage AI? And then, as a second question, as it relates to your operating expense guidance that’s implied in your investments there.

Last quarter, you talked a lot about reallocating investments. So, I’d be curious just if you can double click on what’s changed over the last 90 days that really pushed you to make those incremental investments from — I appreciate the reasons that you gave, some of those like the $50 million multiyear, Dev, you probably had some visibility on that 90 days ago. So, sort of what has changed in those 90 days that pushed you to make those incremental investments?

Dev C. Ittycheria — President and Chief Executive Officer

So great. I’ll start — I’ll address the Voyage AI question, and then I’ll hand it off to Serge to talk about opex. So, stepping back and just thinking from a customer’s perspective, one of the main reasons what gives customers pause in terms of deploying mission-critical AI use cases is the risk of hallucinations. Because AI systems are probilistic, you can’t always guarantee what the output will be.

And if you’re in a regulated industry, whether it’s financial services or healthcare or other industries where precision of the response or the quality of response really matters, it really prevents people from deploying these production level AI use cases. So, the reason we acquired Voyage AI is to provide what’s called embedding and reranking models. And let me just explain, you know, how this all works. So, think about the LLM as the brain.

Think about the dat;abase is about your memory and the state of where how things are. And so — and then think about embedding as an ability to find, you know, the right information for the right question. So, imagine you have a very smart person, say, like, Albert Einstein on your staff and you’re asking him, in this case, the LLM, a particular question. While Einstein still needs to go, you know, do some homework based on what the question is about finding some information before he can formulate an answer, rather than reading every book in a library, what the embedding models do is essentially act like a library and pointing Einstein to the right section, the right aisle, the right shelf, the right books, and the right chapter on the right page, to get the exact information to formulate an accurate and high-quality response.

So, the performance gains you get by leveraging embedding models is significant. And even embedding models themselves have different qualities, and Voyage AIs embedding models are typically the top rank models on Hugging Face. So, we know a lot of ISVs have already reached out to us since the acquisition saying they switched to Voyage from other model providers and they got far better performance. So, the value of Voyage is being able to increase the quality and hence the trustworthiness of these AI applications that people are building in order to serve the most demanding and mission-critical use cases.

Serge Tanjga — Interim Chief Financial Officer

Yeah. And I’ll take the opex question. So, you’re absolutely right. We are both reallocating and reinvesting at the same time.

And so, 90 days ago, we talked about some reallocations in our sales and marketing line where we’re reducing our investment in the mid-market in order to deploy those resources in the upmarket. And then, we also talked about discontinuing or deemphasizing a few products so that we can focus more on the remaining portfolio where we see the traction and the opportunity. We are investing over and above what we’re reallocating, and that was the plan all along. And the reason for that is because of the opportunity that we see.

You’ve heard Dev talked in his prepared remarks about the unique opportunity that AI will present for people to revisit their infrastructure stack. And we see that as a unique once in a lifetime opportunity that we want to capitalize on. And what we don’t want to do as a management team is sit here five years from now and wonder whether we invested enough to fully maximize our long-term opportunity. And what gives us comfort in this investment is, frankly, our margins track record.

So, if you go back and take a step back and go back as far as the IPO, our margins went in the negative 30%, and obviously, we’ve come a long way in terms of growth and margin expansion at the same time. And even if you look more recently over the last couple of years, at the moments when we slowed investments, we saw margin spike, including, frankly, in Q4, where we printed 21% operating margin, which is in line with our long-term guidance. So, we have confidence that the economics of the business are strong and that the business scales, but it’s about investing at the right moment in time and the conviction that we have to really play offense and optimize on our opportunity.

Operator

Thank you. One moment for our next question. And that will come from the line of Mike Cikos with Needham. Your line is open.

Mike Cikos — Analyst

Hey, guys. Thanks for taking the questions here. I wanted to come back — I know we’re talking about the Atlas consumption trends and how they’re shaking out, where we sit today. Just curious, when we think about the full year, you guys are talking about taking most recent couple of quarters as far as how that consumption has played out.

And is there anything specific to Q4 consumption that started to drive this dynamic on the growth? I’m interested in what you would point to. Was it the improving sales initiatives in the cohort you guys are capturing or, is there something else you could point us to on that for?

Serge Tanjga — Interim Chief Financial Officer

Yeah. I’ll take the first one on that, Mike. So, when it comes to Q4, first of all, as we’ve discussed in the past, it’s sort of the seasonally slowest quarter of the year in terms of consumption growth because we do see both usage and consumption slowdown around the holidays, and we saw that happen. Q4 consumption was lower than Q3.

[Technical difficulty] apparent volatility when it comes to the holiday season. When it comes to stable consumption growth in fiscal year ’26 though, I would [Technical difficulty] consumption in three components. So, the first [Inaudible] is the base itself, which is obviously the largest, but it drove the percentage rate because, you know, it just the oldest workload. That’s layer one.

Now layer two is workload the prior year. Those workloads in the current year are meaningful and are still growing [Technical difficulty] in any given year, we need the workloads of the prior year and the workloads of the current year to basically offset the growing base effect. And so, last year, we were not able to do that, you know, for three reasons. Number one is, the base itself slowed down, which was a macro phenomenon that we called out in Q1.

Secondly, fiscal year ’24 workloads didn’t meet our expectations going into fiscal year ’25. And then, new workloads in fiscal year ’25, we’re off to a slow start slightly for operational reasons, and that kind of was a headwind that we face for the rest of the year. So, now turning the calendar forward for this year, we are calling for a stable macro environment and usage growth in the base. Obviously, we don’t have a crystal ball, but that’s what we see currently.

Then we’re expecting more from fiscal year ’25 workloads. We’re optimistic than those are doing better based on the data that we have. And because of our move upmarket, we expect to get more new workload ARR and sales productivity in fiscal year ’26 cohort. And those two things offset the fact that the base is again larger than it was a year ago and result in stable consumption growth.

Mike Cikos — Analyst

Thank you for that, Serge. Really appreciated. And for a follow-up here. I know that we’re citing this $50 million multiyear headwind as it relates to the non-Atlas business.

Can you kind of chunk that up? Is — like, if I’m thinking about Q1, Q2, is there any way you can help us get a sense of what those headwinds are on a quarter-by-quarter basis?

Serge Tanjga — Interim Chief Financial Officer

It’s sort of the mirror image of the outperformance that we’ve seen here in Q3 and Q4 that we called out. And so, I would think of it as a back half weighted phenomenon.

Mike Cikos — Analyst

Got it. Thank you so much, guys.

Operator

Thank you. One moment for our next question. And that will come from the line of Brent Bracelin with Piper Sandler. Your line is open.

Brent Bracelin — Analyst

Thank you. Good afternoon. I wanted to double click into Atlas. If we normalize for the unused credits last year, the implied Atlas growth here in the low-20s is actually a bit of a bigger step down in growth.

So, could you just revisit the growth levers as we think about Atlas here? I know, it’s a larger business going into this year than last, but it does look like normalized growth after accounting for the unused credits last year is decelerating a little bit more. Just curious why.

Serge Tanjga — Interim Chief Financial Officer

Yeah. So, I’m going to go through the puts and takes a little bit, but I think it will help with the math. So, the first thing I would reiterate is that on average, we expect consumption growth in fiscal year ’26 to be stable with what we’ve seen in fiscal year ’25. So, that’s point number one.

Point number two is you have the total guidance. And then, you can take the high-single digit rate of decline in the non-Atlas business. And that will give you a sense of what is — what’s left in Atlas, and that fits with the roughly stable Atlas consumption growth in fiscal year ’26. The final thing I would say is, as you think about the growth in fiscal year ’25, just a reminder that what matters is the exit rate as opposed to the average throughout the year because we have seen revenue slow down on a year over year basis because we have had slower assumption in all quarters — consumption growth in all quarters, except Q4 of last year.

Brent Bracelin — Analyst

Got it. And then, Dev, as a follow-up for you. We’ve seen AI workloads, I would argue, in the experimental phase for the last two years. We’re now seeing AI go into production, starting to see early signs of some of these agentic functions show up in revenue.

What’s your expectation as you think about customer conversations, customers that are in experimentation going to production? When do you expect to see a bit of a lift there on your business?

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. So, again, we do see — I mean, we have some high-profile AI companies who are building on top of Atlas. I’m not at liberty to name who they are, but in general, I would say that the AI journey for customers is going to be gradual. I would say one is a lack of AI skills in their organizations.

They really don’t have a lot of experience and it’s compounded by the rapid evolution of AI technology that they feel like it’s very hard for them to kind of think about like what’s stack to use and so on and so forth. The second, as I mentioned earlier, on the Voyage question, there’s also a real worry about the trustworthiness of a lot of these applications. So, I would say, the use cases you’re seeing are fairly simplistic, customer chatbots, maybe document summarization, maybe some very simple agentic workflows. But I do think that that, you know, we are in the early innings, and I expect that sophistication to increase as people get more and more comfortable.

We think architecturally, we have a huge advantage of the competition. One, the document model really supports different types of data, you know, structured, semi-structured, and unstructured. We embed, you know, a search and Vector Search onto a platform. No one else does that.

But then, we’ve now — with the Voyage AI, we have the most accurate embedding and reranking models to really address the quality and trust issue. And all this is going to be put together in a very elegant developer experience that reduces friction and enables them to move fast. So, we feel we are really well positioned for this opportunity. And we’re really excited.

We are already obviously excited about what Voyage brings to us and excited by what customers are telling us. But we do think it’s going to take some time because customers, again, are naturally, you know, getting their arms around this technology and starting slowly.

Operator

Thank you. One moment for our next question. And that will come from the line of Karl Keirstead with UBS. Your line is open.

Karl Keirstead — Analyst

Thanks. Dev, on the last call and even the prior one, you talked quite a bit about this go-to-market pivot where you were pushing MongoDB to go after more opportunities upmarket. To what extent is that go-to-market transition reflected in your guidance? Are you assuming some upside from that effort in your revenue guidance? And conversely, does that require a decent amount of sales investments that might be a factor in your margin guidance? And how is that effort going at a high level? Thank you.

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. Thanks for the question, Karl. We’re really pleased with the progress we’re making as evidenced by just even the data point we shared on the $1 million customers. I mean, that customer count is growing faster than our — the rest of our customer base.

So, we’re already seeing dividends from the investors were making up market. And we did see sales productivity gains last year from the move-up market, and so we expect even further sales productivity gains this year. In terms of the margin, we actually reallocated investments in sales, moving resources from the midmarket to the upmarket. So, I wouldn’t say that there was a demonstrable increase in sales investments.

The investments are really more in R&D and driving more awareness of our platform and educating — spending more time in educating customers because you still find that a lot of people are still not completely aware of MongoDB’s full capabilities and also — don’t necessarily have the skills to use all of our capabilities. So, you’re seeing a lot of investments going there. And that’s what we’re really focused on. But in terms of the move-up market, we’re really happy with the results we’re seeing.

Serge Tanjga — Interim Chief Financial Officer

And, Karl, the only thing I would add is that that increased productivity is definitely a part of the guidance.

Karl Keirstead — Analyst

OK. Terrific. Thank you, both.

Operator

Thank you. One moment for our next question. And that will come from the line of Kingsley Crane with Canaccord Genuity. Your line is open.

Kingsley Crane — Analyst

Hi. Thanks for taking the question. So, again, on Voyage AI, you mentioned that technology is not enough in the prepared remarks. So, to what extent do you think feature sets like that Voyage can drive workload creation within AI apps or is that more market oriented? And then, is Voyage additive in its ability to reduce vector storage costs similar to your efforts and quantitation?

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. So, a couple of points. I’m just stepping back. We see two big challenges that customers have.

They have a skills gap, and then they have a trust gap with AI. Voyage AI addresses the trust gap, enabling to build high-quality AI applications where the results — they have a high degree of confidence in. But the skills gap is still inherent to these organizations. So, what we are doing is not just bringing technology but we’re really taking a solutions approach where we come in together with the combination of technology, best practices, experience so that we can really help customers deal with their business problems, not just throw technology at them.

And customers really appreciate this approach. And so, you’ll see us really take more of a solution approach to help, for example, in modernizing their existing legacy applications, as well as helping them build new AI applications. In terms of storage, yes, the advances we made in the quantization really reduced the storage cost and improves the performance of our Vector store. I would say with these embedding models are slightly different.

What that’s doing is essentially helping really quickly find the precise information needed based on the query being posted to the application or to the underlying LLM to get the best quality answer. So, we really feel like this is all about like increasing the trustworthiness and the accuracy — through the accuracy of the results that are generated from these AI applications.

Kingsley Crane — Analyst

Great. Really helpful. And a quick follow-up. How did GCP partner influenced deals far in the quarter? You called out strength last quarter and that you were looking to do more of them in Q4.

I also saw that they made some cuts more recently. Thanks.

Dev C. Ittycheria — President and Chief Executive Officer

No. Our relationship with Google Cloud is still very constructive and productive. I mean, generally, I would say, our relationship with all the hyperscalers is very positive. And so, we’re working with them depending on the customers.

I see some customers have relations with only one hyperscaler, sometimes they have relationships with multiple hyperscalers. And we work closely with GCP, as well as AWS and Azure, and I would say, all three are actually quite productive.

Operator

Thank you. One moment for our next question. And that will come from the line of Pat Walravens with Citizens Bank. Your line is open.

Patrick Walravens — Analyst

Great. Thank you. I was wondering if you could just step back for us and give us sort of the five year trajectory on non-Atlas, because I look at the growth rates going back, ’21 was 23%; ’22, 19%; ’23, 25%; [Inaudible] so was there a period there where it exceeded your expectations? And then, where it came in below, what you thought. Sort of what was the ebb and flow of non-Atlas?

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. I wanted to say, we don’t really manage the business necessarily by product. We manage it by channel and really work from a customer orientation working backwards. What we do see at the high end of the customer mark — segment is that customers do like choice.

They don’t necessarily believe that every workload will go to the cloud. And in many cases, some customers are still very much focused on building their technology stack on-prem. In fact, a lot of large banks in Europe and actually a number of banks here in the U.S. have pre-dispositions and workloads on-prem.

So, it’s really about serving the customers’ needs. The customers do like the ability to have choice on how they run their workloads. And — but we do also see it, and this is what’s called out in the prepared remarks, for those customers who start with EA who have a significant amount of EA, we are seeing them — seeing more of those incremental workloads move to Atlas. And some of these new capabilities, like, Voyage now that will be available only on Atlas.

And so, there are some things that we’re doing that you’ll see customers probably inherently do more on Atlas. And I’ll hand — you know, I’ll let Serge comment on your question on the guide.

Serge Tanjga — Interim Chief Financial Officer

Yeah. So, I think that — I would just stress a couple of things, Pat. One is, we talked in prepared remarks about non-Atlas ARR growth being in the mid single digits year over year in Q4 and that being slowed down from double digits growth in Q4 of fiscal year ’24. And that’s the phenomenon that Dev is talking about, which is that, we are seeing increasingly customers who are historically not-Atlas deploying incremental workloads on Atlas.

They do deploy incremental workloads on EA, that’s why that line item continues growing, and we expect it to continue growing. But we see more and more of it actually coming on Atlas. So, if you look at the ARR of those customers, it’s actually growing more than what the just the non-Atlas component would suggest, and that’s baked into both the Atlas and the non-Atlas portion of the guide.

Patrick Walravens — Analyst

OK. And then just as a follow-up, and you might not be able to comment on this. But as we look out past ’26, I know you don’t run the business this way, but we do model it this way. So, as we look out past ’26, should we expect the growth to stay really muted?

Serge Tanjga — Interim Chief Financial Officer

Yeah. So, I would say two things. One is, the puts and takes are the following. We do still have low market share even in those customers who are predominantly non-Atlas.

So, we do expect to continue growing workloads that we can acquire in EA, number one. Number two, we do expect to move to the cloud to continue. So, we do expect those customers for us to gain even more share in those customers by getting incremental Atlas workloads. And then, a bit of a question mark at this point is, sort of, how the app modernization initiative is going to play out.

We think that will benefit both Atlas and non-Atlas — or EA rather,. And so obviously, that’s still nascent and it’s sort of hard to ascertain, but that actually all to be helpful across the board.

Operator

Thank you. One moment for our next question. And that will come from the line of Brad Sills with Bank of America. Your line is open.

Brad Sills — Analyst

Great. Thank you so much. A question for you, Dev. You mentioned fiscal ’26 kind of being a year of transition.

I wanted to get your thoughts on what that means exactly. It seems to me that the consumption patterns are stabilizing. You’re seeing some traction with new workloads. Last year was a year of kind of go-to-market changes.

It feels like this would be the year where you would start to see some progress on some of the transition items you saw last year. So, maybe transition is a little bit strong as a way to describe this year, but I just wanted to kind of double-click on your thoughts on that.

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. So, let me be clear. I feel very bullish about the future of this business. I have not been excited like this for a long time.

I think the way people are building these new AI locations are already made for a platform like MongoDB in terms of ability to handle different data types, the scalability of the platform to be able to natively support lexical semantics search and obviously now to be able to also give a very elegant experience to be able to leverage embedding and reranking models. So, that’s — I feel very bullish. And I think this business can grow meaningfully faster than it is today. But we are obviously making the right investments.

We believe the right investments to kind of position the company for that growth. We’re pleased to see that the Atlas business is stabilizing, and that was obviously mentioned by both myself and Serge in the prepared remarks. I know that’s been a question for a lot of investors. I think obviously, with the EA business, there’s the puts and takes with this multiyear, but the long-term trends are in our favor.

It’s a big market. We’re going after, you know, essentially a big opportunity because customers are essentially looking to run their business through custom software. And I believe that, you know, when you think about like a competitive differentiation against the other players in the space, I think we are very, very differentiated and that will show up in the numbers over time.

Serge Tanjga — Interim Chief Financial Officer

Yeah. The only thing I would add, Brad, is that it’s a transition year in a sense that some of our largest initiatives and focus areas, those being application modernization and then generally winning the AI stack are going to only incrementally be beneficial to our revenue this year, but we expect them to be meaningful growth drivers in years beyond.

Brad Sills — Analyst

Wonderful. Thanks for that. And then, would love to get your thoughts on where you’re seeing new workloads strength that you called out. Any categories in particular? Thank you.

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. Actually, the short answer is, we’re seeing it everywhere. We’re seeing it both at the high end of the market, as well as at the low end of the market. If you see our customer count, our customer count — new customer count for this quarter, this past quarter was quite strong.

And so — and as we called out, our move upmarket is generating our $1 million customer count is actually growing faster than our overall customer base. So, we’re seeing results at both the top end and the bottom end of the market.

Operator

Thank you. One moment for our next question. And that will come from the line of Patrick Colville with Scotiabank. Your line is open.

Patrick Colville — Analyst

Thanks so much for taking my question. I guess, Dev, this one’s for you, please. So, MongoDB is obviously doing a lot of things right. So, I guess, I just want to ask around the competitive environment as of today.

How is MongoDB competing with the hyperscalers and Postgres as of today? And is there any difference to the competitive environment, call it, this time of year about March 2024. Thank you.

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. Well, I’ll say that — I’ll make two main points, and I’ll explain what they are. One, a lot of people do compare MongoDB to Postgres. And I think that’s actually a false comparison because Postgres is just an OLTP database.

With MongoDB, the right comparison is Postgres plus Elastic plus something like Pinecone plus maybe like an embedding model from like either like Open AI or Cohere. So, when you package all those components together, you get a like-for-like comparison with MongoDB. And I think obviously, customers much prefer to have a much more elegant solution than trying to cobble all these pieces together and try and figure out how to make it all work. The second point I’d say is, MongoDB is frankly a much better OLTP database than Postgres.

Postgres is based on the relational architecture. It’s very rigid. It doesn’t handle unstructured data well. It claims to support JSON data, but the performance of anything north of like 2 kilobytes of JSON data, the performance of Postgres really suffers.

And it’s not very scalable. And I think what Postgres is the beneficiary of is the lift and shift of Oracle and Sybase and SQL Server because they’re the open source relational standard, but they’re not exactly competing for the same workloads as we are. Our win rates against Postgres are very high. When we talk to our salespeople, when we can explain the value proposition of MongoDB against Postgres, our win rates are incredibly high.

We just want to get into more battles. And what we recognize is people who don’t know MongoDB may just gravitate to Postgres as their solution because they just don’t know how to use MongoDB. And that’s what we’re working on in terms of generating more awareness and infusing more skills into our existing customers as well as the new customers who want — we want to come to our platform.

Patrick Colville — Analyst

Very helpful. And I guess, just touch on the hyperscalers briefly.

Dev C. Ittycheria — President and Chief Executive Officer

The hyperscale is — they have their own variants of Postgres offerings, and they have the clones. I mean we haven’t seen the clones as much lately. Our win rates against the clones are very, very high. This is something we should talk about for a few years ago, but we seem to — our relations with the hyperscalers, as I mentioned on the previous question, is actually very positive.

Our salespeople partner with the hyperscalers all around the world, and what we find is that together, we win more business. And yes, there may be situations where they try and leave with the first-party services. But usually, we find that, you know, when we partner with them that they’re very accommodating and we all can do well working together. So, I would say, there’s no structural issue with the hyperscalers.

Operator

Thank you. One moment for our next question. And that will come from the line of Rishi Jaluria with RBC Capital Markets. Your line is open.

Rishi Jaluria — Analyst

Wonderful. Thanks so much for taking my question. Dev, I want to follow up on a comment you made, which is a lot of the Postgres success is from lift and shift of existing SQL applications. And we’re seeing the same thing in our own checks.

What needs to happen as companies think about net new generative AI applications for them to think about kind of reconstructing or rearchitecting those solutions from scratch, especially when they want to leverage unstructured data? And what role can you play in kind of driving that conversation more toward rebuild rather than just lift and shift?

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. That’s a good question. I mean, we think AI has fundamentally changed the game. And the reason it’s changed the game is that if we thought change was happening fast today, it’s going to happen even faster in the world of AI, that means every business will have to make sure that software is incredibly flexible and adaptable as they deal with all these new different modalities, as the use cases change — you know, to change in terms of being able to address use cases that traditional software could not.

And what that means is that you need a data infrastructure and a data foundation that’s designed to enable change. MongoDB was built for change. The whole notion of our document model was enabled to have a very flexible schema, so you can make changes quickly. Then obviously, over time, we added lexical search and then semantic search through our Vector database functionality.

So, all of that comes out of the box. And now with the Voyage AI acquisition, we bring all these piece parts together. And we feel that staying on a relational database will no longer be a viable option just given the rate of change that every business will have to deal with, and they need a very flexible and adaptable data foundation, and that’s where we come in. Obviously, our job is to educate those customers on our advantages, but we feel — and that’s what we feel so bullish about our future because I think the pockets is actually coming to us just given our architectural advantages in this space.

Rishi Jaluria — Analyst

Yeah. That’s really helpful, Dev. And then, maybe just related to that, you about the opportunity with relational migrator in the past and really how AI can help in accelerating that, remapping the data schema, etc. What sort of momentum have you seen with relational migrator.

And maybe how should we be thinking about that as a growth driver going forward? Thank you.

Dev C. Ittycheria — President and Chief Executive Officer

Yeah. Our confidence and bullish in the space is even higher today than it was before. I do want to say that what we’re going after is a very hard problem. And I should say, we knew this from the start, right? For example, when you’re looking at a legacy app that’s got hundreds — tens of thousands, if not thousands, not tens of thousands of store procedures being able to reason about that code, being able to decipher that code and then ultimately to convert that code takes — is a lot of effort.

And — but the good news is that we are seeing a lot of progress in that area. We see a lot of interest from our customers in this area because they are in so much pain with all the technical debt they’ve assumed. Second is that when they think about the future and how they enable AI in these applications, there’s no way they can do this on their legacy platforms. And so they’re motivated to try and modernize as quickly as possible.

We are initially focused on Java apps running on Oracle because that seems to be the most pain that customers are seeing. And we feel like FY ’26, this year is we’re going to scale out this work and then it’s really going to start showing up in our numbers in FY ’27.

Operator

Thank you. That is all the time we have for today’s question-and-answer session. I would now like to turn the call back over to Dev Ittycheria for any closing remarks.

Dev C. Ittycheria — President and Chief Executive Officer

Thank you. Thank you for everyone for joining us today. I just want to remind and to summarize that we had a really strong quarter in the year as we executed on a large opportunity. We expect this coming fiscal year to play out similar to last year with healthy new business and stable Atlas consumption trends.

We are more excited than ever about the long-term outlook, particularly around our opportunity to address expanded requirements of a database in the AI era, and we’ll continue to invest judiciously to focus on our execution — and focus on our execution to capture the long-term opportunity ahead of us. So, thank you for joining us, and we’ll talk to you soon. Take care.

Operator

This concludes today’s program. Thank you all for participating. [Operator signoff]

Duration: 0 minutes

Call participants:

Brian Raferty Denyeau — Investor Relations

Dev C. Ittycheria — President and Chief Executive Officer

Serge Tanjga — Interim Chief Financial Officer

Raimo Lenschow — Analyst

Dev Ittycheria — President and Chief Executive Officer

Unknown speaker — — Analyst

Mike Cikos — Analyst

Brent Bracelin — Analyst

Karl Keirstead — Analyst

Kingsley Crane — Analyst

Patrick Walravens — Analyst

Pat Walravens — Analyst

Brad Sills — Analyst

Patrick Colville — Analyst

Rishi Jaluria — Analyst

More MDB analysis

All earnings call transcripts

This article is a transcript of this conference call produced for The Motley Fool. While we strive for our Foolish Best, there may be errors, omissions, or inaccuracies in this transcript. As with all our articles, The Motley Fool does not assume any responsibility for your use of this content, and we strongly encourage you to do your own research, including listening to the call yourself and reading the company’s SEC filings. Please see our Terms and Conditions for additional details, including our Obligatory Capitalized Disclaimers of Liability.

The Motley Fool has positions in and recommends MongoDB. The Motley Fool has a disclosure policy.

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

MongoDB, Inc. (NASDAQ:MDB) Q4 2025 Earnings Conference Call March 5, 2025 5:00 PM ET

Company Participants

Brian Denyeau – IR, ICR
Dev Ittycheria – President & CEO
Serge Tanjga – Interim CFO

Conference Call Participants

Raimo Lenschow – Barclays
Bob Dion – Morgan Stanley
Mike Cikos – Needham and Company
Brent Bracelin – Piper Sandler
Kingsley Crane – Canaccord Genuity
Patrick Walravens – JMP Securities
Brad Sills – Bank of America
Patrick Colville – Scotiabank
Rishi Jaluria – RBC

Operator

Good day, and welcome to MongoDB’s Q4 Fiscal Year 2025 Earnings Call. At this time, all participants are in a listen-only mode. After the speakers’ presentation, there will be a question-and-answer session. [Operator Instructions] Please be advised that today’s conference is being recorded.

I would now like to hand the conference over to your speaker, Brian Denyeau from ICR. Please go ahead.

Brian Denyeau

Thank you, Sherry. Good afternoon, and thank you for joining us today to MongoDB’s fourth quarter fiscal 2025 financial results, which we announced in our press release issued after the close of the market today. Joining me on the call today are Dev Ittycheria, President and CEO of MongoDB; and Serge Tanjga, MongoDB’s Interim CFO.

During this call, we will make forward-looking statements, including statements related to our market and future growth opportunities, our opportunity to win new business, our expectations regarding Atlas consumption growth, the impact of our non-Atlas business, the long-term opportunity of AI, the opportunity of application monetization, our expectations regarding our win rates and sales force productivity, our financial guidance and underlying assumptions and our plan to invest in growth opportunities in AI.

These statements are subject to a variety of risks and uncertainties, including the results of operations and financial condition that cause actual results to differ materially from our expectations. For a

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Article originally posted on mongodb google news. Visit mongodb google news