Vector Databases and the Data Structure of AI ft. MongoDB’s 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 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 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.

Today we're 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 he's now helping to steer Mongo's evolution in AI first world. Mongo's journey into vector databases began with semantic search for E commerce, but it's evolved into something a lot more fundamental, becoming the memory and the state layer for AI applications. We're excited to get Saher's take on the past and the future of vector databases and what shape infrastructure itself will take in a brave new world of AI agents and applications and unlimited software creation. Sahir, welcome to the show. We're so excited to have you here.

Thanks Sonia. I'm super excited to be here.

We're going to 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 going to change the database market?

That's an interesting question. I think the related and probably more interesting question is whether it's going to change software development in applications. And I think that it really is. I think we're seeing generative AI powered applications address a set of use cases that traditional deterministic software hasn't been able to go after. And I know I read some stuff from Sequoia around the idea of server 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.

Can we poke on that for just a minute? So I'm curious, since you guys are operating on 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?

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 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 pie. 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, 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 ambient agents and reacting to signals without necessarily intentional human action. I think we're at the 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 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.

Do you have a favorite example either one that 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?

Yeah, I would say generally we're seeing more in, 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, is we worked with a large automaker in Europe and they have huge fleets of cars globally. They have a bunch of first and third party 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? Diagnosis means that you typically go in 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. Yeah, we work with them to actually identify an audio embedding model that can allow them to record with a phone the corpus of, and semantically match that with a corpus of sounds that are typical problems, that are known problems with, you know, their, their, their cars or any cars, which shrinks down the actual diagnosis time, you know, 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. And then on the other side of it, instead of looking through PDF, 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 you know, 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, like that's millions of dollars of potential savings for them and a better customer experience, know consumer sentiment around their brand. And so that was kind of definitely one cool one. Another one, you know, 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. And 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 clear CSR, as they call it, within a few minutes. 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, you can draw a pretty quick line towards true $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.

Yep.

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 database is playing in this kind of new evolving market for AI applications?

Is it good news or bad news?

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, 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 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 host 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 when I look at all these embedding models and just what we can do with probabilistic software, it takes the value out of 70% 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.

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 going to be generated, not rendered. And I think of rendered as 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?

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 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? 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.

And 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? Why would an agent choose to use Mongo as its database? Does that make sense as a question?

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 stateful 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, 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 a 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.

Speaking of higher levels of abstraction.

I.

Forget who had this one liner. Somebody had the good one liner, which was English is the ultimate layer of abstraction.

Right.

And at the limit you will just be able to describe in plain English what product requirements you have. And a foundation model will spit out the code required to 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?

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 of an 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 going to 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 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. Yeah.

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. 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 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?

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 different things, very simplistic 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 areas. They try to merge metadata, transactional data and semantic search together into a single 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.

So I think you have the most fascinating seat to what's happening in the vector database market. We constantly pull 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, from the 20,000 foot view it seems like people of you 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 knowled, 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?

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

Of course.

Did Mongo. I'm aware of Mongo's vector database because of generative AI and seeing people use it for generative AI?

Sure.

Did you guys have a vector database pre generative AI?

We started because of a more classic now semantic search use case. So a few years ago one of the things we noticed were that you know, 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 it's, you know, 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 sonia your point, it's certainly a different use case to leverage vector embeddings or even just metadata or transactional data 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.

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 rack.

Yeah, yeah. Every week goes by and there's some new sort of approach to higher quality retrieval is kind of what I think think everyone's sort of trying to chase. I think they're complementary. 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.

Is it fair to simplicity? 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, brain and memory. Is that the right abstraction, the right mental model?

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've got obviously compute, storage, 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.

So you're saying the database is not only the memory for the LLM, but it's a reflection of world state. LLM needs to interact with world state.

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. If 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 is Mongo a good frame of reference for what the API businesses of OpenAI and anthropic would or should or could become over time?

Yeah, I think it's an interesting proxy because it's, you know, 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, you know, are changing so fast these days, but, 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. 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 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.

Yeah, all hypotheses at the moment.

Yes.

I mean, speaking of hypotheses, there's all these hypotheses about 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?

Yeah, I think the, the fundamental data architecture, at least as far as vectors are concerned, seem to be strong primitives that seem to hold. And 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. 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 new, 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 in Databases, et cetera. So we view it as a foundational element. I don't see that going away. I think the 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.

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.

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 Tratecheri, 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 quality? And so will the domain 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 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.

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

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 database rules are going to be more important to that than just a one shot simple answer engine answer 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 of 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, 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?

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 business transformation. 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.

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?

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, you know, business priority. You know, there's nothing that, 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 that. And so when I went knocking on one of my peers 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, all right, I'm, 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'm going to 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 Spiff's 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.

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 project sitting off in a corner getting starved for resources, but actually part of the core business and holistic transformation. It's not a skew, it's a wholesale reinvention of the business in a lot of ways.

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 that we were traditionally. So almost every function had to change in pretty fundamental ways. And I think sometimes outsized amount of our time went to those things that you wouldn't think were 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.

I also think one of the analogies to draw and tell me if this is just I'm off in la la land. But you were, 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 experience that's the thing to really prioritize.

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 wince at that. 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, you know, 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, it's neither. Both of them have to be cohesively integrated to reach the global scale of customers that we have at this stage.

Should we wrap with some AI rapid fire questions?

All right, sounds good.

Okay, first one, favorite new AI app.

All right, I mentioned that I'm definitely a Gemini Deep Research fan, so that I mentioned 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. The way perplexity makes the user experience, the design sense, for example, is really great as an end user. So I don't think, I 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 Snipt. I'm a snipd. I'm a big podcast listener and it's a great example of an application that I think is woven AI really well through the user experience. So it like subscribed 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 allows you to take kind of notes.

Super cool.

We've been looking for this. Super cool. Okay, yeah, I just found out about it last week and I am loving learning how to use it.

Well, it who do you admire most in the world of AI?

That's a tough one. I mean certainly I think some of the just researchers that see the future and are 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 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 to listen to.

Fair enough.

Okay. Agree or disagree. Every developer will become an AI engineer.

Agree. 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.

Wonderful. Sahir, thank you so much for joining us today. I think you have.

This was super fun.

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.

Absolutely. Thank you. And have you. Happy to be here. And, you know, we'll see if any of these thoughts actually hold water. Things are moving so fast. Awesome. Thank you, Sam.