 Welcome back everyone. LiveCube covers New York City from MongoDB.local. This is the inaugural kickoff of a multi-city tour going local, going out to the streets. That's where the fashion gets built. That's where the developers are. And it's the bottoms up movement for developer first platforms in MongoDB announced today. I'm here with the CTO Mark Porter with MongoDB. Great to have you on. Thanks for coming on theCUBE. It is awesome to be here. Thank you so much. It's an exciting time for us. So now we're going to talk tech under the hood. CTO Chief Technology Officer. MongoDB has been so successful. Congratulations. We love the tech. Databases that have the power applications. It's operational. We all get that. What's different about Mongo right now from a tech standpoint? It's not just the document database. There's a lot more to it. So I mean, I'll just start with the basics. So SQL databases and relational databases, which were what I did the first 35 years of my career are great. They're great for single node applications. They're great for things where you don't care that much about true high availability and for doing OLTP structured data. But when MongoDB came along, we developed a modern distributed system that is a database. And so that's one of the main things that's different is it's a distributed system. The second thing that's different is the document model. And in particular with all the rage going on with AI right now, it's so important that people can have flexible data structures. And the document model is the core of that flexible data structure, which is needed for AI. And you know the surge of the whole democratization of development happened over the past 20 years. We saw it. And then Mongo just kept getting better and better. Atlas came out with a couple of gears to build. That's now got a nice trajectory on revenue standpoint. It's expanding its base as a platform. Now you've got AI, which is a language model. You have structured query language and no SQL language. You got LLMs, large language models. The AI piece is super important. The document piece fits well there, but now you have other things in the platform. How are you guys tying that together? Because as developers want to go the next level of data and how it's stored, but also how they run in their apps, AI is now an important part of that. So I do want to be clear. I mean, AI isn't the only thing. It is currently the thing that's really exciting and being able to build great apps that do great things with your core data is always going to be important. But what's happening is people are enhancing their apps with AI. So if you think about having a document data model and that document data model is distributed across a large MongoDB estate, what developers can now do with the vector search technology released today, a lot of the relational migrator stuff we released today, they can actually build apps that incorporate AI directly into their apps. And while MongoDB isn't necessarily the AI company where we're producing LLMs, hundreds of companies use MongoDB as the foundation of their AI apps. And that's because it's distributed, it's scalable, it's flexible, it's easy to work against. We're really excited about everything going on. I want to get into the distributed database piece of it and the distributed platform piece of it, if you don't mind. But first I want to just ask this. I hear things like time series streaming announced today, you got search in the platform, there's other solutions out there, but it's this cloud native trend where you're starting to see native things in the platform. So it's more than cloud native because it's being native behind a single API, behind a single thing you connect to. So one of the beauties of MongoDB is that the data that is stored in the database is exactly the database that your app sees is exactly the data that the human can read on the screen. And that's different from all other data systems to date. So there's this cognitive dissonance that occurs when you're programming against other systems that doesn't occur, okay? So when you think about people building these AI systems and this weird data that comes in with different shapes than it used to, because a lot of the data coming in from these streaming systems is unstructured data, it just naturally fits into our system. And so we're seeing customers who are just like, well, of course I'd use MongoDB. And I don't mean to toot our own horn here, but the fundamental thing I'd like to walk away from today is if in 2006 when we had founded MongoDB, if we had known about AI, we would have built the system we have today. It's as if we built for the needs of AI. We didn't of course know about AI in 2006. Well, I mean, you guys were data centric because you have to store stuff. So I mean, it's interesting, if you look at the whose position is best for AI, and by the way, great point. You guys were already data enabled. That data now feeds into what AI now values, which is scaling up data. Okay, so quick question for you then. What's some of the use cases in your mind real quick as these data pools are sitting around or tons of data is sitting around, there's like a new level of insight coming. You have analytical, oh yeah, I got a dashboard for this and we got some operational data, got some analytical data, you know, you bring it together. Phase one insight was, oh yeah, things are happening, KPIs. Now you have AI making insights and application feature, not just some. So true, so amazing. So what's going on? If you think about legacy systems where you have like 15, 20 tables and a human has to tell the training model how things relate. Like let's say you have a billion rows and 75,000 of them have one field. The human would have had to tell the system that field matters. Because of MongoDB's document model and the fact it's all stored together, the AI model without even realizing it will go and realize those 75,000 records are special. So when you do some recommendation or some fraud detection or some other thing, the model works better on top of documents. And it's something we didn't expect. I mean, I'm just going to be honest, it came along, we started training models and we started going, wow, this model has better recall and better inference than we expected. You know, you better be lucky than good but all the inside people, luck is where preparation meets opportunity. That's exactly right. I use both phrases depending on the situation. You guys definitely earn the luck and I think that's key. If you look at that point about the AI, I have to ask you the next level, which is Amazon's got this expression, I always quote on the cube, we abstract away all the undifferentiated heavy lifting. Okay, I get that cost, mock and toil, whatever. That's cloud scale. With data, there's differentiation in the data. And the apps are extracting that in real time so it requires a new kind of programming thinking. It's a software at the end of the day. Data is code. If you think about that, you say, okay, if it's scaling, it's scaling the differentiation value. So we are predicting on the cube and Silicon Angle and we're reporting it that new value propositions will emerge from AI that we've never seen before and they're going to happen faster. So as a customer of MongoDB because they're positioned for having all the things enabled and in play, they're going to experience value faster, new value. So the question we're always trying to squint through is what new value is going to emerge from the platform that's sitting there and I'm the coder away, the developer will make the end. So there's a couple things there. First off, like I said, it's got to be easy to program against. It's got to all be in one system. There's all these diagrams which you've seen on our website and seen from us where we talk about people who wire up 2030 systems. We believe that time series and AI and IoT data and text data should all be in one system. That makes it easier. The second thing you talk about is value and one of those interesting things to me is once those things are all in one system and once that system can scale, your biggest success, the day your app gets featured on the App Store or the day you go big is not your biggest day of failure. When you need to scale up and you can't scale up anymore. With MongoDB, you can scale out. We have customers running a thousand nodes with three petabytes of transaction consistent data. You can't do that with legacy systems. So when you talk about getting the value from those systems, one of the things that's most interesting to me is people get these deluges of data and transactions they didn't expect and your underlying architecture had better be able to scale quickly or your best day turns into your worst day. I think that brings back to your point about humans. The humans plus AI is better than AI. So AI by itself is cool but humans plus AI is a critical aspect. That's where the AI augments the humans and that's where an area that's coming in. What's your reaction to that? What do you see when you hear that phrase what's the humans role in that new AI plus humans plus AI? Is it to tune? Is it to prompt? Is it to architect? How would you look at that? I know I threw that out there. I may be in the minority here, the less hyped minority. I believe that after the hype dies down we're going to end up with models that are finely tuned and that have really deep insights. We're going to learn how to tune these models even better with fewer parameters. Okay, and with really fast response times that are accurate with less elucination, et cetera, et cetera, all the vector stuff you know about. And what that's going to do is it's going to make AI into this tool that is just one of the tools in a programmers, developers toolkit. And they're just going to use it. They're going to say, I need recommendations from this dataset. I need this. And it's just going to be another tool. I mean, yeah, I think that for things like chat bots it's transformative, don't get me wrong. But for writing core features of mission critical systems it's just going to be one of the many tools that you have in your toolbox. Yeah, you guys are taking a very strong approach with this developer led approach. And I was talking to Andrew who runs product on your team and he and I were riffing and he's like, yeah, it's like New York fashion starts on the streets. Okay, and then it's not a top down. We're using this database or the developers right now are becoming a de facto standards body. Okay, they're the ones who are dealing with the data and the infrastructure and the application. And if you look at open source as any kind of canary in the coal mine they're making decisions on who wins and loses. Absolutely. Based upon who's got the better stuff and what scale. So you got horizontal scale, but also vertical applications, domain specific linguistics or data. What are the stacks going to be? How are the stacks going to work? Which are the easiest stacks to use? So my peers to hear as our CPO pounds into us this phrase elegantly integrated. And we use that term internally with the belief that if we provide something that's elegantly integrated our developers will be happy. But there's something we haven't talked about today which I really want to touch on which is what's going on in engineering teams is changing. It used to be you'd have these C++ developers or Java developers. Now you need to have data scientists. Now you need to have ML ops people because the idea of building your models the idea of training your models the idea of running your models in production with zero downtime because now doing inference is just as mission critical as making sure your storage system is available. Mark I'm glad you brought that up for the folks watching. Mark's had a career in ML ops, AI, running teams, data, databases, you name it, he's been there, done that. This is huge. There is a, I won't say generational baton passing but more of a incremental step up of a next level. You're starting to see those basic concepts of ML ops that were pioneered by people with arrows on their back or scar tissue but now it's becoming more abstracted away with tooling and AI. What's the philosophy for someone out there leading a team? Someone who wants to build a new startup or application. What's the mindset? How should they be thinking about how to organize methodology? I mean, is it iterate fast moving? I mean, talk to the current CTO, one of your customers and he's like, we've tried stuff all the time. We stop, we pull back, we stop, we pull back and when it hits, they double down on it. It's funny I was on this startup meeting this morning with a bunch of startups and we talked about the key decision that CEOs and leaders need to make is when do I make my platform better and when do I just keep iterating? And it's different for everyone, right? Because you might take a step back and make your platform a lot better but maybe you're not going to iterate on features for a month or two while you do that or you might just be in a point where you need to iterate quickly. And I think it's a decision that every CTO needs to think about every day. So for a small startup, you should probably rely on some platforms. For a large company like us, we build a lot of the stuff we do internally because we need it to be tuned exactly for what we do. Atlas, our managed service, is three million nodes. There aren't any platforms I can buy to manage that. We build our own. But if someone was starting out small, I'd focus on how do I get to my customers and get feedback from my customers in this intensely quick loop? That's the part that needs to be quick. And that's the part where I think a lot of, frankly, I'm an engineer. A lot of engineers think we know better and a lot of us engineers become CTOs and then we become CEOs and we still think we know better. If I was to say one thing to every startup leader, which I said this morning, listen to your customers relentlessly. And I think that whole fashion comment was interesting because that's the listening, you got to watch the herd. What's going on with your developers? What are they building? What are they thinking about enabling that experimentation? Seek to disconfirm your beliefs. Yeah, I love that. All right, now let's get into the distributed aspect. I wanted to come back to this because one of my rants on my podcast almost every week is cloud native, public cloud and on-premise and edge. It's just distributed computing if you're running cloud native. So your database is actually perfectly poised for that concept of public cloud, on-premise edge from an app standpoint. And I know it's got a lot going on with networking and data right now. What's your view on how Mongo fits into that right now? Because right now the two hot areas are networking and data. In respect to on-premise cloud operations and now edge emerging. So look, it's a complicated time in the industry in this area. So we run on the three major public clouds. We run on 14 other clouds through OEM agreements. A lot of people don't know that. There's 17 clouds that run MongoDB as a managed service, okay? People also run it internally and what we found is our biggest customers take our on-premise thing and they run it as a managed service within their own company. So that's really interesting how people are using our products. What's happening is as soon as they get past that managed services burden, they can get back to focusing on the data. So when you think about this distributed systems, distributed systems means you can scale at low commodity. Distributed systems means that you have high availability. So let me talk about that for a second. All the databases that I worked with the vast majority of my career, when something goes wrong, they fail over in 10 seconds, 30 seconds, 60 seconds, 90 seconds, or they don't feel over. Our 99th percentile of failover times on MongoDB Atlas is 840 milliseconds. That's not an outage. That's a blip. Apps don't even notice it. So customers who work with our software and customers who work with modern distributed systems, like AWS provides, like Azure provides, like GCP provides, they don't want to ride through outages. They don't want to have outages. And that's the key thing that we're helping people provide. Of course we still have outages. Of course we still have problems, but the software and distributed systems way is designed to not have outages. And that's a great point. I want to ask this a great point. I want to ask the next question, which is, okay, I'm a customer or I'm a company. I'm like, hey, I'm going to build this product. I'm going to put it on AWS. I scale up, I get thousands of customers. I'm about to go public. I'm super successful. Thanks to the hyperscales, capex, I don't spend a dime, but I'm paying Amazon. But I've already made my money, I'm successful. Great, now I want to go to Google and Azure to increase my tan. That's what people are doing right now. They're not, they take, be successful on one cloud. Then they're going to bring it on premise. Then they're going to create connective tissue between the clouds so that their systems can run. I know you guys done a lot of work with the multiple clouds to create an experience that's unified and positive. Less friction. So there's two levels of that experience. The first level of that experience is, you can write an app that works on MongoDB, on Azure, AWS, GCP, all day long. Okay, same app, exactly the same, no difference. Okay, that's thing one. Thing two is, you can actually run an app simultaneously across all three clouds. And we will let your cluster run across all three clouds, including failover. Now what a lot of people use this for, is they use it if they want to migrate an app from one cloud provider to another. They want to say, hey, you know what? This app belongs on GCP, near where my BigQuery data is. Or this app belongs over on Azure, or this app belongs right beside SageMaker on AWS. They can actually spin up nodes on the other cloud provider, have their apps move to the other place, and with one 840 millisecond failover, move their app between clouds. No other vendor offers that. Now I got to tell you, the cloud providers kind of don't like that. Of course. Except what it does, in all honesty, is it levels the playing field, and it makes us be more honest with our customers, it makes cloud providers be more honest, and be better partners with each other. And I actually think it's really healthy for the industry to have these level playing fields at each level of the platform. Well, it's not only that, it's choice and developer affinity. Because if you want to move your workload to the data, that's a lot better than moving the data to the workload. Because if you want to move your data from GCP, we all know what that looks like to Amazon. It's a lot of work and cost. Why not? We have customers who look at moving data between clouds. It might be six months to a year at full network bandwidth. It's easier to move the app to the data. I mean, operational disruption is a huge switching cost when it comes to making decisions around who to work with. This to me is a fundamental old school IT mentality. Hey, let's make complex things more complex with complexity. Versus the developer who wants infrastructure as code, they want to just build the app. I just want to write software and I want it to run. So I think this is where I love this AI angle because I got to have the base system in place to take the headache away from running stuff. I just want to build. So I think we're in this early stage of a Cambrian explosion of AI apps or data apps, in some say data apps, I call them data apps. Snowflake calls them data apps in the cloud. So they get the data is now an application feature. Yep, that's exactly right. So one of the things we do is with our Kubernetes operators and our Terraform operators, literally moving between clouds is you go and update one line in a config file. That's it. The app moves over, it's there. So this data thing I want to hit on for one second. One of the biggest problems we saw customers having on my prior career is once they exceed the limits of that system in terms of data, they hit this wall. And all of a sudden they're re-architecting. They're breaking out into different databases, they're breaking out into different storage tiers. With MongoDB. Why are they doing that by the way? They're doing that because the system might hit a wall. Like one of the most popular relational databases out there hits a wall at 64 terabytes. You know, 64 terabytes ain't that much. And now you got to re-architect. You know, we have customers running petabytes. Okay, so that's one thing. The second thing is you got to have the data only cost what you're willing to pay for it. So there's two elements to that, which I really want to get to today. One is we let you stage your data out in S3 on AWS or in the other blob stores, and we let you still query it. So if you decide to make a cost decision to move last year's data out, you change zero lines of code. Those queries for last year's data are just slower. The second thing that's really important is if you have 15 to 20 tables and you're querying something, it might take 30 to 50 IOs to get your customer record back. With MongoDB, because it's a document, it might take you three. And I'm telling you right now, I'll cost money, I'll cost huge amounts of money. And with NVME systems and network systems and network drive systems, IO bandwidth is actually the limiting scaling factor for a lot of people. Scaling factor, critical point. Critical point. Mark, great masterclass we're putting on here. I wish we had another hour. We can go deep dive. This is super important as the CTO Mongo, your story career, you've seen in movies many times, you've seen the multiple waves of innovation. How do you see this wave playing out? Share your thoughts on this big wave, I call it the biggest wave of all, AI bringing cloud next generation cloud and the fact that Mongo's position. How does Mongo fit in this wave? Share your thoughts on how you see the future emerging and how you want Mongo to be perceived and implemented by customers. So the first thing that I said is I do believe that had we designed Mongo 16 years ago for AI, we would design the Mongo we have today. You talked about luck and good, whatever, I think it's a combination of being prepared. The second thing, my oldest son is actually a programmer and so he gives me feedback all the time on my products and he says to me, Mark, what I really need you to do is remove friction from my day and he says, if you remove friction every day, I become more and more loyal every day. So our goal is simple. It is to remove friction and delight developers and that's it. And that is the North Star of our entire company and it always has been. And I think it's a fabulous position. I think it's coming fast. I think you guys are the first ones to really have this position and I'll see anyone doing this. So congratulations on I think a winning hand here. It's not about winning the developers over. I hate that phrase. You don't want to win developers over. You want to be aligned with them. It's not about winning anything. You win when you've been successful with them. So you guys doing a great job. I think that's a great thing. I think data as code is here. I think it's like security market. The whole shift left phenomenon being in the CICD pipeline in the mind of the developer. Easy, programmable, easy. Let someone else take care of the guardrails. That's you guys. You're going to see a lot more coming from us over the coming years. Mark, thanks for coming on theCUBE. Mark Porter, CTO, MongoDB. Laying down what's going on in the technology, what it means for customers and where it's going here in theCUBE. We'll be back with more live coverage after this short break. I'm John Furrier, your host. Thanks for watching.