 Thanks, Tony, and thanks to everyone who organized the conference. Thank you all for coming. Let me start with just a minute about me. I've been in the database space for almost 20 years. I was at Oracle for nine years. I did a bunch of different jobs there in the e-commerce applications as a chief applications architect. So I saw the database mostly from the perspective of somebody trying to build applications on it and building some of the newer applications. I then spent seven years at Mark Logic and then the most recent three years at TenGen. I don't like the fact that I'm old enough to have been in the database industry for 20 years, but I'm actually the same age as the relational database. And so all this gray hair on me, I think, is symbolic of maybe a time for some change in the industry. My background, I'm really sort of a geek turned business person, but I'm going to not talk about the bits and bytes here, I'm going to talk about the industry trends. So I want to talk about where I think the industry is, where we're going. This will not be like the roadmap of features that are coming in MongoDB. It's not going to be an advertisement for one no-sequel product over another. I will tell some customer stories to illustrate points that are MongoDB related, but you should take those as examples of what I think is going on across an industry. So we'll start with some history and why I think now is a time that this industry is really going to change where we are today and then where this industry might go and how we can all help to bring it to, I think, where it deserves to be. I think we're at a really interesting moment in the history of the database industry and I think the people in this room, the vendors and the users will all play a big role in charting how the industry evolves over the next few years. So I'm going to start history before the invention of the relational database. This guy on the screen is Opabinia, it's about 540 million years ago and it lived during a time known as the Cambrian explosion. There was life on Earth for a long time that really was relatively uniform, single cellular, and then in a period after life was around for a couple of billion years of a few tens of millions of years, sort of magnitude a percent of the time that life had been on Earth. There was this explosion of diversity that came onto the scene, where the vast majority of the body plans that plants and animals have today were formed in that window of time of a few tens of millions of years, about half a billion years ago. Now, I don't know, and I don't know that anyone knows for sure, I'm not a biologist, what it was in the environment that caused all that change to happen in that narrow window. People talked about temperature changes, changes in the composition of the atmosphere, etc., that affected the balance of the ecosystem in which all these organisms lived and caused a very rapid evolution. I think what's going on today is that there have been a bunch of changes in the computing landscape that I'll talk about that are now causing a very rapid evolution of database technology. Biological and technological evolution are similar in some ways, they're different in other ways. They're similar in that the innovations that occur, whether they're in the plan of an animal's body and how it lives its life, or a piece of technology that we use, succeed or fail based on how well adapted they are to the environment in which that organism lives, or in which that software operates. So, and there are many changes going on at the same time that are part of a complex equilibrium where a new technology comes on the scene, and that affects all the other technologies with which it interoperates. Now, one thing that's different, I should say, is that with biology, there's this constant stream of mutations at a relatively stable rate. And the rate of change is determined by how many of those are actually successful. In technology, there are other factors that actually also affect the pace of innovation that's occurring and how many new things come on the scene. How much money venture capitalists are giving out and people's belief that they can start a company, that they can innovate. There are a lot of other factors that influence things in technology. But a lot of it comes down to the environment in which people live and that complex equilibrium with the rest of their ecosystem. So, fast forward now to 1970, and to just get us in that mode of 1970. The guy on the screen is Marty Cooper, who invented the cell phone. Actually, in 1970, it was still a prototype. I think that phone is from 1972 or 1973, but it sets the spirit of the time as a very different world. And the way in which we interacted with computers was very different, right? So this is the way that we interacted with computers when the relational database was invented. So that's a job control card from the top of a punch card deck from the Columbia University Computer Center. And I know we're starting to get terminals there. I think deck had just introduced the VT-50, this futuristic thing with a keyboard and a screen that could actually show letters on it. But that was an innovation that most people didn't have access to when they interacted with computers in 1970. So very different ecosystem. I'm gonna fast forward now, and I'm gonna fast forward through an era that I think we're all familiar with. And to 2003, ten years ago and the very beginning of the smartphone, right? So here's a BlackBerry, now ten years old. And now we interact with computers on iPhones, and maybe soon we'll interact with computers on something like Google Glass. So the ecosystem in which these computers are working, the software, the databases is very, very different. In particular, the way people develop applications has changed dramatically. Most acutely in the last decade, right? The types of data that are a part of our applications world are much, much broader. The way we develop is much more iterative, much faster. People wanna push out new functionality every week, every day, sometimes by the hour. Gets deployed into cloud style environments consumed on mobile devices. And many of the decisions are made by developers, right? The decision making around software development is much more decentralized. It's a very, very different environment than it was when the relational database was invented. And many of the decisions around the design of the relational database are not well optimized for this environment. So as you try to use a tool that was designed for maybe running payroll for a few thousand employees to track social media mentions all over the internet, a lot of things begin to break down. And so here are some of what I see as the symptoms of the breakdown of the relational database in attempting to solve many of today's problems. Now, I'm not here to say that the relational database doesn't have a place. If I were building a payroll system, an accounts payable system, an accounts receivable system, I would use a relational database. I think it's well suited for that type of application and that type of data. That's just not a lot of the applications that we're building today. So one of the things that we learned very early as we're trying to build applications is to try to avoid hitting the database wherever we can. So we put caches in front of it, we pre-build the pages. People build sophisticated caching infrastructures where they can keep track of different versions of the page based on whether you're logged into the site or not, all of this to avoid hitting the database. Then meanwhile, we also have this well-developed science of how do we normalize a database for a second, third, fourth normal form, etc. But then we denormalize it for performance reasons. We build these complex data models, but then we use these tools to map our objects to them because they're too complex for us to understand. We manually shard our systems. The whole development environment becomes very complex because we're doing a lot to work around a database that can't deal with the volume, velocity, and variety of data that our applications demand. It creates a lot of rigidity. It creates data in silos. I was talking to my dad the other day who'd bought a couch and decided that it wasn't the right one. So he called Restoration Hardware to return the couch. And the first question that they asked him was, did you buy it in the store online or over the phone? Because those orders were in different systems, according to how you'd bought the couch. And he scratched his camera and looked, see, I went into the store and I saw it and then I called you and then I looked on the web. I'm not sure. I think I may be bought it on the web. There's no reason that this data has to be siloed, but the systems today aren't as flexible as we need them to be to do business in the way we want to do business. I thought I'd illustrate the complexity that we create. This is a relational data model. I apologize for the small font, but I was trying to get it onto the screen. It's something out of the biotech industry. It's actually something, credit IBM for doing this. And it's actually, their example was how much simpler this would be in XML, right? And they had a very simple XML structure that modeled all of this. Now whether the answer is XML or JSON or wide columns, the point is that we're often using a tool that's ill-suited to the job that we're trying to solve. Making a developer understand this and code against this is a recipe for applications taking a long time and having a lot of bugs, right? So people I think have begun questioning a bunch of things. First of all, do I even want a database? Do I want an appliance? What's the right data model? How am I going to deploy this? Can I take advantage of in memory? What should the consistency model be? Everything's been kind of open for debate in a way that it hasn't for most of the last few decades. And NoSQL was born out of a set of choices in response to some of those questions where people said we need a different data model. We need a distributed architecture. Most of the people who would be considered a part of NoSQL said that it should be open source, that there should be some rethinking of transaction semantics and some form of new query language. And I think the naming is unfortunate because the query language change is, in my opinion, the least important change of everything that's being rethought in databases, but that's where the name for NoSQL came from. This is what I think the NoSQL databases have in common. The great news from my perspective, and I think from the user perspective as well, is that the NoSQL space has been growing very quickly. So this is a chart that I took from Indeed.com. They go through job posts and organize them online. And the orange line is the portion of all the job posts that mention RDBMS somewhere. And the blue line is the portion that mentioned NoSQL. I'm not trying to say that we're now at 80 or 90% of the usage level of the relational database. I think that many of the relational database jobs mentioned specific vendors. And there may have been greater specific desire for NoSQL skills because they're new. But the point is that there's a lot of growth and it's a material portion of the market now. There was a study from a 451 group recently that talked to, I think, about 18% of the respondents were using MongoDB. If you expand that to include NoSQL as a whole, it became quite large. So there's a lot of growth in the sector. You've probably heard of most all of these companies and some of how they use NoSQL pioneered at Google and Amazon and adopted by a lot of the other high profile web companies. What you're probably hearing now for the first time in the last year is some of the big traditional enterprises also using NoSQL. Companies like MetLife, Goldman Sachs, Telefonica, UK government. I don't have time to go into all of these in detail, but I thought I'd just tell the story of MetLife and their usage of NoSQL. Because MetLife is a very different type of company than Amazon or Google. It's been around for a long time. They have had 70 different systems that contained policy information. So when you called up to get customer service, they had 24 different call centers because they couldn't train one agent on all 70 systems and that agent would have to track down your information across a variety of systems based on the type of policy that you had, how you bought it, their history of acquisitions, etc. They'd been trying for years to get that data into one system, right? And this is not a problem that's unique to MetLife. It's not a problem that's unique to Restoration Hardware in the case of my dad calling them about his purchase. This is a problem that's common across many industries and many users. The challenge is that when you have to design that data model and you have to get it just right to accommodate every field that you have and you're consolidating 70 different systems and each one of those 70 systems is changing. You do your two-year project and when you're done and you're ready to roll it out, you find out that 11 of the 70 systems have changed, right? And so you go to revise it to catch up with those changes and nine of them you can handle pretty easily but two of them are a real hassle and it takes you six months and then four more systems have changed and you just never quite catch up to the current state. They were able to in 90 days get all their data into one system with MongoDB and roll that out to an initial set of users. My favorite part of the story was the reaction of the users when they start having access to all the data in one place. The colleagues who didn't have access would start IMing their friends who were using the new systems and hey, I've got a customer on the phone and I'm trying to find their policy. Can you look it up for me, right? That's a sign of a successful system. I think that type of business impact to be able to go in in three months and transform the way that they interact with their customers is a tremendous opportunity and I look forward over the coming years to doing projects like this across many customers and many industries. So I think we're starting to get some momentum here. There are a bunch of the bigger players in the industry are beginning to take notice, most of them in a way that I view as very, very positive. So whether it's IBM partnering with us around no-SQL query languages or Microsoft working to get no-SQL solutions in Azure, Rackspace and Amazon doing hosting integration with tools from ClickTech and Informatica, we're building that ecosystem where a user who wants to run their servers at Rackspace and integrate their data with Informatica and do reporting with ClickTech and plug into Red Hat security architecture. All of that stuff is beginning to work together. We see Oracle announcing pricing models and things like that that look more like the rest of the no-SQL market. It's great. We do have some competition from the big players now. I welcome that. I think it's great. I think it's inevitable. I think it's good for the industry and good for all of you. I will just put up a quote from Gandhi. First, they ignore you. That was what happened to no-SQL probably three or four years ago. I think a couple of years ago, it was being ridiculed. Now we've got a bunch of Oracle talks. We've got some products from a bunch of the leading vendors. And we've got a battle in the marketplace. I think it's great. I hope that some of us new insurgents will win. But may the best man win who delivers the best solution to all of you. There's lots of work to do before no-SQL as a sector can win. And before we can get from that 15 or 20% usage to something that's used across all the organizations that have large scale IT needs. So security, there are tons of requirements around security. From encryption of data at risk as it's traveling to integration with Kerberos and LDAP, fine-grained access control. How we do roles and permissions, various certifications, years and years and years of work to do on security. I think each of the vendors may be in a slightly different spot. I know many vendors have put a lot of work into this and made a lot of progress and people deploy systems for which security is an important concern. But we could make it much, much easier for all of you. So that the 80% who wait for something to be fully baked will come on board. Similarly, manageability, integrations, I think the fragmentation and lack of standardization in the market. The skill base is growing rapidly. Find over 50,000 people on LinkedIn with MongoDB somewhere in their profile. 50,000 is still a small portion of all the developers that are out there. A lot of work still to do. I talked about how there's this framework around first, second, third, fourth normal form. There's not the same thing for all these different types of data models and different ways that people have to model data. There's a lot of maturity that still needs to come into the ecosystem for us to get from that 20% adoption level to the 100% adoption level. There are two challenges, by the way, that we face as we do that. We need to make it accessible. We need to do all the things that people will be allowed to use it at the same time that we actually make it better and delight the users, right? Make it easier to do queries, make it possible to query different types of things in new ways. But we should not underestimate the importance of checking all those check boxes so that people are allowed to use the technology in big organizations, right? That's what's held us back and why we're just beginning, I think, to get into organizations like MetLife and Goldman Sachs. So the rules around the usage of new technology matter a lot in the adoption of new technology. This is a snippet of the Locomotive Act of 1861 that was passed in the United Kingdom when people were building these things that were kind of a hybrid between a train and a car, right? Like I mentioned, a big steam engine on wheels and people trying to drive it through town. So they decided that this needed regulation, some things like you couldn't drive it more than five miles an hour. I think you had to have someone walking in front of it and waving a flag to warn people, right? So when you put those limits on the technology, unsurprisingly, it turned out not to be very useful in that regulatory environment. Thankfully, over the coming decades, the regulations loosened up as the technology matured, and we wound up with the automobile. But there are a couple of different directions. I think there's a lot of momentum around NoSQL, and it could turn into something great, right? You look at the Tesla. I think the electric car is going to revolutionize automobiles. I think it will be absolutely the way things look 20 years from now. But these early innovations, you don't know exactly how they're going to turn out, right? Remember the segue and how that was going to revolutionize transportation? So it didn't quite revolutionize it as broadly as maybe was hoped at the time. I think there are a lot of things that go into that. How many of you ever tried riding a segue? Okay, this picture is not me, but this is what happened when I tried riding one. I think customer success is really important to the adoption of these new technologies. If people can use NoSQL databases, they can be productive. They can build great applications that move their organizations forward. They're going to tell their friends about it and their friends are going to want to use it. If people try them and they kind of fall off, as in this picture, they're either not going to talk about it or they're going to talk about it in a negative way, and it's not going to be on the same growth trajectory. So I think the single most important thing for the development of this industry is the success of customers in using the technology. I think that success is a team effort. We need to invest as vendors aggressively in the product, in making it both better and more compliant with all the checkboxes. We need to value user success over short-term monetization. If we don't make the free open source downloads well tested and solid, and we try to say, well, if you want to do something real, you better come to us and pay, then the industry will never take off. We built a bunch of online training. It's been tremendously popular. We made it available for free, and we've had roughly 100,000 people sign up for that online training. I think it's been great since launching that training. The quality of the questions we get back about MongoDB, the number of things that people do that are shooting themselves in the foot has materially diminished. I think it's really important for all of us as vendors to invest in customer success, even if it cannibalizes what could have been a revenue stream around that training. The other thing that I think we need to do is we need to, each of us as vendors, be true to the essence of what we've built, and not get excited about chasing someone else or something else. Understand not just what our product can do, but what our products can do better than anything else out there. We can focus on that and find users that want to do that that are going to be delighted with their experience with the products. Then we need to build an ecosystem to complement the product. There's so much to do. We cannot do it ourselves. We need to make sure that all the vendors out there that users rely on for different pieces of their solution interoperate with our technologies. From the customer side, if I look at the successes and less than successes that I've seen out there in the wild, I think, first of all, using the right tool for the job, and not just bringing in a NoSQL database because it's cool because you want to learn it, but bring it in where it's really going to be impactful for that project, and think strategically about where to start. If this is something that has the potential to have a huge impact on how you build applications over the next five years, start with a win. Start with something that's going to be a huge success, that's going to be visible. If you're a manager, think about the personality of the team and think about who's going to be a good evangelist and advocate for the technology as well as a good implementer. Just in training your team and don't hesitate to ask for help from the vendors. Now, one of the challenges that I think we face in working together as vendors and as users is a history of win-lose negotiations. The enterprise software world, unfortunately, I think for both parties, I think it can look appealing from the vendor side, but in the long term it's not a good thing. When a customer selects a product and deploys on your product, they become captive. Captive customers can become fearful and withdraw from the type of collaborative engagement with a vendor that can make them successful and that can make the product better. The relationships that I love with customers are with the customers who have done great things and want to do more like them. They want to share with us what worked and what didn't work, and they want to partner to figure out how they can have more of that success. Unfortunately, so many customers have been trained over decades by vendors that really the only conversations they should have with us are how can we have the same quantity for a 10% lower unit price. I think one of the things I'm excited about is because we're doing this in an open source approach, the customers have more power. We have to earn customers' business every year. That creates less of that fear, less of that withdrawal. Low prices and high value create that alignment around success that I think will create some true collaboration. So I'm really excited about where the industry is right now. I think that we have an opportunity to transition a major part of the technology stack to open source. I think as we do that, we can try to remake the vendor and client relationship in a much more collaborative way. I think we can reinvent the database industry that it'll look completely different in 10 years than it does today in terms of who are the players, what's the share, what's the business model, how people feel about those vendors. I think we can create an agility and application development that really rejuvenates IT's relationship with the business where all of our colleagues in IT out there can surprise and delight your users by delivering things quickly that they love. So that's why I'm excited about the industry. I'm really excited about the journey that we're all on together. Thank you all for coming. I think I'm out of time. Thank you, Max. Let's not miss the opportunity though to pose a couple of questions. Great. So if anybody has one, just raise your hand. We'll get the mic to you. I can't believe nobody's willing to challenge anything. All right, one over here on your right. So what do the database market look like 10 years from now? I think it'll actually be smaller than it is today. It's a market that's 30 or 40 billion dollars, but I meet too many customers that are unhappy with how much they're paying. So it might be a $20 billion market instead of a 30 or $40 billion market. I think relational will be a bigger part of the market, but not dominant in the way it is today. Relational might be half. If we're successful, I would love no sequel to be 60 or 70% relational 30 or 40, less so maybe the other way around. Found left there. Thank you very much. That was a very good talk. I want to ask you about the security manageability aspects that you talked about. It's been five or so years the NoSQL players started showing up, and companies like us, it's difficult to be in front of a customer to say that, oh, we use a NoSQL, especially if it's a financial institution. So where do you see the security and manageability aspects get mature in two years, three years? What do you think? So I think that there's been a lot of progress even over the last 12 or 18 months, which has led to some of those early adopter wins with some of the financial institutions that I mentioned. And I know that we're working in close collaboration with some of those financial institutions, some government agencies, et cetera, some folks in health care to create not just the ability to build a secure system, but to make it easy and to make it check all the boxes in a natural way that people will be comfortable. So I think you can do it today. I think it should be easy in, I would say, probably about a two-year time frame. OK, we have another question on the left. And we're going to take advantage of this little extra time to just do a swap of machine. OK, I appreciate you being here today and sharing with us what's going on in the world right now. I've been around in the consulting role for quite a while, and I've always run into people who hired me to come in and help them, but didn't want to implement the plan because it meant that they had to change the way they did things. The biggest thing I'm finding out with new technology is resistance from people who don't want to learn anything new, they're happy the way things are, but they don't want to rock the boat. This is what I see is going to be the biggest obstacle to the adoption of new technologies. Absolutely, I think people come in a variety of flavors, and some are really excited to try the newest thing just because it's the newest. And then there are some who will use the newest thing if there's a demonstrable benefit to it. And then there are others that will use it only once it's really safe, and there are some who even once it's really safe won't want to use it. And so all we can do is create that benefit, lower those barriers, make sure that people hear about the successes that they're having, and the market will shift over time. I do think it shifts faster now than it did a couple of decades ago, and I think sometimes you benefit for people choosing things for the wrong reasons as well when people think that this is going to help me get a new job, then they're excited to learn it whether it's useful or not. So it cuts both ways, but mostly it will slow us down. I agree. OK. We're going to have to cut things short there, and I apologize to the other hands that are raised. Max, thanks very much for joining us. Really appreciate it. Thank you.