 Okay, we're back here live in Las Vegas for Amazon. Reinvent, this is theCUBE, our exclusive coverage of the event. I'm John Furrier, the founder of SiliconANG. I'm joined with my co-host Dave Vellante. Our next guest is Elliott Horowitz, co-founder and CTO of MongoDB. Great to have you on. You're a celebrity in the big data world. Obviously, Mongo has been an amazing success. We've had you guys on theCUBE, I think. Going back two years ago, Oracle Open World, just watching the enormous rise of Mongo has been really fun to watch. There's two trends that we've always loved, that's Hadoop and Mongo because developers, the LAMPstack developers were doing stuff, but we're pretty cutting edge with Open Source and MySQL and all this great stuff, but it was just like a glass ceiling, right? And then breaking through, making it really easy was something that you guys really did well. And I want to get your perspective on that right now. Looking back, where you guys were, and kind of now, with all the hype of, oh, Amazon's taking over the world, go back in time for a bit before we get to someone who's on the show, and what was that breakthrough for Mongo because you guys really hit the nerve from the beginning and then had a breakout right when it was like, oh, this is easy. So I think the breakout for us is really figuring out early on what developers really wanted from a pure productivity standpoint. But it's really a matter of figuring out, all right, I've got a developer, they really just want to build the product. They don't want to work on databases, they don't want to figure out how to scale a database or how to work around the database, they just want to store their data and interact with it easily so they can do their job. And I think the key thing we figured out early on was the data model. The data model of MongoDB lets developers be very productive, it lets them scale, it lets them do all these things pretty easily without actually reinventing the entire way they interact with the database, right? There's two things I think that were very good. One is we changed the data model from relational to a document, and we also kept a lot of the things people were used to, we got how indexing works and how consistency works. We kept those things from the relational model so people coming over didn't have to relearn everything because there's already a lot to learn. Yeah, you move from different language, different frameworks, new syntax, new way of doing things. So you guys really kind of spoke the language of the guys in the mainstream web development side, right? But wanted to give them more scale. That feels like, that is like the DevOps philosophy, right, I want to program, write code and make a lot of the stuff under the covers work at scale, scale and work better, right? That's kind of the DevOps philosophy. Yeah, and it's all, in my mind, it's all about productivity, right? DevOps is largely about productivity, about reducing the time to market, reducing the time to get things out there, reducing the complexity of software and operations and managing things more simply. And I think that's really what a lot of what we want to do is increase developer productivity, increase ops productivity by giving them better tools, by giving them a product that takes a lot of the things they had to do before, unless I'm focused on their core mission, right? Because no one starts, except for us, right? No one starts a company and wants to work on databases, but they start a company to build a product, to build whatever it is they're building, and they don't want to, and our history had been, every time we wanted to build a product, we ended up spending all of our time working on databases, which was very counterintuitive to what we actually wanted to do. Yeah, total pain in the ass, and we wanted to actually just solve the problem once and for all, so the next time we wanted to build an application, we could actually just build the application. That's the beautiful thing about leverage, right? When you have leverage, then better things happen, and it's also an open source ethos too, build on the shoulders of other stuff. I will say, Dave and I, we're joking like a couple years ago, actually last year we said, if 10 years ago, if you went to a party and said, hey, I'm a database expert, oh yeah, where's someone else? Now, if you're a database expert, you're like a rockstar, you're going to get that. I go to a lot of events for my kids' school, right? So I was at an event the other night, and I said, yeah, I work for a database company, you don't know what it is, what is it? A MongoDB, a MongoDB, that's so cool. Guys who I would have never thought would have known anything about databases. It's a pool of jays. Cool is a word because you guys create value, and one of the things we've been talking about here is the startups that we've been showcasing, Elliott, is, the time to value is just a concept that just makes good things happen, whether you're an agency doing stuff for clients or you're shipping code. When people start seeing traction or anything good or bad, they can make adjustments, right? Iterate through, agile, whatever you want to call it. So, you know, the cloud is perfect. You guys have a perfect product for that. But I got to ask you, and let's kind of keep that timeline going down. You've been criticized in the past, and this is just natural evolution. You can't scale. At a certain point, Mongo doesn't scale. You guys have addressed that. So I want you to talk about that specifically. You know, some people say, hey, you know, up to a certain point, Mongo's great, but at some point it doesn't scale. How do you address that to the folks who say that? And what are you guys doing to push that scale? So, you know, I think a lot of that comes from a few things. And I think a few years ago, there was this perfect storm where Mongo was still a little bit immature in some ways, especially concurrency. And frankly, AWS had some problems where EBS was a little slow and they didn't have SSDs or priority IOPS at that point. And you actually had this little bit of a perfect storm of problems where if you were using Mongo and you were on AWS, it didn't scale very well, and it was trouble. And by scale in this case, they really mean scaling up on a single server, right? Not horizontal scalability, but just, you know, making good use of the physical attributes of the machine. And so over the last two years, a few things have happened. One is Mongo's gotten a lot better at concurrency. So we've done a lot of work on that. It's still a long way to go, but we've made a ton of progress. I think over the next couple of years, we'll make a lot more progress, but we've done a lot of progress. And also like AWS has improved dramatically as well, right? They now have two new products, your priority IOPS and SSDs. And so now, if you take the same problems you had two years ago, write it today, and you really just won't have any problems, right? One of the key things to remember at MongoDB is, it's still only very early in the database space. If you compare it to Oracle or any established database, it's still a very young product. And databases are one of the more complicated things to build, and these things will take time to fully mature. But I think over the last two years, you've seen a lot of improvements. Over the next two to four years, I'll see a lot more improvements. So a long way to go. So what led you to take us back? What led you to commit so much of your time to Mongo? You were describing earlier that you were trying to solve problems and improve productivity. Well, why Mongo? And then why has Mongo been so successful when you've got 50 other no-SQL databases out there? Yeah, so Mongo for me, when we were looking at, when we started trying to figure out, all right, we sold Shopwiki, we were trying to figure out what to do a little bit, and we were thinking about building some applications, and every time we came back to it, we were like, well, we don't like the tools available to us. And we knew we were going to get bogged down actually building databases. And the more we thought about it, in the last decade before that, some of the best times I had as a developer was actually building databases and solving the data problems. And it was like, all right, well, why try to solve these things and this one niche application again, let's just go ahead and build a database that actually works for us. And we really just built what we wish we had, right? Which is a great thing to do, is build something that I want. And then hopefully, the idea at that one was hopefully other developers feel like us and want it also. And it turns out they did. And I think the main reason really comes down to a few things. One is the document model. The document model is intuitive for people. It makes sense. It's very productive. It's really easy to work with. The document model lets you scale horizontally. So that really drives everything about the product and everything about the adoption where people really can be incredibly productive with their main work rather than having to work on these problems they don't really care about. So you heard the Amazon announcements today, probably knew they were coming up with the optimized compute, the SSDPC we're talking about. Talk a little bit more about what that means for your customers. So I think it's definitely great for our customers. Because before, if you wanted to use SSD's and Mongo, you had to use these very expensive instances that frankly were pretty cross-rehibited for some applications. And I think they brought them down to the large instances where now it really brings it into the realm of possibility for a lot smaller companies. It really just lets people be a lot more cost effective with Mongo and with any other application that is IO intensive. Right, so and the good news is unlike companies that sell tons of licenses, you don't have to worry about these optimized instances eating away at the license. I love it. And for us, especially with people on AWS, what we care about really, first and foremost is making developers productive, making people really happy with Mongo, making Mongo a really great tool for people. And over time, as that happens, I think monetizing it is hard, but the onus then becomes on us to figure out how to add value in ways that people want to pay us. But first and foremost, our goal really is to make developers productive, make operations people productive and really sort of drive the Mongo ecosystem. So you've watched the evolution of databases over the years and markets evolve over the years. You got to expect there's going to be consolidation in this business, maybe not tomorrow, but over time, it's got to happen, right? So first of all, do you agree with that? And how do you see that shaking out? I mean, what do you think is the timeframe will be? What gives you confidence that Mongo will be the one remaining standing and just talk about that a little bit? So I definitely think there will be consolidation, right? And I think that there'll be consolidation in two ways. One is the number of database vendors. And two is right now you sort of have this mentality of, oh, I'm just going to try a different database for every different problem I have. And I don't think that's really the right model, right? I think the days of like one database for all my problems is definitely gone. You're not going to have companies betting everything at a single database, but I don't think companies are going to want to have 20 different operational data sources. I think you're going to want to have three, maybe four, and you're going to want three or four ones that really cover the entire, you know, spectrum of your database needs. And I think what you'll see is a few different things. I'll have a relational database, because relational databases are not going to go away. There's a lot of great use cases for relational databases. You're going to have some sort of data warehouse, because you've got a lot of data and you need something that does batch processing where you can sort of do in the background, do massive jobs, and you literally understand the sort of massive amount of data you're storing. And you'll definitely need some sort of document database where you can store sort of some loosely structured data that's just, you know, so developers can be more productive in certain cases. And maybe you'll also want something like a key value store cash kind of system that is a little bit simpler and a little bit more lightweight. And I think that's, and then I think that's where the market will go. And I think one of the reasons why there are so many vendors right now is you've got different vendors and they all have sort of one feature that people really care about, but they're all, the products are so new that there isn't one that has all of them yet. And then sort of in the NoSQL market. And I think what you'll see over time is that as, you know, these databases will actually keep adding features and really sort of consolidating feature sets as well. Right, you know, have products that can do lots of different things. Right, one of the reasons why people choose other databases over Mongo today is for eventual consistency. We view that as a feature that Mongo should have in the feature. Doesn't have it today, I won't have it tomorrow, but over the next couple of years we think it absolutely will have that feature. And I think that's, those are the kinds of things where you'll definitely see consolidation as this product is. So you're consolidating around those four areas and those four areas will cover the sort of spectrum of requirements for the foreseeable future. Yeah, that's my belief. And I think, you know, whether we're the document database of the future, I mean, then it's really, I think we will be and we just have to make sure we keep delivering on the product and keep advancing it and not really get stagnant. You guys certainly have established the standard in my opinion. And I want to get more in detail on the consolidation. I would definitely agree with you on the assessment of those areas. But I want to ask you to describe the use cases because, you know, I always see blog posters. I just read one yesterday. It was Trashing Mongo. But you know, you can't please everybody, right? Maybe someone's using you guys in the wrong way. Someone's in your leader. You know, well, it's also bad design. Maybe you just pick it up because you're used to it and you might misfire on a project. So I want you to just not set the record straight, but just educate the folks out there. Hey, this is the bad ass scenario for Mongo. We're bad ass. We do the job well, extremely well. And here's areas that quite frankly, you might not want to use Mongo. Yeah, horses for courses. Take us through. Take us the horses for courses, as Dave says. Right. So I think, you know, areas where Mongo works really well is anything where you've got a lot of data about an entity. So think user profiles. But if I want to start information about a person, right, I've got lots of different attributes. I've got different things like addresses, where it's not a one-to-one mapping, where it's a one-to-many mapping. I've got addresses or likes and dislikes and all these attributes. And storing those in relational databases is actually very hard and very tricky. So that's a place where MongoDB makes a lot of sense. Right, so any kind of CMS, CRM type data, those things make a lot of sense. For relational databases, there are cases where you have data that is relational. And it's kind of amusing if you actually go back and look at the original relational database papers, they actually lay out a set of use cases that they're designing for. And frankly, the use cases they were designing for, relational databases are still the best options for those. Right, if you think about accounting and finance, they actually are the best. And they lay them out very well in the original papers. And what happened is they built these things for those use cases, and people found that they were good enough for other things until they tacked those things on. But the original design goals, they've actually met them incredibly well. So would you say then, if I prove out the following phrase, Mongo is really good for loosely structured data. I mean, unstructured means it's got nothing. Data always has structure. But what we were basically saying is, hey, here's some loosely structured data, and we can help you just store it. I think loosely structured is definitely a great, I think we can do more things than loosely structured, but loosely is a great example for us. Where you've got different kinds of things that are kind of similar, but kind of different. Right, you've got different types of media. You've got videos and images. And you don't know yet how they relate to anything, so you just want to store them. Right, you've got images. A little bit of metadata. Put it in a pile and go get it later. You've got images and you've got video. You want to put them all in the same thing so you can show them together and search for them together. But they are different. They've got different attributes, sort of a little bit loose. So is this why you guys, is this why you're having such success with web apps and mobile apps? Because think of it like, well, key value storage is also good for web apps too, but there's a lot of social data out there where I got an app and I might want to go get some data. I just don't know when or why I'm going to get that data. Yeah, that's a good use case. The other use case is anytime where you're dealing with APIs. You're dealing with like 50 different providers and they all have different APIs. Well, they're going to be changing their APIs all the time and they're probably giving you some JSON back and they may change it. They may add fields at some point. So you may actually have a structure at any one time or a scheme at one point, but that's changing and you don't actually have control of it. So it's actually a great use case for things like that. Schema less and schema light, whatever you want to call it. I mean, but not hardcore schema. That's relational. Oh, the relational can keep that. We just had Duke and HBase fit in there. Obviously that's a different philosophy. It's getting some traction. Some are saying that it's losing a little bit of traction right now. So, you know, Hadoop, you know, look Hadoop was designed for offline batch processing. It's still one of the, it's still the best solution for offline batch processing. And what you see is a lot of people using Mongo and Hadoop in conjunction with each other. They store their OLTP data with Mongo and then they process due to batch processing in Hadoop. We had a big H base thing. I moved it to DynamoDB almost story itself, but we basically would roll it up in my sequel. We had a huge batch. Yeah. I mean, so Hadoop is still a great way to do that. So I don't think, you know, in some ways, I don't think they're actually that competitive. So I think, you know, as I said before, I think you will have a warehouse, you know, you need warehouse products, right? It's a different workload. You need different features. Last two minutes, I want to get a thread in. I got trashed on Twitter earlier. I made a tweet that said, and again, it's always hard to tweet when I'm alive on the queue, but I did say Amazon is extending their lead just with all their new integrated stack on open source and moving faster than open source. And I was basically implying, you know, with Lumen Hives and the warehouse space, specifically with the closed loop that they have, going, oh, I open source. Of course they're using open source. So I've got to ask you the open source question. And I asked Martin Mikos yesterday, I said, tell me what's different. You were the pioneer of my sequel, you know, you're a celebrity too. He says, 10 years ago, it was about source code. Today, it's about source code and about data and about APIs. And so talk about that. Talk about that dynamic of open source now. Do you agree with him? That's not just what the source code anymore? I mean, I think it's more about the product now. But I think people, you know, the source goes there. And I think in some cases, open source has become table stakes, right? I don't think an infrastructure product can actually exist as a closed source product anymore. I don't think if you try to launch a closed source database and try to get some sort of wide adoption, I don't think you can do it. So I think open source has become table stakes in some ways, where it's the default. If you don't, you know, you have to prove why you shouldn't be open source. And so now it has become about other things. It's a cover charge. Maybe this child will ride the roller coaster, right? That's how you get in. Right, you have to be open source now. So that has completely changed. 10 years ago, they were the first and now everyone has to be if you want to be in this game. So that means speaking to how you guys are having experiences with Mongo and different environments, that's where the APIs come in. Now you got data and APIs. That's right in your wheelhouse. Do you agree that's part of it? I think so. And I think APIs really is, you know, data is a little bit tricky, but APIs I think for sure, right? You know, because as you bring in, you know, the web has brought so many, you know, disparate little services where you can plug this really complicated thing together by pulling pieces from different places. And APIs is what powers all of that. And so that is a huge thing for the future. This is theCUBE. We are pro open source. I'm not retracting my comment, Matt say. I'm still sticking by what I said, but on that one thing, we love open source. We love what it does. And certainly the game is changing. The sands are shifting. Amazon is clearly standing there to lead. I believe that they're light years ahead of anyone in the public cloud. But again, open source is a great environment right now. It's changing. It's maturing. It's going to the next generation. This is theCUBE. We'll continue to cover it. We're here live exclusively the Amazon Web Services Conference re-invent. I'm John Furrier with Dave Vellante. We'll be right back with this short break.