MongoDB’s Sahir Azam: Vector Databases and the Data Structure of AI

Contents

Sahir Azam: In a world of probabilistic software, you know, the measure of quality is about that kind of last mile. How do you get to 99.99X sort of quality? And so will the domain of sort of quality engineering that we typically associate with manufacturing kind of apply to software? And that really got me thinking in terms of you’re not gonna be able to necessarily get a deterministic result like you would with a traditional application talking to a traditional database. So therefore, the quality of your embedding models, how you construct your RAG architectures, merge it with the real-time view of what’s happening in the transactions in your business, that’s what’s gonna get you that high quality retrieval and result. And unless it’s high quality in a world where it’s probabilistic, I don’t see it going after mission critical use cases in a conservative enterprise. And that is a problem space we’re very focused on right now.

Sonya Huang: Today we are excited to welcome Sahir Azam, who leads product and growth at MongoDB.

Sahir was one of the architects behind Mongo’s successful transformation from on-prem to the cloud, and is now helping to steer Mongo’s evolution in an AI-first world. 

Mongo’s journey into vector databases began with semantic search for e-commerce, but has evolved into something much more fundamental: becoming the memory and state layer for AI applications. 

We’re excited to get Sahir’s take on the past and future of vector databases and what shape infrastructure will take in a world of AI agents and applications and unlimited software creation.

Sonya Huang: Sahir, welcome to the show. We’re so excited to have you here.

Sahir Azam: Thanks, Sonya. I’m super excited to be here.

Sonya Huang: We’re gonna dig into everything from vector databases to embeddings to knowledge graphs and much, much more on this episode. I’d love to just start with the big picture question and maybe your hot take: Is AI gonna change the database market?

Will AI change application development?

Sahir Azam: That’s an interesting question. I think the related and probably more interesting question is whether it’s gonna change software development in applications. And I think that it really is. You know, I think we’re seeing AI-powered—generative AI-powered applications address a set of use cases that traditional kind of deterministic software hasn’t been able to go after. And I know I’ve read some stuff from Sequoia around the idea of services as software, et cetera in that whole space. And we firmly see that in terms of our early adoption of what we’re seeing in the market. And so that in turn changes the fundamental way we will interact with software, it changes the way business logic of applications will evolve over time with things like agents. And that all has underlying implications on how the database layer will need to transform as well.

Pat Grady: Can we poke on that for just a minute? So I’m curious, since you guys are operating at a layer where you see a lot of what’s being developed? What are people developing today that they could not have developed a few years ago before these capabilities emerged?

Sahir Azam: Yeah, I think on one hand, one trend we’re seeing is certainly that it’s much more easy and efficient to create software than there ever was before. So, you know, the fact that there will be more software in the world means that that’ll have implications in terms of data persistence, storage and processing. So that’s kind of one sort of related piece.

But in terms of use cases, I think the fact that we can now interact with computers in completely different ways beyond just the classic web and mobile applications that we’re all used to, you know, the more interactive experiences, I think the blending of the physical and virtual worlds in ways that I don’t think we’ve really seen yet. Obviously there’s a big trend around how AI impacts robotics. There’s a great blog I read from, I think it was from LangChain the other day, around sort of ambient agents and reacting to signals without necessarily intentional human action.

I think we’re at the very early stages of that top layer of sort of human-computer interaction fundamentally changing. And I think that can now tackle a whole bunch of use cases in terms of improving the productivity of our personal lives, our professional lives, and go after, you know, fundamental productivity that I don’t think traditional software has gone after. And I think that’s the biggest kind of meta change that I think this all has the potential to go after.

Customer use cases

Pat Grady: Do you have a favorite example, either one—either a Mongo customer—obviously you love all of your customers, but do you have a favorite use case either that you’ve seen one of your customers build or a favorite use case that you yourself use?

Sahir Azam: Yeah, I would say generally we’re seeing more—and like most things, we see more sophisticated, advanced use cases tend to come up first in, you know, more risk tolerant, sort of faster-moving startups. But for that reason I’ll pick a couple enterprise use cases that have kind of captured our imagination. One is we worked with a large automaker in Europe and, you know, they have huge fleets of cars globally. They have a bunch of first and third party, you know, mechanics and maintenance sites where people, whether they’re dealers or other sites where people go to get help when their cars are having issues. And the common problem of I hear something funny with my car, like how do I go diagnose this? It means that you typically go in, a mechanic who has expertise has to go kind of tinker around, figure out what it is and then go through a manual to figure out what the remediation steps is, or what parts they have to order to fix it.

Pat Grady: Yeah.

Sahir Azam: We work with them to actually identify an audio embedding model that can allow them to record with a phone the corpus, and semantically match that with a corpus of sounds that are typical problems that are known problems with their cars or any cars, which shrinks down the actual diagnosis time by what typically could take hours if it was a tricky diagnosis, to something that could take now seconds. It’s almost like Shazam for car diagnostics.

Pat Grady: [laughs]

Sahir Azam: And then on the other side of it, instead of looking through PDFs or, you know, physical manuals on what the approved remediation steps are to fix it, now it’s sort of a natural language interface to say, “Okay, this is the issue that we match to. What should I do next in terms of fixing the problem?” And that’s all about unstructured data, semantic meaning of the information both in the problem with that car, and if you extrapolate the business case of that, though, across thousands of dealerships or hundreds of different models and iterations of cars, that’s millions of dollars of potential savings for them, and a better customer experience and consumer sentiment around their brand. And so that was kind of definitely one cool one.

Another one in a more very heavily-regulated industry. Worked with Novo Nordisk, you know, one of the largest pharmaceuticals. You know, obviously getting a drug approved is a highly-scrutinized process. And so there’s this idea of a clinical study report that pharmaceutical companies have to fill out, which typically takes a lot of manual effort to write and structure and review and, you know, kind of get approved. They were basically able to use a large language model, train that against all their approved drugs, all the process they do manually, and now they can get that initial draft of a CSR, as they call it, within a few minutes.

Pat Grady: Hmm.

Sahir Azam: And so it shrinks a lot of just the initial drafting cycles. The quality of that initial draft is higher than what they typically see if it was manually done. And so again, like, you can draw a pretty quick line towards true dollar ROI savings on use cases that are not necessarily even bleeding edge in some aspects of what we’re seeing in the sort of early stage ecosystem, but are being applied in a context of scale in industries that obviously have big implications for them and for their customers.

Pat Grady: Yep.

AI applications: good news or bad news for databases?

Sonya Huang: So now that the shape of these applications is changing and, you know, they’re multimodal, as you said, they’re agentic, they’re ambient agentic, what does that mean for the database layer? And if you wouldn’t mind just giving us the 101 today of, like, the role that databases play for software as we know it today, deterministic software. And what role do you see databases playing in this kind of new evolving market for AI applications?

Pat Grady: Is it good news or bad news?

Sahir Azam: We’re excited. So it’s one point I lightly brought up earlier, which is if there’s more software in the world, which I think generative AI will just make it easier to create more types of software experiences, I think that in general is a tailwind for any data persistence infrastructure technology. It doesn’t necessarily mean that MongoDB or any other particular vendor is automatically going to be the beneficiary. There’s a lot of execution that goes into making sure we’re technologically, and for our partnerships and ecosystems, well set up for that, which is where I spend a lot of my time. But in general, like, more software means more data and needs for persistence of that information. So that’s a very macro sort of, I think, tailwind that we’re definitely excited about.

I think the shift from relatively simplistic gen AI use cases, oftentimes where you’re just interacting via chat with an LLM, it doesn’t necessarily need very advanced kind of data persistence. But as enterprises need to ground the results of their AI applications to proprietary information or to control the result set so the retrieval is of high quality, now there needs to be a lot of interaction with these foundational models and their underlying information about how they run their business. And a lot of that is not necessarily publicly trainable information on the internet.

And so whether that’s advanced or simplistic RAG workflows, whether that’s fine tuning different approaches around post training there, I think there will be more need to interact with an enterprise’s data and foundational models over time, especially as these models become lower latency, and so they interact more with the real-time business data that’s being generated in an organization. And that’s really what we’re seeing in the most advanced companies right now is they’re building really sophisticated ways to control the output of these LLMs based on the use case that they’re trying to drive towards and merging it with the operational data that drives their application or their business.

And so I think we’re still early days in that, in terms of where I think that can go, but I really do fundamentally believe the databases will need to get much better at high-quality retrieval, in particular of unstructured data. Because, you know, when I look at all these embedding models and just what we can do with probabilistic software, it takes the value out of 70 percent of the world’s data, unstructured data, and makes it applicable to applications in a way that just really wasn’t possible before. And I think that’s the real opportunity.

Sonya Huang: What’s the devil’s advocate answer to that? So for example, I’m thinking of Jensen at our first AI Ascent. I think you were at that AI Ascent and he said something like, “Every pixel is gonna be generated, not rendered.” And I think of rendered as, you know, retrieved from a database somewhere. What is the devil’s advocate point of view to the—is it good or bad for databases as generative AI takes off?

Sahir Azam: Yeah, I think the devil’s advocate view to me is less about whether there is a database somewhere behind the scenes, more about where is that abstraction, and is that something that’s occurring a choice of the application developer building that application, or is it abstracted behind some higher level API? Or is that a choice that an LLM makes, in terms of, as it auto-generates software or auto-renders that environment, where does it choose to persist that data?

Sonya Huang: Yeah.

Sahir Azam: But at the end of the day, you know, we like to joke internally, an AI application is still an application. You still need to persist transactions safely to make sure people’s bank balances are accurate. You still need the ability to search information based on text keywords, not only on the semantic meaning. And so I view all these generative AI needs from the data layer as additive, not necessarily substitutive to the needs of a traditional application.

Sonya Huang: And, you know, one of the reasons people love Mongo today is the developer experience, right? If you fast forward the clock, and maybe there’s x-hundred-million human software developers, but there’s trillions of, call it, agentic developers. What makes a good agent developer experience? Like, why would an agent choose to use Mongo as its database, if that even makes—does that make sense as a question?

Sahir Azam: Yeah, I think it does. And it’s something—we think a lot about sort of how the nature of software development will change. And I think one of the things as we move from more simplistic generative AI kind of powered applications to more advanced ones with more agent-driven business logic, state will be more necessary, because now you’re coordinating a more complicated workflow where you need to be able to track the results of a particular piece of a transaction and coordinate that. And all of that requires storing that somewhere and manipulating and updating it over time.

So I think in general things are becoming more state-ful in generative AI applications over time, which is a drag of data and database consumption overall in terms of where things are going. Now I think in terms of the abstraction, I think the question is: If developer experience is the thing that makes any technology really accessible today for human developers, does that same value proposition hold for AI? And I think what we’re seeing, even if you look beyond just the database space, think of, you know, the adoption we’re seeing of some of these, call it AI platform-as-a-service type companies, you know, look at the adoption of things like Vercel v0, or you see things like Replit or whatnot, I think we’re seeing that, at least with early AI-generated software, there’s a preference for great developer experience à la higher levels of abstraction. So I think it’s too early to be definitive on that but, you know, I think we’re seeing some really promising signs.

Pat Grady: Speaking of higher levels of abstraction, I forget who had this one liner. Somebody had the good one liner which was, you know, English is the ultimate layer of abstraction, right? And at the limit you will just be able to describe in plain English, you know, what product requirements you have, and a foundation model will spit out the code required to, you know, build whatever application you want to build. First off, do you believe in that as a future state? And then secondly, is that great news for Mongo because there’s just going to be so much more software and most of it’s going to need a database sitting beneath it? Or is that bad news for Mongo because it neuters some of that development experience that is a good advantage for you? Do you see that playing out, and what does that mean for Mongo?

Sahir Azam: Yeah, I think for databases in general, I feel pretty confident it’s absolutely a tailwind. I think MongoDB specifically, one of the advantages we have is that our data model is really well attuned to managing structured data, semi-structured data, and now with embeddings, unstructured data. So I think we have some fundamental architectural advantages we believe are even more prevalent and important in AI as you’re representing all these forms of data, regardless of whether the software above it that’s interacting with it is human generated or machine generated, so to speak.

Now that being said, we’re certainly not resting on our laurels that that’s gonna happen without us being really intentional about it. So we are working with the whole ecosystem of AI frameworks and model providers to make sure that we are well integrated, whether it’s inference players or dev frameworks, et cetera, to make sure that just like JavaScript and Web 2.0 and Cloud were big tailwinds and are big drivers of our business, that the modern stacks that are being used to generate these applications, MongoDB is well integrated as a default in. So I think there’s a lot of work happening there.

We’re also focused on this idea of what is the equivalent of, you know, quality training or even SEO for LLMs? Meaning if you go scrape the internet to train a code assistant on any technology, is that necessarily what the best practices are? Probably not. But there’s no standard way for a vendor or a technology expert behind a particular area to submit the canonical training data for quality MongoDB code, for example. And so we’re working with some of the labs on methodologies around that. We’re doing things just even without involvement to test sort of what we can be doing to create data sets that allow for the quality of the outputs of these systems to be reliable. Last thing we want is somebody going and saying, “I want to use MongoDB. Help me generate some code for some functionality,” and it’s not high quality, performs poorly. And so there’s various facets of this that I think are very intentional efforts to make sure that our technology fits well as things evolve over the next few years.

Pat Grady: Yeah.

Sonya Huang: So actually to that point, I think there’s been a lot of chatter and increasing chatter that, you know, we’re hitting a wall in terms of just public data globally available.

Sahir Azam: Mm-hmm.

Sonya Huang: There’s a lot of data still left in private enterprise data. You guys sit in the middle of a lot of it. I’m curious how you think about your role in, kind of, that as the market evolves towards this next leg of finding that next trillion tokens’ worth of training data. Do you see yourselves, you know, being a training data provider for your customers? Do you see yourselves partnering with the labs? Are your customers mostly looking to use their data in Mongo for RAG, or are they looking at also training models on the data they have in your systems?

Sahir Azam: Yeah. Definitely, I think, just to be clear, any of the data that we manage on behalf of our customers is owned by our customers. So we’re certainly not taking that data and training any models that are outside of what that customer wants us to train or use for RAG. So I think that definitely is where more of our focus is. And we see a variety of differing things—very simplistic kind of use cases where people are just using core operational data stored in MongoDB or metadata as part of their RAG workflows. We’re seeing obviously a lot of vector adoption; it’s our fastest growing new product area as they try to merge metadata, transactional data and semantic search together into a single sort of system for more quality retrieval kind of use cases, which is sort of, I think, where the market’s going.

And then we see instances where people want to use the data they have in MongoDB and other systems to either fine tune or straight up train smaller models that are specific to a particular use case. And I don’t believe that there’ll be kind of one particular modality that suits every single use case. I think there’s going to be a plethora of different things that customers will begin to optimize for their latency requirements or performance requirements.

Are vector databases a new category?

Sonya Huang: So I think you have the most fascinating seat to what’s happening in the vector database market. We constantly poll our portfolio on what their AI stack is, and consistently Mongo has been the number one vendor that everyone uses for vector databases, so I think you have the deepest and most interesting perspective on this. Maybe, like, from the 20,000 foot view, it seems like people are using LLMs as—you know, they have world knowledge up to some pre-training cutoff date, but beyond that you need RAG and you need vector databases in order to supplement knowledge, to provide specific domain knowledge almost as in information retrieval knowledge source. But if I look at vector databases, they kind of came from the semantic search world and e-commerce and things like that. And so that’s a very different world. So how do you think about—what are people using vector databases for today? Is it a technology of the past that’s being improperly shoehorned into this information retrieval use case, or is it the ideal data structure to kind of be the knowledge infrastructure for LLMs? Like, how do you think this all plays out?

Pat Grady: Yeah, can I ask a quick question on that, too?

Sahir Azam: Of course.

Pat Grady: Did Mongo—I’m aware of Mongo’s vector database because of generative AI and seeing people use it for generative AI.

Sahir Azam: Sure.

Pat Grady: Did you guys have a vector database pre generative AI?

Sahir Azam: We started because of a more classic—classic—semantic search use case.

Pat Grady: Okay.

Sahir Azam: So a few years ago, one of the things we noticed were that many of our customers would use MongoDB as an operational data or any operational data, and side by side with it have an inverted index kind of search engine for full text kind of lexical search. And our customers are basically like, “Why do I have to copy data between these systems to run two different databases just to get the search results I want to empower my application with?” And so being focused on developer experience and simplicity we’re like, this seems like an obvious problem for us to go after.

And so we started there with our search product to really just simplify it so a developer interfaces with one database, but really it has different modalities of indexing and storage that can serve OLTP-type queries as well as full text search queries. Some of our e-commerce, advanced e-commerce customers were the ones then saying, “Okay, that’s great. But I want to start to do semantic similarity search and blend full text lexical search alongside similarity search, because that’s what’s going to give me higher quality search results.” And that’s where we started getting pulled into building the vector capabilities into our engine.

And for us, one of the things we’re always trying to do is remove the need for customers to have multiple systems. So when we say we added this capability, a lot of it goes to how do we integrate it in an elegant way to our data model, how do we extend our query language so it’s very easy for a developer to just feel like it’s not a separate system, they’re just interacting with it as part of their application development.

And so we were down that line, and then obviously the world explodes post ChatGPT. And we were like, “All right, this is going to be even more relevant than we thought.” And so we poured the gas on things, accelerated things, expanded the strategy to be well-integrated into a whole bunch of new frameworks, working a lot more closely with the AI labs, because it is, to Sonya your point, it’s certainly a different use case to leverage vector embeddings or even just metadata or transactional data to integrate to RAG than just a pure semantic search use case.

But as we look at our most advanced customers now in 2025, they’re actually seeing that the integration of all those modalities is really important because you need to filter based on metadata you know about your unstructured data, whatever it is you’re building an application around. There are times when you need to sort by keywords and relevance ranking like a more traditional search engine, and then you need to understand and extract semantic meaning from vector embeddings. And there’s a whole bunch of things around how to improve the quality of that. And only then can their overall application get the percentage quality predictability—especially for large enterprise—to trust putting something in front of their customers, especially in a regulated industry.

And so that’s turned out to be a real advantage to have all of those in a single system, because otherwise it requires a whole bunch of what I call kind of RAG gymnastics to try to tie all these things together, which is possible, but it puts a whole huge burden around the development cycle, what happens in app code. And frankly, you need to be a pretty sophisticated team to figure that out on your own. And so we’re trying to democratize that all by making it just much simpler for the average application developer.

Pat Grady: How do you think about vector versus graph? Are they substitutes? Are they complements? What are the trade offs? Because we see vector-based RAG. We also see graph RAG.

Sahir Azam: Yeah. Yeah, every week goes by and there’s some new sort of approach to higher quality retrieval is kind of what I think everyone’s sort of trying to chase. I think they’re complementary. You know, there are reasons why you want graph relationships because that’s an augmentation of understanding that you may not be able to just infer by the vector embeddings themselves. So we view that as additive, just like pre-filtering based on some sort of metadata you know about your unstructured data and embeddings is additive and improves the quality of results. And so I do view these modalities as very complementary.

Our goal is to just make it simple to combine all of those for a developer so they don’t need to have their graph representations of their objects in one style of database, their metadata in another database, their transactional data in a relational database, and then have to have a separate vector search database and try to rationalize all that, which is kind of what happens. We’re trying to just make that dead simple.

Sonya Huang: Is it fair to simply think about in an agentic system, the LLM as the brain, and the database, whether it’s a vector database or superset of those as the memory? Is it brain and memory? Is that the right abstraction, the right mental model?

More state to persist

Sahir Azam: I think that’s definitely one way to think about it, because absolutely you need to persist memory and state, especially when you have agents that are having more complex workflows and need to drive interaction across multiple endpoints, not necessarily a single foundational LLM with a one-shot call. So you need to persist more of that state. I view them as sort of two pieces of an emerging architecture. You know, you’ve got obviously compute, storage and networking as sort of the underlying primitives, but now there’s this whole set of use cases that foundational LLMs can go after that are more probabilistic in nature, that can automate tasks that knowledge workers would typically have to do manually, which is super powerful. But then that needs to store its state and be grounded and interact with the transaction that the application is driving, and the other information that’s either semi-structured or structured.

And those things together come to create a great application experience and end user experience. It’s not an either/or. I think it’s complementary in a really powerful way, which will only become more important as LLMs become lower latency and faster. Where now you can really use what’s happening in a real world setting to augment the results of an LLM, and much closer to real time than today where it’s just a very different interaction speed.

Sonya Huang: So you’re saying the database is not only the memory for the LLM, but it’s a reflection of world state.

Sahir Azam: Yeah.

Sonya Huang: Like, LLM needs to interact with world state.

Sahir Aazam: Exactly.

Pat Grady: Well, I think that rough framing is consistent with what we’ve talked about internally, which if you think about the bottom as raw infrastructure, compute, network and storage, you think about the top as the application, you’ve got all this stuff in the middle, and for anything that is deterministic, you’re going to be better off with vector database, graph database, relational database, NoSQL database, kind of the traditional database world. For anything that’s more probabilistic, you want something that looks like an LLM. The functionality that gives you is a little bit of human-computer interaction and a little bit of reasoning, which is complementary to what you get from this part of the world.

But I want to take it one step further because it sounds like we’re pretty similar view on this default architecture of the future or kind of this emerging pattern. If you take it one step further, does that imply that the mental model investors should have for the API portion of Anthropic or OpenAI or the other foundation model companies is Mongo? Meaning they’re occupying a similar layer in the stack, they both reside on top of the public clouds, they both reside beneath the application layer. Is Mongo a good frame of reference for what the API businesses of OpenAI and Anthropic would or should or could become over time?

Sahir Azam: Yeah, I think it’s an interesting proxy because you sometimes read, like, okay, the LLM is the new operating system. That never felt logical to me in terms of how application capability and functionality should look. Maybe I’m wrong, things are changing so fast these days. But what we see is really these are side-by-side complementary components that drive and serve the business logic and interaction layer of the application above.

Pat Grady: Yeah.

Sahir Azam: And there’s a whole bunch of use cases obviously that large language models can now reason about and provide human interaction around that weren’t possible before. That’s the amazing, powerful aspect of them. But it doesn’t, you know, in any architecture we’ve seen, supplant the need to have deterministic outputs from structured data to manage transactions and search and all the other data components. It’s really complementary. And I think it’s still early days. I think Sequoia has done a great job sort of writing about as well. We don’t know what the real next generation business models and applications are yet today. I think we’re still seeing the early years of it, and that’s what’s fun, to be able to see all these different early stage companies or these enterprise use cases that I highlighted earlier. Even then, I think there’s a lot more to come.

Pat Grady: Yeah, all hypotheses at the moment.

Sahir Azam: Yes.

Sonya Huang: I mean, speaking of hypotheses, there’s all these hypotheses about, you know, what model architectures are going to leapfrog, and what the next model architectures are going to be. I’m curious your hypotheses on the database side. So we went from nothing to vector databases pretty quickly, it seems like. Do you think we’re going to leapfrog to a new type of data structure for AI, for these AI systems, or do you think this is kind of the ideal architecture?

Sahir Azam: Yeah, I think the fundamental data architecture, at least as far as vectors are concerned, seem to be strong primitives that seem to hold, and where I think we’re still trying to figure out how we extract all the possibility there. Now if something else comes along, certainly open minded to it, but I think it is a primitive in my mind. You know, I think there was a question in the market at some point of, like, all right, is a vector database a whole new segment in the market, or is that going to replace core databases? We view it as a primitive. Like, if you want to manage unstructured data, the combination of the ability to index and vector embeddings combined with high quality embedding models that can represent the meaning of the unstructured data is sort of a new primitive, just like text indexes or B-tree indexes and databases, et cetera.

So we view it as a foundational element. I don’t see that going away. I think how you create high quality results from that data and how you have high quality vector embeddings or how you augment that with other information, there’s a whole lot of evolution happening there right now. And I don’t think that’s by any means settled.

Sonya Huang: I see. So the data structure, the data storage, that’s vectors and the way you store them seems pretty sound. And the thing that’s yet to be optimized is how do you go from all these vectors to ultimately meaning and …

Sahir Azam: Yeah, and I’m not saying there aren’t going to be optimizations or room for innovation and how that can be more efficient, more performant, more cost effective. There’s plenty always in the database space happening there. So I’m not trying to make a statement that there’s certainly innovation going on there. But I think the more interesting thing is when you’re in a world of probabilistic software—and I heard a really interesting take on this from Ben Thompson who writes for Stratechery, where he kind of said in a world of probabilistic software, the measure of quality is about that kind of last mile. How do you get to 99.99X sort of quality? And so will the domain of sort of quality engineering that we typically associate with manufacturing kind of apply to software? And that really got me think in terms of you’re not going to be able to necessarily get a deterministic result like you would with a traditional application talking to a traditional database. So therefore, the quality of your embedding models, how you construct your RAG architectures, merge it with the real time view of what’s happening in the transactions in your business, that’s what’s going to get you that high quality retrieval and result. And unless it’s high quality in a world where it’s probabilistic, I don’t see it going after mission critical use cases in a conservative enterprise. And that is a problem space we’re very focused on right now.

Sonya Huang: How do you think all the innovation in the reasoning model side interplays with what’s happening in your corner of the world?

Sahir Azam: Yeah, I think in terms of whenever there’s reasoning, memory comes into place, long running logic. I think then how reasoning plays into more advanced agentic workflows, all of that needs state as I kind of mentioned earlier. So at a very loose level I think databases are going to be more important to that than just a one-shot simple answer engine from an LLM. So I think that’s the kind of meta trend. As an end user I’m fascinated by these types of reasoning models. I mean, I am definitely a—I know this is very not exactly novel in the last couple weeks, but Google’s Gemini Deep Research and the product experience around that I think is amazing. So I think there’s a lot that can be done there in terms of the user experiences and the types of use cases that applications can build off of that at least the first wave of LLMs that we saw haven’t been able to really drive in terms of adoption.

MongoDB’s business transformation

Pat Grady: Very different direction. So one of the things about your background that people who are listening might not be aware of is that you sort of like architected and led the transformation of MongoDB from being a traditional on prem enterprise software business to being a cloud native consumption-based business, which is now most of MongoDB. And I think any transformation of that magnitude is really hard to pull off, and you guys did it at reasonable scale. And of course now the company has, you know, billions of revenue scale. The reason I’m harping on this a little bit is I think there are probably a lot of enterprises or even a lot of startups who are currently faced with a similar challenge where they need to undergo a transformation of their business. And yours was an on prem to cloud transformation, which not a lot of companies got right. The one we’re looking at now is sort of a non-AI to AI transformation. And so the question is: What made that work for Mongo? Maybe just say a little bit about the nature of the transformation. What made that work for you guys? And do you have any advice for people who are looking at an AI transformation of some sort now?

Sahir Azam: Yeah, I appreciate you bringing that up, and certainly we’re very lucky and fortunate that we were able to make this pretty monumental shift in terms of the business model, the product strategy of the company. And certainly, by all means it required a lot of different people doing a lot of different things to make that happen. But I think one important piece I want to key off is you’re using the word kind of “business transformation.”

Pat Grady: Yeah.

Sahir Azam: That is really important because I think for a lot of companies that have tried to drive this type of a transition, they just view it as “Okay, this is a new SKU, a new product. That’s all I have to worry about.” But I think certainly I took it as a sort of business transformation as the goal here, and therefore we made sure that every functional leader in the organization one, understood that they had a really important part of that transformation and were also accountable for working to think about in a consumption-based cloud-first model, how customer success changes, how our financial model changes, how you can name any single function.

Pat Grady: How did you guys get buy-in in the early days when the thing that generates all the revenue was not this? Like, how did you get people to care?

Sahir Azam: Yeah, absolutely. So one, definitely having strong top-down support. You know, like, it was very clear to the company that launching Atlas, making this transition was a super critical business priority. You know, there’s nothing that gets around the fact that you need that level of top-down consistency. You know, that included empowering me as sort of the person to help drive that. And so when I went knocking on one of my peer’s doors in a particular function, I said, “Hey, I really think we need to fund some headcount here to think about the cloud side of the business,” that I had the sort of ability to kind of drive that level of influence.

But I think what’s important about that is we didn’t treat it as this sort of separate mini BU that’s isolated from the core business. We wanted every functional leader to feel like they were part of that transition and it wasn’t some competing thing for—you know, and they were going to lose some sort of part of the function they ran. So I think that was a really important thing. Certainly it meant a lot more shuttle diplomacy for me versus direct authority, but that was critical to bring the whole company along for that transition as opposed to it just being a starved new business initiative in a corner, which you see sometimes start to happen.

Certainly in terms of the sales organization, the revenue functions in particular, it took a lot of one, just really rolling up sleeves and being a seller, meaning being in the early deals, learning what objections are coming up, whether that’s a product objection we had to go build on the roadmap, or whether it was just an enablement issue or a positioning or messaging exercise or pricing thing. So really taking a mindset of like, you know, our team, the product team launching this is going to be side by side with the sellers and the SAs in every single one of the first deals. And I remember in our smaller New York office at the time, I used to make the rounds every evening and be like, “All right, what’s happening with this deal? What help do you need? Where are we on this? What are you hearing?” And that got a lot of sort of one, all right, the sales team isn’t just being asked by some stranger to do something because it’s important. I was trying to show that I’m in it with them.

And then certainly you have to drive incentives around it. When something’s working and people know how to drive revenue a certain way in any function, there’s going to be so much inertia around that already because the software business is still a growth business for us. So we had to be very intentional about putting SPIFFs, heavy emphasis on enablement, inspection and accountability to make sure enough momentum got built in the new business until we could kind of neutralize it. Because ultimately we’re about customer choice. We don’t want to artificially push a customer that’s on prem to the cloud if they’re not ready. That’s largely out of our control. But in the beginning, we needed the sales team to get a lot of attention on something that they felt was not necessarily the needle mover until we got a certain level of momentum.

Pat Grady: Yeah. Yeah, interesting. The lessons I heard for anybody going through an AI transformation is a lot of top down support, which I imagine requires a lot of conviction that this is where the future is going. Fully integrated, not some projects sitting off in a corner, getting starved for resources, but actually part of the core business. And holistic transformation. It’s not a SKU, it’s a wholesale reinvention of the business in a lot of ways.

Sahir Azam: Right. And some of the most important things were not technology decisions. It was, you know, business model transition. It’s sales enablement to sell to a different segment of the buyer in the organization, different buyer within the organization than we were traditionally. So almost every function had to change in pretty fundamental ways. And I think sometimes an outsized amount of our time went to those things that you wouldn’t think or needed to change that much or that would be easier, versus what you assume to be the hard part, which is how do you deliver a highly reliable cloud database? That’s by no means easy, but that’s the part I think everyone gravitates to. But it’s all these other things around the different functions that drive the business and making sure all those line up in a coherent way that a lot of attention went to.

Sonya Huang: I also think one of the analogies to draw—and tell me if this is just I’m off in la la land, but in our conversations, you were really focused on driving the developer experience through that period of transition, and the developer was going to choose the database for this kind of new mode of operating. It feels like to me, for companies going through the AI transition right now, right now it still is developer developer developer. To your point, developers are choosing AI tools. Eventually, if we have trillions of agents running around, it might be the agent’s experience that’s the thing to really prioritize.

Sahir Azam: Yeah. Especially if agents are the ones who are going to be driving a lot of the business logic without necessarily custom development happening by the organization. I could see that. I think oftentimes from the outside I get the question of how did Mongo go from enterprise to PLG? And I always sort of like, wince at that. You know, I think to me those things are absolutely complementary, and more have to do with where a customer is in their adoption journey or what style of organization they are, whether they’re a technical founder-led, fast-moving startup that doesn’t want to necessarily engage with sales in the beginning of their journey, or whether it’s a large enterprise that’s never going to show up via a self-service type channel. And so we spent a lot of time thinking about the whole system holistically, and trying to map that to how the users and the buyers actually want to engage with us as a company. And so I think a lot of that is what has been behind the cloud transition sort of success. It’s not trying to be too philosophical of saying, “Credit card business customers are the right ones, and enterprise sales? No way.” I mean, it’s neither. Both of them have to be cohesively integrated to reach the global scale of customers that we have at this stage.

Lightning round

Sonya Huang: Should we wrap with some AI rapid-fire questions?

Sahir Azam: All right. Sounds good.

Sonya Huang: Okay. First one: Favorite new AI app.

Sahir Azam: All right, I mentioned that I’m definitely a Gemini Deep Research fan, so that I mentioned. I think that and also Perplexity for me—they’re not new by any definition—in my mind run counter to the okay, thin AI wrappers aren’t really sustainable, because I see a lot of product craft. And I know Gemini obviously has a deep model training behind it, but just the product craft is what I think is really interesting. Like, the way Perplexity makes the user experience, the design sense, for example, is really great as an end user. So I don’t think it’s so simple that AI models are suddenly going to make software go away. I think there’s a lot around adoption and understanding your user, having great design sense. And there’ll be a version of that as we go to other interactive modalities as well, even if it isn’t visual. So I think that’s kind of one thing.

In terms of what’s new to me? I don’t know how new this product is, but somebody last week turned me on to Snipd. S-N-I-P-D. I’m a big podcast listener, and it’s a great example of an application that I think has woven AI really well through the user experience. So it, like, subscribes to all your podcasts. It, like, auto summarizes, it allows—it surfaces up some of the key insights in readable form or in a shortened version. It allows you to take, kind of, notes.

Sonya Huang: We need this. We’ve been looking for this.

Sahir Azam: It’s super cool. Yeah, I just found out about it last week, and I am loving learning how to use it well.

Pat Grady: Love it. Who do you admire most in the world of AI?

Sahir Azam: That’s a tough one. I mean, certainly I think some of the just researchers that see the future and probably have a sense of where things are really going. Every time I listen to them on this podcast or read some of their writing, I feel, like, really excited about the future. And, you know, the typical names there. So I think that cohort of people is always inspirational to me. You know, I think it’s fun to listen to the large company CEOs kind of mudsling a little bit about whether their applications are just systems of record, or who’s going to win the agent race and all of that. So I think it’s interesting to see the battle of titans happening in terms of who are going to really be the incumbents that can survive and thrive versus the ones that may not make the transition. So without naming names, I’d say those are the two most interesting cohorts of leaders that I tend to listen to.

Pat Grady: Fair enough.

Sonya Huang: Okay, agree or disagree? Every developer will become an AI engineer.

Sahir Azam: Agree. You know, I think that traditional machine learning was typically specialized in a centralized ML or data science team, and applied to probably a subset of the use cases that could potentially add value to. What we’re seeing though with generative AI being integrated into applications, whether it’s greenfield or to an existing application, is it’s the average full stack or application developers that are the ones that are responsible for that. So really democratizing that capability across the organization is something we’re trying to do. And so if I had to give a simple answer, I would agree with it.

Sonya Huang: Wonderful. Sahir, thank you so much for joining us today. I think you have…

Sahir Azam: This is super fun.

Sonya Huang: You have really profound theses on how AI is going to change not just databases, but software and technology and the way we interact with technology as a whole, and how that ripples over to the database market. So thank you for taking the time to share your thoughts.

Sahir Azam: Absolutely. Thank you. And happy to be here. And, you know, we’ll see if any of these thoughts actually hold water. Things are moving so fast. 

Pat Grady: Awesome. Thank you.