 Live from the Julia Morgan ballroom in San Francisco, extracting the signal from the noise, it's the Cube, covering Structure 2015. Now your host, George Gilbert. This is George Gilbert. We're at the Iconic Structure 2015 Conference, downtown California at the Julia Morgan ballroom. And we are privileged to have David, you did cherry, yeah? I've mangled that one. That's okay. Chairman and CEO of MongoDB. Mongo has taken the world by storm over the last several years. For decades we were accustomed to SQL DBMSs with hardcore transaction processing. What allowed MongoDB to take off? Sure, the company was founded by people who saw the data management challenge like 15 years ago. So the founders of MongoDB were the founders of DoubleClick, the largest global ad serving network in the world. And they were serving billions of ads per day. And what they struggled with was having a data management platform that could deal with that amount of volume of data. And what they realized is that a new solution had to be built, especially with the nature of applications data just going to the next level. And so that was the callus for them to start MongoDB. And that bet has paid off. MongoDB was built on a vision that you needed a platform that was incredibly flexible. You needed a platform that was massively scalable. And you need a platform that could run anywhere, either on premise or in the cloud. Okay, so let's take those vectors perhaps one by one. So in terms of flexibility, is it that developers didn't want to keep going back to central IT and ask permission to add a field or a table? Or was it that machine, more and more of the data was sort of machine generated and you couldn't really predict exactly what components that would have? Well, I think with the relational database, there was lots of benefits with the relational database. It was like a standard way of writing and reading and data for an application. But there was an inherent tax involved in terms of how you'd work with a SQL database vis-a-vis that the development language you're using. So there was this translation layer from the development language you were using to your relational database. And in those days, data used to be a nice rows and columns so that was pretty manageable. Well, a couple of things changed. One is the nature of data has changed. We now have data can be a video file. It could be a graphic. It could be unstructured text. It could be machine data. So the nature of data has changed profoundly. Second is the volume of data has just exploded. And third, the nature of how applications are built are incredibly agile in the sense that people don't want to have six-month release cycles. They want to have two-week or maybe even daily release cycles so people have to iterate. So they don't want to presuppose a solution that then they have to go rebuild again. They want a flexible architecture and hence a schema that they can continue to adapt as their data requirements change. Okay, so that's all mom and apple pie and goodness. We all want that ability to be flexible and what goes along with that is I don't have to exactly design up front every last thing about how I'm going to use the database. Exactly. But you trade off something for all that goodness which is it's harder to do the analysis on the back end after you've captured that data, I assume. Not necessarily, so in fact in our latest release of software we've announced the ability to connect the latest BI tools like Tableau, Cognos, Click, or any other standard BI tool they're using to basically, you can basically access information from Mongo directly without using an ETL solution. And so that becomes very powerful for people who want to do sophisticated analytics and we are a transactional database and so people want to do real-time analytics and that's one of the biggest use cases. Okay, so then, all right, let's talk about the class of applications. Talked about flexibility and volume. Did Mongo start out as the flexible way of developing an experience for a web or a mobile front end? And if so, has it evolved from there? MongoDB was built really to run anywhere, it was to be always on and run anywhere. So whether you're building a mobile app, whether you're building a large-scale analytic, e-commerce application, whether you're building an IoT application, if you want to run it on your prem, if you want to run it in the cloud, if you want to run it in a hybrid environment, you can do so with MongoDB. So you're not presupposed, you're not kind of limited to any kind of underlying kind of architectural constraints. So that's very powerful, especially for, say, a small company that doesn't know how well the business is going to take off, they can build on MongoDB and know that the solution is fairly future-proof. On top of that, we do offer some of the features that people still like from Relation Technology. We didn't think that the relational solution was all bad. Things like a very rich, expressive query language, things like strong consistency, things like secondary indexes are all features that developers use to make their applications perform optimally. And some of our competitors, we didn't really focus on that, they just focused on making people trade off the features from relational versus the flexibility performance and scale of next-generation databases, and we allow you to actually, in some ways, have your cake and eat it too. Okay, have you found that the class of applications you're being used for has changed over time with these new features that you're adding? Absolutely, so it's really a function of the maturity of the product and comfort by customers. Customers are starting to trust us more for more and more of the mission-critical applications. So originally they may start working with us on some skunkworks or some prototyping and maybe some tertiary applications, but as they got more and more comfortable as their developers became more and more familiar and as the product added more and more capabilities, and we've added capabilities not just for developers, we've added tools and solutions for operations to run and manage Mongo at scale. We offered solutions, like it's mentioned, for the business analysts to be able to access data quickly, so it makes Mongo much more appealing to a larger population. So with that, we're seeing Mongo evolve from kind of these early prototyping projects to truly mission-critical applications, whether they're new applications or sometimes they could be moving workloads from legacy platforms to MongoDB, and so that's what's really giving us a lot of excitement about our business. Even if you have to anonymize, can you tell us some of your largest deployments and sort of the characteristics of those apps? Well, I'll tell you, of the Fortune 100, every one of those organizations is either a customer or user of MongoDB. We have some of the largest financial services firms who are deploying MongoDB as a platform, either to move workloads from existing platforms or for some of their new applications. We have the largest retail, e-commerce, telecom and cable companies using Mongo for a variety of different applications to run their business. And then we also have people like small companies who are essentially bettering their business on Mongo. I'll give you a couple of examples. One really interesting example is a company called Oxford Nanopore Technologies. They've built a palm-sized device that essentially allows you to take any living molecule and decode the DNA of that molecule in real time or essentially four to five minutes and they use Mongo as a data management platform. So what they do with this device is essentially stop the spread of diseases like Ebola in places like West Africa. So that's pretty profound. We have another, you know, we have like Bosch who's a pioneer in IoT who's leveraging Mongo to add more and more sophistication on the sensors that they offer in the devices that they sell. Let's drill into this a little bit because IoT is of intense interest to customers right now and you know, we're hearing about it all the time. The IoT sort of application architectures somewhat different from, you know, traditional transactional applications. Sure. What does it look like in this case? Sure, so with IoT, any individual piece of data is not that interesting. It's really the aggregation of data over a period of time that becomes much more interesting. But the key part of IoT is that you need a platform that can be inherently flexible because the sensors you start using today may either change or you may add additional sensors over time. Look at your iPhone. Your iPhone when it was first introduced maybe had two or three sensors. Today has over 15 sensors, right? So you can't predict what new sensors you're going to add and what data formats that data's going to be need to be collected in. So you need to have a data management platform that allows you to collect that data quickly and to be able to synthesize that information quickly. So Bosch, for example, has standardized on MongoDB to essentially drive their IoT business for those particular reasons. But then there's also some very, very sophisticated predictive and prescriptive analytics that typically go along with the data that's streaming in now. It's not, it's the center of gravity shifting from big data to fast data and from fast data to analyze it with very little delay. So that's a real benefit with MongoDB. You can truly do real time and what I mean by real time is sub-second analytics and our customers are pushing for us to do that because obviously being the backend database of every application that's where the data's essentially generated or stored. Now you can obviously use technologies like Spark or Hadoop to do much more sophisticated analytics that require maybe not sub-second response but people are using us for, to your point, fast data for many interesting use cases. Can you give us, not to get stuck on IoT but like perhaps with Bosch an example app that would help people understand a concrete example? Well, for example, they're big in the automotive business, right? And so respecting the confidentiality, they're embedding devices that car manufacturers are putting in to track information about what's going on in these cars. There's some very well-known new car manufacturers who I can't mention who may be using some of those sensors to provide real time feedback on how the car is working and also to learn things like driving behavior and other attributes of what's going on to be able to improve the driving experience for their customers. Okay. I'll give you another example that's another pretty interesting app, Accsa Insurance. When the Apple Watch came out earlier this summer, they very quickly realized there was an opportunity for them and what they did was they basically built an application called Drive Coach which allows the user to track their driving behavior and say, how am I driving? And it'll give you feedback. Oh, and it's instrumented on the watch. It's instrumented on the car. Exactly. For example, they'll give them feedback on how good of a driver you are. How quickly do you accelerate? How hard do you break? How quickly do you take turns? And that feedback then helps the driver essentially become a driver, essentially get feedback on how to become a better driver. In real time. And so, and the value for Accsa is that if that driver now wants car insurance, they have an immense amount of data to say, I can describe a certain type of risk for this kind of driving behavior and obviously Accsa now is viewed as a very different company than a traditional insurance company. I'll be sure not to sign up with them. So, shifting gears to the commercial side somewhat, database companies typically or recently, they go into an enterprise and they get the developers the design win, but then they need to sell to IT sort of as the IT's willing to pay for uptime. How does that affect how you do business in terms of pricing, the size of the sales force you have to field? Tell us a little about that. So we do offer today a general purpose free product. We call it a community version that anyone can download and use for free. But then there are certain features that if you need from a management point of view, if you need from analytics kind of point of view, if you need and other things to kind of run and manage manga at scale, that we encourage you to use our commercial product which has these features. We also have some advanced security features in those products. So that's important for certain industries. And so the way we monetize the community is for people who have, we find people who have very critical projects so they're not necessarily science projects anymore, but they're critical projects. And two, they're predispositioned to use some of our paid features. And typically, if you meet both requirements, they tend to be prime candidates for people who we can sell to. Do you find that your competitors are constrained by legacy pricing models that without naming any competitors that they can't really break out of that business model? Yeah, I mean it's the classic innovators dilemma. What we're seeing is that are the large incumbents, they're basically using pretty aggressive sales and pricing tactics to try and extract as much value from the customers, which customers are getting tired of. And so on a cost basis, people can easily justify five X cost savings using MongoDB and the productivity gains are 10 X. So it becomes a pretty compelling cost proposition for people to look at Mongo versus the alternative solutions. Okay, David, we have to stop it there. This is George Gilbert. We're at structure 2015. We'll be back in a couple minutes.