MongoDB, Inc. (MDB) Earnings Call Transcript & Summary

Good afternoon, or good morning, or good evening, depending on where you're tuning in. Thanks for joining us. Today is the first day of our Annual User Conference, MongoDB.live. We're doing it remotely this time, again, given circumstances, but look forward to the event returning. We believe it's really a great opportunity to remind you and remind our community about where we are heading. And so our goal today is really to inform you to talk about our market, to talk about our strategy and to share some of our product road map with you. We want to make sure to provide multiple perspectives to you all, not just from the executive team, but also from customers, from partners and from third parties. So just a quick look at the agenda. Here is the agenda that we have for the day. Sahir, our Chief Product Officer, is going to start us off. After Sahir, Mark Porter, our CTO, is going to talk. Then Dev is going to host and moderate a customer panel that will have participants from Software AG, Current and Shutterfly. From there, we're going to hear from Steve O'Grady, who's the Founder of RedMonk, which is a research firm focused on developers. And then you will hear a little bit about our partnership with Alibaba. And then lastly, we'll have time for an exact question-and-answer session with a number of us. I will look forward to that. So please submit your questions throughout the day. We'll try to get to as many of them as we can. Hopefully, you'll bear with any technical difficulties that we have given we're doing all of this remote. [indiscernible] throughout the day to try and mimic what you might have been able to do in a real live user conference is we've got sort of customer vignettes and stories that are sort of interspersed throughout the day under the theory that the more that you can hear directly from customers, the better we think you'll understand the company. It's a really packed schedule. We've tried to jam a lot into a relatively short period of time. So thanks for your patience and enduring our ambition here. Obviously, feels -- take any breaks as you need. The session is being recorded and will be hosted on our website for some time. Again, we are doing this virtually for the first time, so please excuse any technical challenges that we have. And then with that, we'll get started. Before I turn it over to Sahir, though, I wanted to start off with a customer testimonial that has a lot of personal significance to us at MongoDB. [Presentation]

All right. So thank you all for joining. As Michael mentioned, I wanted to spend some time going through some context in terms of what we're seeing in our customer base as well as some context in the sort of challenges we're trying to solve with the evolution of our strategy over the last couple of years. So really wanted to kind of give a little bit of that context before we get into some details from Mark on our technical differentiation and the new capabilities that we're leasing into the platform. So to get started, first and foremost, I don't think this is a controversial statement, but we believe firmly that modern business and competitive advantage is derived heavily and directly from software and how well organizations are at building that software and leveraging their data to empower those digital experiences. Now the challenge we see is that as organizations make this shift to being digital in the way they drive commerce, there are really no barriers to entry. So for example, if you're a local bank, it used to be that you were only competing with organizations perhaps in the same state, the same geography, the same country. But now it's just as easy for a challenger bank from across the world to enter your market and come out with more compelling, easily available capability. We also see that competitive advantage can't be bought. And what we meant by -- what we mean by this is it's not like software is new to most enterprises. We've all been running software for 20, 30, 40 years, in some cases. But in order to create differentiation when software and technology are the interface to your business, we believe that buying a SaaS vendor, using a cloud platform as an infrastructure provider isn't enough. You need to build competency as an organization in creating those differentiated experiences to thrive in the long term. We also see an immense need from our customers and feedback that they need to be able to sustain innovation. It's not good enough to have a flash in the pan, great idea that defines a business. That might be a place to start, but they need to build methodologies and repeatable processes and talent to be able to sustain that over the long term to ultimately succeed. And last but certainly not least, as organizations become digital interfaces to their customers, it's crucial that they become stewards of their customers' data. So things like data security, data privacy are top of mind for almost every organization we speak to as they start to make this transition and lean into technology and software as a differentiator. Now we see that, first and foremost, if you want to deliver a modern customer experience, that is heavily tied and reliant on the underlying data infrastructure. But in fact, that modern application or customer experience has changed drastically over the last decade. It's now normal that customers expect everything to be real time, performant not to be lagged or slow down. Slow is the new down in software in many ways. People expect highly personalized experiences. They expect their providers and their brands to interact with them and show them only the relevant information automatically at the right time. The way organizations and individuals interact with software has fundamentally changed. The canonical way to interface with applications today is mobile. Mobility to both because of its reach and its convenience is becoming the standard interface that organizations interact with their customers. Data privacy is something that organizations have regulations around, requirements around that weren't even around 3 or 4 years ago. So the right to forget, for example, for GDPR and new requirements that didn't exist very recently. We're seeing a need also for smarter applications. And what we mean by this is the ability to combine multiple sources of data, analyze those sources together and not just display dashboards and reports, but actually empower automated decision-making, automated customer experiences off the back of that analytics. And of course, every organization is looking to always improve. The idea of updating your mobile banking application, insurance quote application, whatever it may be, once a quarter, once a year is no longer good enough. So this idea that your teams need to be constantly pushing new capability as soon as it's ready is a crucial requirement for every organization. The challenge is, of course, that for many companies, especially established brands, this is really hard. And if you look at the stats from the analysts, whether it's BCG in this case or others, it's typically 70% to 80% of enterprises that go embark on these digital transformation initiatives, they actually fail because this is a very immense change organizationally and technologically to incur on an organization. Now we certainly see day in, day out, as we talk to many customers, that the hardest part of making this transition to building modern customer experiences, modern applications is really working with the data, wrangling and understanding the context that needs to power those applications buried in the proprietary data that an organization creates and owns. And so in many ways, what we've observed is that the requirements for applications, requirements from the business on applications has fundamentally changed in some pretty profound ways, as I just mentioned. However, the typical underlying data infrastructure in the average enterprise hasn't. And that's fundamentally because the legacy data infrastructure is built around a relational core of systems, rows and columns organized in a certain way. That was formulated 40 years ago with the inception of accounting applications originally on the mainframe. And what we find is this rigid approach to managing data makes experimenting, iterating, providing agile development practices really hard for the average organization. And that's fundamentally because the data structures in these legacy systems clash with the way modern programming languages and modern development practices actually work. And as a simple example, this little chart on the right, not to get too deep on it, is modeling 4 basic objects potentially in a data model. Just the interdependencies between those 4 basic objects is hard to reason about when you're trying to move quickly across an organization. And fundamentally, from an architectural standpoint, the technologies of the past weren't built to support an always-on application that doesn't have performance degradation, that automatically fails over should something go wrong in the infrastructure. They just won't architect it for that horizontal scale and global reach that many applications now have. And this is just a very basic example. I mean, when we go into our customer environments, there are oftentimes special printers that print out 3 or 4 feet wide pieces of paper that have these complex rows and table diagrams with energy relationship diagrams pasted on the wall just so they can get a glimpse of it in totality to start to rationalize the changes that need to happen at any given time. And this is fundamentally what I think slows almost every organization down with traditional development approaches. And we see this in our customer base. I chose 1 example. This happens to be an insurance company here in New England in the United States. And they had a heavy initiative to modernize their business insurance practice. And this was a top-to-bottom initiative. It wasn't just a data problem. So they first started with changing processes. They moved from traditional waterfall development processes that would ship a version of code once a year to agile development, moving things more iteratively, getting code out faster. They moved to new architectures. They moved from traditional bundled monolithic architectures they had built up for decades to this idea of micro services, more modular components of the application with independent teams moving more quickly. And they changed their deployment process. They moved to what's called continuous delivery. So as their developers build new capability, they could just as easily automate the deployment of that to their test environment into their production environments. And all of these were good changes. There were foundational changes to the way they think about software. However, what they found was no matter how many pieces of the process they slow -- sped up and got rid of, fundamentally, it was the change to that legacy data model back in the relational database system that was the piece that held them back. And so our -- one of our key constituents in this organization we embarked on this project years ago basically was we implemented all of these things, but it still took us days or weeks to ultimately get a change out to our customer base. And so the business is saying, "I don't care how much you spent on agile and micro services and continuous delivery and all these things. If the end result isn't getting there because of the data problem, it doesn't really matter to the end driver for all of this investment." And so that organization and the insurance company went embarked -- and embarked on a set of changes that we see is quite typical. They said, "All right. Well, there are certain things that, that database, that data technology that we've had at the core can't solve. So let's start surrounding it with newer technologies. Let's choose some NoSQL data stores around the edges to try to deal with those shortcomings." So they added a key value store for some metadata. They added some graph traversal databases to be able to understand relationships between different policies, for example, in their customer base. And what they found is as they bolted on caching technologies, key [indiscernible], all these different niche technologies, none of these was fundamentally able to replace the core problem. So they effectively became a BAND-AID. It was more infrastructure, more technology under the covers of this application that was trying to keep up and meet with those modern requirements. And then that imposed an even more challenging problem of keeping data in sync. So they had a separate set of technology and tools that they needed to add ETL vendors, in their case, that manage shuttling of data from the core transactional system, legacy system and the surrounding new kind of niche NoSQL technologies that they had built around the edges. And this -- typical of what we see in a lot of the NoSQL players is they're adjunct to the core problem being solved by the application because of that niche characteristic that they have in terms of what they can support, not being able to support transactions, not be able to be the core of the application. But as we dug deeper, we talked to more customers, we found that the problem is even much broader than the core database itself. And what we found is that almost every application, not even consumer applications that we use day in, day out, but even internal applications, core back-office systems that empower employee productivity, they all have a requirement for human-readable, relevancy-based search. And what organizations have to do is, yet again, stand up a separate technology and integrate the data from their core to that separate technology, typically Elasticsearch or Solr in most of the environments we see. And as we zoom out, what we see is every hour, every individual, every $1 spent on maintaining another one of these boxes, another one of these BAND-AIDs is fundamentally an hour, a person or $1 spent less on innovation, driving the actual application and that competitive differentiation that everyone is being pulled to embark on up above. But the problem doesn't stop there. Like I mentioned, mobility, modern web interfaces are highly agile, highly responsive to be able to give that great experience. Well, that requires a separate set of technologies. There are technologies on Apple phones, technology on Android phones, for example, that are used to have locally persistent data. So you can have a great user experience on your mobile phone, but at the same time, that imposes more integration work. So custom APIs, push notification code, message cues, all of this to deal with edge data effectively, mobility, IoT sensor data and how that integrates in a bespoke way back to the cloud, back to the core systems that the customers are managing. Again, more time on plumbing as opposed to innovation. And of course, we're seeing the same thing happening in the analytical space. Increasingly, we're seeing organizations want to empower those smarter applications or even just report operationally and provide operational analytics across multiple sources of data across this architecture. And most of the technologies, if not all the technologies that power the application, provide no analytical capabilities. So organizations are forced to stand up a data warehouse or some other technology just to enable real-time operational analytics on what's happening in their business. So if we zoom out, what ends up happening in most organizations is we end up with this sprawl, this spaghetti architecture. This is actually probably -- we had 1 customer tell us, this is probably too pretty, too organized, but it's a conceptual diagram. Mark and I were on a call with a CTO of one of our largest customers recently. We were walking them through this, and he put a Zoom background up and the Zoom background was his immensely complicated AWS data architecture for a new application they had built. So this is very real and something we see growing as a problem for architects, for CTOs, for CIOs in the organizations we deal with. And there are any number of different technology players that fit in these boxes. And in some organizations, even MongoDB, starts off as one of those boxes. But this challenge, this architectural spaghetti fundamentally, in our experience, creates a very fragmented developer experience. What it means is that every development team needs to now rationalize and reason about multiple APIs, multiple query languages, multiple technologies and their capabilities just to enable those modern requirements I talked about upfront. It gives the organization less predictability. So they have multiple operational paradigms, multiple security surfaces to have to reason about. And that creates just fundamental complexity and cost in the organization. It leads to unnecessary data integration. It's -- of course, there are going to be multiple data systems in a large organization, but what we see is this creates unnecessary duplication where data has moved from system to system. Multiple copies are created. Master data management becomes a challenge just because you need the capabilities of these 10 different tools to enable an application in the modern era. And so fundamentally, as we step back, we view this as a tax on innovation. Now every organization is trying to compete for development talent, compete with the best resources and designers and everything to be able to build great differentiated experiences. And they take all those people, all that talent and they have them deal with plumbing in this fragmented experience as opposed to differentiating themselves. And that's really the problem that we've been focusing on solving. And so as we looked across the thousands of customers we speak to every day, we did find organizations and we worked with organizations that don't have that problem, that are ahead of the curve, that are on the bleeding edge. And we sort of identified 4 key guidelines or principles, tenets, what have you, that was distinct in the way they thought about their technology selection, the vendors they work with and the architecture they ultimately build. First and foremost, they were obsessed with developer productivity. They knew that roughly 50%, if not more, of this comp side talent every year graduating from computer science schools goes to 4 or 5 major tech companies. So if they're going to be able to compete in that market, every developer they bring on, every DevOps engineer they bring on, every designer they bring on has to be extremely proficient and extremely productive and can't just scale linearly with the size of the requirements coming in from the business. Second, they focus heavily on elegant and repeatable architectures. So every application doesn't have a different blueprint, that doesn't have a different set of technologies so that they can bring on a consolidation of skills and get leverage in their organization as they get smarter and stronger with a core set of technologies that drive the business. They make sure security and data privacy controls are baked into the architecture and are at the front-end of the development process and are core to the systems as opposed to a science project that requires analysis and tons of extra security personnel after the [ fact ]. It has to be build foundationally in the way they think about their application development. And finally, the most advanced organizations look at multi-cloud not as a burden or something to be afraid of that they've got to manage coming down the pipe from business leaders. They view it as a core technological advantage. They see the differentiation happening in the public cloud and don't want to be hindered by being locked into 1 single provider. They want the flexibility to take their core IP, their data but tie it to the differentiation of services and plethora of kind of differentiation and innovation happening in the public cloud. And so these principles, that's what informs, frankly, our development at MongoDB. And so the last few years, many of you have seen us sort of really expand our portfolio, add a lot of core capabilities, integrate it and around the database. It's fundamentally focused on removing that tax, that architectural spaghetti, that application data complexity so that organizations can move more quickly and focus in on core differentiation. So when we go out to the market today, we really focus in on this idea that we're the first application data platform. And what we mean is we're not just solving only a database problem. That's the core of every application. But we solve the broader application data architecture problem. So organizations can have that simplicity, can accelerate that development for any workload no matter what they're trying to build. Now to dig in a little bit here, and Mark will go into much more detail, but I want to give at a high level an overview here, how we do this, it starts fundamentally with the data model that we chose, that our founders chose when they started the company and the technology over 12 years ago. And that is the document model. The idea that the traditional rows and tables of a relational system that's pervasive and legacy computing didn't scale to modern application requirements is -- and that choice is foundational to what drives the company today because the document model thinks fundamentally in objects. And if you follow kind of computer science over the last 20 years, object-oriented programming languages have become the norm. So the idea of being able to naturally think about business objects in your code and then persist that naturally down to objects and documents in the database removes an immense amount of cognitive load, overhead, extra reasoning that goes into common development. And so that's the foundation of everything we think about at Mongo is how do we build on top of that flexibility offered by this model. The second point, which is a little bit more nuanced, is the document model is quite broad. And so we realized, this is 7, 8 years ago, that the document model, because of what we're seeing in our customer base, could actually be a super set of other data models. So managing basic key value data for maybe IoT or time series data and financial services is natural in the document model. It's a subset. Relationships are easy to model and the hierarchy that documents create. Graph traversals are easy. Geospatial data is easy. So we had a strong foundation to add use case after use case after use case. The next big piece was when we look at our fragmented user experience was how do we actually unify the developer experience? Because what we're seeing, especially in the public cloud, is a plethora of choice. Every developer and every organization has access to dozens and dozens of different technologies today. And what we're seeing here is that, that creates complexity, as I mentioned above. So we knew that if we were going to add capability, we had to match that capability with a unified and elegant interface for developers to interact. They have 1 technology and repeatable sort of knowledge that they can use over and over again. After the [indiscernible] of the data model and the query language, we started expanding to a wider spectrum of use cases. And first and foremost, we doubled down on strong guarantees, on consistency of the data. And so many of you know, a few years ago, we released multi-document asset transactions. And this is about data guarantees in the database. Why this is crucial? This is crucial because if we didn't want to be another BAND-AID or another ancillary system, we know we needed transactional guarantees to be able to replace the core of an application. So the reason why organizations choose MongoDB to get not only developer agility but to fully modernize traditional systems, this could be back-end payment systems, core banking systems, insurance pricing systems, this requires us capability. And we're one of the first, if not the only modern technology to bring this forward into the new era. So that was really a big step forward in 3 years of major investment to get there. Next, we tackled the search problem. We recognized that managing a dedicated search engine was perhaps in many organizations, and we're seeing that in our customer base now with Atlas Search, as they're coming in, that's actually more complicated than the core database in some environments when they have petabytes of search data that they want to empower. And so we knew we could do better, and so we integrated that into the database experience. So the developer feels like it's a core part of the experience, but they're not operating a separate system. And they can actually run unified queries across their operational data and their search queries for the application to be even more powerful. On the mobile side, we acquired a technology here for that mobile persistence for unifying all the different plethora of platforms we see on mobile devices. In many ways, Realm did what -- for mobile developers do what MongoDB had done for back-end developers. It was create this much more natural experience. And what we did is we integrated that mobile database with a novel sync protocol back to the cloud, back to our core database. So that organizations don't have to deal with bespoke integration work, bespoke plumbing. We can handle variable connections. We can handle off-line experiences and manage all that data conflict resolution integration for customers very easily. We heavily invested in real-time analytics. So both through workload isolation, so you could run analytical queries on the database while not disrupting the core operations of that application. That was one of our first steps in the distributed architecture. But then we added things like native visualization. Because what we saw was people wanted graphs, charts empowering not just a dashboard, but the actual live application experience that internal or external customers are looking at. And we've expanded that to broader analytics with Atlas Data Lake. So the ability to federate and combine analytical queries perhaps with data that even originated outside of MongoDB, that's stored in S3, for example, on Amazon, and being able to combine and transform that data and either operationalize it or merge it together for broader queries for bigger understanding of what's happening in the business. Now all of that capability I walked through, the document model, the breadth that provides, all these different areas we've simplified into an elegant architecture, that would frankly be irrelevant if we didn't provide the resilience, the scale and the security at the foundation of that architecture. And so everything at MongoDB from the early days through today and the latest innovation were rolled out on the Atlas side is about distributing data. It's about making sure that we leverage the best of cloud native architecture for availability, for performance, for cost, but also that we can -- so we can meet the demands of global applications. So that if you need to keep data in Canada for your Canadian customers, Germany for your German customer base and Sydney for your Australian customers, we make that super easy. You're not standing up multiple databases. It's just something the platform automatically manages for you. We also invested heavily in industry-leading encryption and security controls. So organizations today unfortunately have to make a trade-off. They have this immense desire to drive innovation by leveraging cloud data platforms, application data platforms like Atlas, like other cloud data companies. But the problem is they are giving up control of their data to a third party. And it's not only 1 third party. If you're using a SaaS service, for example, or a SaaS cloud database or cloud application, you're not only dealing with 1 third party, you're potentially dealing with multiple. You're dealing with the underlying infrastructure cloud provider, the data center provider, the networking provider. There may be multiple levels of control there. So organizations were then saying, "Okay, I want to leverage the best of what the cloud offers, but I can't because I've got regulatory reasons or other reasons to control the most sensitive PII or personal health information. And so we give customers the ability to not have to make that trade-off. And so we enable things like client-side field-level encryption. So organizations could control the keys down to a very granular level for an individual -- for an individual customer and maintain that control no matter where they run the database, whether it be with MongoDB and Atlas or self-managing on a third-party cloud provider. And they can delete that definitively without the worry that, that data has leaked somewhere across multiple spans of control. And finally, we're a clear leader in multi-cloud. We invested early and heavily in not only building on 3 cloud providers, but also providing global reach. And I think as of today, we're roughly just over 81 global regions, the most available public database as a service on the planet, but most importantly, the ability to connect those clouds. So we're seeing organizations spin up cloud databases that span multiple major cloud providers, whether it be to migrate a database from 1 provider to another, to span data to -- from 1 provider to another to get availability in a single geography, a variety of different use cases. Certainly, we believe this is an important tailwind for customer value that we are well ahead of the market on and will be ever more important as we move into the future. And so if I step back, the developer experience fragmentation, the complex operational and security model, the unnecessary data duplication I talked about earlier, these are the foundational problems that we aim to solve today, in 2021 and beyond, as we start to really expand our strategy into becoming this application data platform more broadly than even today. And we do that by providing a unified developer experience, an architecture that's repeatable and easy to reason about for operations and security, that provides automated and transparent data movement. So you don't need other technologies just to manage the correct storage and performance profiles for these use cases and ultimately reduces the amount of data duplication required across an organization. And some of our most advanced customers are following those key principles I mentioned earlier by leveraging this platform. So I mentioned one of our large insurance customers earlier. They finally closed that last mile gap on delivery and started getting code out in hours instead of days or weeks by moving to MongoDB for the core of their systems. We work with a challenger bank. I believe this one's out of Canada. And they actually empower unified search, analytics and core transactional systems all in MongoDB. And the reason that's so important for them is they've got a relatively small team comparatively to the large organizations that they're trying to disrupt. So every ounce of speed they can get out of consolidating that architecture is crucial to them because they just can't hire at the volume of some of the larger incumbents. We work with one of the largest government agencies in the U.K. and making sure we can secure citizen data by allowing them to delete keys if they need to delete a particular citizen's information while leveraging the best of the public cloud platforms. And finally, we work with one of the largest health care providers, if not the largest in the U.S. in multi-cloud. They started first by leveraging Atlas on Azure and GCP, independent workloads, independent business units. Now what we're seeing is that they are running databases that span those providers, where their operational data is on Azure, but they're extending real-time replicas to GCP for running machine learning algorithms. A quick story as well. Mark and I were on the phone with the CTO of asset management at a major investment bank. He was focused on a project, I believe it was somewhere around 35 or 40 individuals from operations, security, networking, database team, that was looking at spanning a database across Sydney, the Eastern U.S. and Switzerland, across 3 cloud providers. And that was going to be a multi-week project, just to proof-of-concept that with that many people. And by showing them how easily we could stand that up with a couple of clicks in the UI or just an API call, his statement to us was he just took that to -- from a 35-person project to a 2-person project to stand that up and test before lunch. So I think we're in the early days of customers really seeing the power of that just given where they are in their multi-cloud journey, but we're really excited about how we can partner with organizations on that journey. And so as we look to the use cases across the environments we work with, whether it's product catalogs, customer 360 view, transactional systems, recommendation engines, we are fundamentally building an application data platform for any use case that gives developers that unified experience no matter where they want to run. And that's the vision and the focus of the company today and definitely what you'll see us continuing on in the coming years as we invest even more. So with that being said, I believe the next step is to have another customer story of one of the great examples of a company using this. And then from there, we'll go into Mark's session where Mark will go a little more deeply into some of the concepts that I introduced. [Presentation]

Hey, everybody. My name is Mark Porter. Welcome today. It's great to see you, and thanks for your time. I would love to remind all of you that you can queue up questions for the Q&A sessions by just typing them into the Q&A box you see on your window. So Sahir told you about how our products give value to customers. I'm trying to get the -- there we go. Sahir told you about how our products give value to customers. I'm going to tell you about what our technical advantages are in delivering those products. But first, I think it's important for you to understand some of the history of data and how it's evolved. And we'll start a little bit with my own personal evolution. Finally, I'll close by telling you about today's exciting product announcements. So my personal intro is I live data, asset transactions and uptime my entire career as a developer, operator and customer on-premises and in all 3 clouds. To pay for Caltech, I worked with education systems, space systems and microchip systems, all of which had massive amounts of different types of data. In the 1980s and 1990s, I worked on Oracle 5, 6, 7 and 8 and Oracle RAC. And for those of you who use it, I hope you were delighted. And if you didn't like it, I'm sorry. Oracle RAC is the backbone of Oracle's high-performance, expensive and proprietary Exadata machines. After a decade of retirement, I came back as a CTO of News Corp, working on a mass student data system. And I got to use MongoDB. It was literally, even in 2011, the only platform that had the functionality and the scale we needed. Next was AWS where I was the General Manager and Development Leader of Amazon RDS, Aurora and the Database Migration Service, which has migrated over 300,000 legacy databases such as Oracle and SQL Server into AWS. However, I ultimately became disillusioned by the restrictions of relational technology despite being in it for 30 years and a number of other barriers to innovation, and I decided to move on. As a result of the experience up until this date, I feel that the fundamental innovation was and is impossible in these legacy databases. It's all about incremental change with no ability to rethink the fundamental architectural changes made decades ago, and I'll dig into that a little bit. I then joined Grab as CTO, helping Southeast Asia with millions of rides, meals and payments every day with over 1,500 databases in our infrastructure. And even some of those databases were MongoDB. In 2019, I joined MongoDB on the Board, and I quickly realized that I could have the impact on data at MongoDB that I had always wanted. And I asked Dev if I could be his CTO. He agreed, which brings us up to today. Now you may wonder why this story matters. You might think it's controversial for me, who's been a core member of the relational technology community for decades, to come to MongoDB. On the contrary, I intend to show you that today -- I intend to show you today that it's the next logical step for both me and for the industry. Now in those 35 years, there is 1 trend I could always count on. I'll let you look at that slide for a second. And that trend was that data is growing exponentially and that growth is actually accelerating. Here, you see the amount of corporate data in the world over the last 30 years with a logarithmic virtual access. The graph represents over 1 million times growth. And here's the kicker. The vast majority of that data, maybe 70% or 80%, depending on who you talk to, is not row and column data, but a heterogeneous data mixed with row and column data. The amount of data that is being created is amazing, manufacturing, financial, time series, traditional. This means that customers need databases that can access and process all of their data together for every workload they have. In fact, as CTO, I've begun to think that data stores that predominantly store rigid row and column data are now the new niche databases. More and more, they're being relegated to specific parts of a customer's data and application estate with most innovation happening instead with more new and modern, flexible databases. This relentless tour of data has created challenges, which creates opportunities. All of that data needs to be persisted, stored, backed up. And as a tech guy, with every order of magnitude of data growth, back-end technology has to change fundamentally, and I've lived through all of those changes. But I want to take you back in a time machine to 1970 when things were a little bit different. Before 1970, all data was stored in proprietary systems with proprietary access methods. In 1970, the revolutionary relational data model was published by Ed Codd, and here's his paper. It was a way to manage data and avoid duplication when storage was wildly expensive and horribly slow. It was a way to write applications that talk to their data in similar ways no matter what database they used. And in fact, right after this, the SQL language followed and was released in 1979 first by the company that would become to be known as Oracle. However, it's important to note that, that time was 51 years ago last month. Computer systems have grown literally millions of times more powerful since then. And the constraints of that time are just not the constraints of today. However, it was better than anything that came before. And as you know, relational became the standard for corporate data systems. Over time, storage became faster and cheaper, developers became more expensive, and speed became more important. Not only speed of the computers, that's obvious, the speed of your company. By the turn of the century, relational technology was struggling. I felt it. I was there. Relational systems are strictly defined and hard to change, often requiring rearchitecture and downtime. So central IT departments, maybe at the companies you're at, manage them, frustrating and slowing down developers. In fact, many new college grads at both our company and at companies that we talk to say they have no wish to work on relational systems anymore. Relational skills are becoming the new cobalt. And strict rows and cobalts -- and strict rows and columns, sorry, of former strength are now a weakness. To model all the different data and application needs, engineers have to do contortions with lookup tables and mostly empty columns. This is confusing and inefficient. Also, relational databases just don't scale well. And I say this as a guy who spent his career trying. Relational can scale reads across many machines, but it can't scale writes. They all have to go to a single machine, limiting performance and risking huge outages if that machine crashes or becomes overloaded. My personal experience is that the majority of the outage minutes at Amazon and Grab were caused by the operational complexity and scaling limits of relational databases. Think about that for a minute. All of the things above were bad enough, but it's even worse. The Internet in the early 2000s was taken over, and applications might need to scale by orders of magnitude literally overnight instead of a couple percent per week, which was what the world was used to pre-Internet. So just when the data systems at companies were most stressed, the requirements had gotten more demanding. Another thing happened in the 2000s. And as a CTO, I get to give you a tech slide. This graph showing computer performance from 1995 to 2011. As you can see, the slope of the curve starts flattening out in 2003. And by 2006, it was clear that Moore's Law had officially run out of gas. First, correlational tech couldn't and still can't scale past a single machine. Second, databases machines had stopped getting faster -- fast enough. And third, the Internet happened. So these are the technical and market forces that made the NoSQL movement happen when it did. It's not a mystery. It's not a coincidence. In fact, this was the reason -- sorry, I just realized the slide didn't come up. There is the slide I've been talking about. I'll let you look at it for a second. In fact, this was the reason that Dwight Merriman, Kevin Ryan and Eliot Horowitz founded MongoDB. And you can see on that slide wherein 2003 to 2006, everything slowed down. In 2007, our founders hit these limits. At double click, they needed over 400,000 transactions per second out of their ad-serving databases. It was impossible. They realized that simple technology improvements wouldn't be enough. The time for half measures was over. They had to start over. Realizing that all Internet companies were hitting the same problem, they saw an opportunity. They set out to build the world's best modern general-purpose database, one that would scale without limit and would be the new way for developers to build applications. In fact, MongoDB wasn't alone in seeing that wall. This technology crisis opened the door for disruption by many, many tech companies. And since the database market is huge, many companies signed up for the challenge. So let's talk a little bit about the NoSQL movement. The NoSQL movement use modern tech to solve problems that the legacy technology couldn't. First, it was about inventing new distributed systems architectures for scale and performance. This was essential. When your company succeeds and you see 100% or more growth in a week, nothing is more important than scale and performance. Next, velocity of development became key, and that meant that engineers needed flexible data structures that they can define, deploy and iterate on. Without getting their central IT department and DBAs and approval tickets involved, many corporations still today only change their schema once a quarter, and that just doesn't work. NoSQL databases took on the new challenges presented by the Internet, global databases, global users, every timezone all the time and no maintenance windows allowed. Systems now needed to be designed for always up and everywhere. However, NoSQL databases still lack those critical features. All those capabilities were great, but the new products just weren't enterprise ready. So the blush came off, the NoSQL rose pretty quickly for mission-critical use cases. The NoSQL players hadn't built in the robust query technologies of the relational players, tuned and improved over decades. So enterprises could move their applications. And many NoSQL players took their flexibility too far. Production apps must be able to lock down their data structures and the data in them for control, compliance and regulatory needs. And companies thought naively that they could get away without enterprise security features, encryption, single sign-on, et cetera, unfortunately, contributing to many C-suite executives thinking of NoSQL technologies as toys. Because of all of these things, most NoSQL databases, no matter how innovative or performant, tended and still tend to be niche players. MongoDB took a different approach. This is literally the most important line in my presentation. MongoDB chose a new data model, one that was more versatile than anything that had come before. MongoDB focused on distributed systems tech. Legacy players couldn't do this. They have literally millions of lines of single machine, monolithic, unchangeable code. I know I am personally familiar with the code in Oracle, MySQL and Postgres and look what company's name I have on my badge. MongoDB didn't fool themselves that enterprises would put up with anything other than mission-critical functionality. We just never played that game. This different approach is fundamental to the speed and success of our company, and I'm going to walk you through that approach now. Sahir has already told you about the document model and how it's key to our success. It's what got developers so excited when we launched, and it's completely different than how other databases stored data before the document model. You've heard us tell you before, it's flexible and maps to how developers think in code. First, developers want to have the same thing in their head, their code and their databases. And Steve, from RedMonk will tell you a little bit more about that later today. Next, objects need to be different sometimes, and computers shouldn't make that hard for them. Custom objects in relational mean new columns, new tables, new lookups. In MongoDB, think about this for a minute, the developer just updates their code. The database automatically creates the data structures behind it. No DBA, no operations, no ticket. It turns out that computers like documents, too, not just people. Since all the data that is read together or written together is stored together, documents are faster than following rows and columns across all the tables. And MongoDB's implementation of documents is very mature with over a decade of work. We have bigger documents than some of our competitors, and we have the most flexible documents and operators on those documents of anyone in the industry. And this adds up to the fact, and it is a fact that developers are more productive and engaged when working with modern document technologies. Another area -- we also tell you -- sorry, we also tell you that documents or objects are a superset of all models. Let's tease that apart. MongoDB and documents support data relationships well. 27,000 customers use MongoDB for their applications, and most of those applications need relationships. I thought I was going to come to MongoDB and have people -- customers tell me all the time that their relational apps couldn't move over. Over 200 customer conversations, over 1 year at the company, and I have heard that exactly 0 times. MongoDB also supports key value for those simple applications that just need blindingly fast lookup and storage speed. MongoDB functions perfectly well as a massive distributed key-value store. And for graph use cases like social media, fraud and recommendations, ones I'm very familiar with from Amazon and Grab, you can model documents as nodes and edges and use our GraphQL support to traverse them. In fact, referring back to my earlier comment, since applications are a combination of these multiple data models, why would you stand up multiple data stores for relational, key value, object, graph and geo when you can stand up a single general-purpose data store and do reads and writes and queries across them. The next thing I'd like to talk about is scale. It's another area where MongoDB has distinguished itself from both relational and NoSQL competitors. So first, a quick reminder on how vertical and horizontal scaling work. With traditional vertical scaling systems, whenever you need the ability to do more writes per second, you move to a larger size box. You buy another box or you go to the cloud provider and click on the console. Eventually, you run out of larger size boxes. And as we all know, those boxes cost more and don't benefit from commodity pricing. This is our relational database to scale and why they ran into trouble. Modern systems, on the other hand, scale out horizontally, adding machines one after another without taking downtime, and they're adding commodity machines. This disperses the risk of machine crashes to a subset of the database and, like I said, can be run on commodity hardware. Most other NoSQL implementations of horizontal scaling implement a very narrow solution that makes you make trade-offs in data consistency, even letting the application, believe it or not, read stale or deleted data or they don't let you control the data distribution, which might be essential for performance or data sovereignty like Sahir said. MongoDB's approach is far more mature, offering users full control on data consistency and data placement along with correctly implemented horizontal scaling. Not only that, I want to pound home, MongoDB databases are unique. We have a new definition of run anywhere. You can run us in your own data center or across regions with a single cloud provider for availability, like Sahir talked about, or across the world for local performance and data sovereignty. And you can do it all in whatever cloud providers you choose simultaneously. Nobody else can do that. And we're going to make it better. We believe in letting customers make their data and their database match their needs rather than forcing them to use our data structures and our database. It's complicated to balance GDPR, application speed, cost and complexity. With MongoDB's run anywhere philosophy, customers can get the mix they need. Now the final key pillar of the approach is that enterprises need mission-critical systems, no matter whether they're in retail, banking, trading or any other vertical. To meet these needs, we have a rich query tech on par with relational databases and in many ways better, just check out our aggregation pipelines. They're better than relational. So customers can migrate their legacy apps and write powerful new ones. We also added fully compliant acid transactions because indeed, many workloads need them. For example, moving money from 1 account to another involves the simultaneous update of 2 documents that you can't have failed. And we never lost sight that security is job 1. And so we have full encryption capabilities on-premises in the cloud between clouds, and that was hard, and full integration with every cloud provider security system. And in addition to the basic encryption at rest and in flight, Sahir told you about our unique client side encryption so that your data is encrypted so that the network provider, the cloud provider and even MongoDB can never see it if you don't wish us to. These features are what enterprises are looking for. Now you've seen this picture before. Sahir just showed it to you. And I want to just highlight, because of the limitations of relational, customers have had no choice but deploy these niche databases in front of their relational databases. This is complicated, unreliable and expensive. Our approach is -- allows MongoDB for the majority of use cases to handle the workloads the niche databases were fronting for the relational databases, eliminating that cost and complexity. So, so far, we've talked about the technical advantages of our core database, document model, scalability without compromise and enterprise feature focus. These are formidable technical advantages that will benefit us for years to come. But we haven't stopped there. 2 years ago, we started releasing parts of our next journey, our application data platform. And I'm really excited about it as is Sahir that you heard about. Here's the picture of that general-purpose database again. An application data platform builds everything around that database that customers need to build end-to-end applications in the small teens and micro services that people are building today as well as in large enterprises. Realm, our end-to-end mobile solution, connects right up, allowing language local development without SQL and with automatic server synchronization. Now from a developer point of view, sync is something every app develop -- every app needs. And it's something that's complex enough that developers get it wrong the first couple of times they write it, trust me. Most applications also need search. Another thing developers get wrong. And Sahir told you about how it's just a couple of clicks away. No infrastructure to stand up, no programming to do, just integrate the search box directly into your app. Finally, we've added Atlas Data Lake in Charts, unique to MongoDB. You can join your Data Lake data from your own buckets with your OLTP data. This is an application data platform that lets people write end-to-end applications well. And this is a picture of that architecture. Now I'd like to switch gears and talk about what's next for MongoDB. Today is a big day. It's my first .live at the company, and I'm really excited about it. We're announcing a lot of very exciting things. First, we are announcing an entirely new data type, time series for processing IoT or other streaming data. Time series data, instead of being a separate store, sits right beside your normal MongoDB data. You can join the 2 together. No need to stand up separate time series databases and synchronize all the data back and forth. We're really excited about this, and it's just the beginning of our time series journey. Next, there's a little bit of a nerd feature here. I'm going to give you a warning. We are announcing live recharting. Charting is a feature that distributes data in your MongoDB cluster. And when this data is spread across all those nodes, sometimes indeed, the application changes or your data characteristics change, meaning that the data would be more efficient if it was distributed differently across all of those nodes. This used to be a very manual process with MongoDB. And with this release, now the computer does it for you. You just tell it what -- how you'd like to distribute the data, and it will perform hours or days worth of work to move it all around on your clusters without downtime or application interruption. It's a pretty amazing feature for operators. We're also adding new security controls. One of our key features you've heard about is client-side encryption, where not even the cloud provider or us can see it. We're extending that feature to better integrate with all 3 cloud providers even on multi-cloud clusters, which is crazy complicated. And we're letting you configure your security filters now online without downtime and without going offline at all to respond to new events or new threats or new questions you want to ask. And this is all how we put security first without interrupting customer applications. Next, we've recently announced that we are FedRAMP-ready, and we're launching our new initiative called Atlas for Government. Government agencies can now move forward to take advantage of MongoDB Atlas for their critical workloads. And even better, MongoDB partners can now sell their products that use MongoDB underlying them to the government easier. This announcement positions us better for growth in a very critical vertical worldwide. Sahir talked about Atlas Search. We're enhancing Atlas Search in a pretty powerful way. E-commerce providers can now have custom synonyms, now allowing them to deliver exactly the right answers to their customers regardless of what their dictionary used to say. In addition, with function scoring, applications can promote certain results based on time of day, based on user preferences, location or even allowing e-commerce vendors to sell promotion to their customers in that search results. These 2 features, along with improvements in count and category faceting, kind of nerd features which help you sort on a commerce website, make Atlas Search even more powerful, which are going to allow us to win even more search workloads moving forward. There's so many features. For mobile, it's becoming more and more important for developers to develop cross-platform. That means iOS and Android applications so that they don't have to develop twice. I had to do that at Grab. I hated it. We moved the whole architecture to Dart at grab. And now we're adding support for the 3 most important ones, the game platform unity for game developers, the 2 most popular cross-platform languages, Kotlin and Dart. And we're making Realm sync more selective and customizable in what it syncs so that the data on your phone is smaller, faster and exactly what you need. By continuing to make Realm more ubiquitous, we're bringing our application data platform right out on the glass that's in front of every user, and we're positioning it to become the default mobile database and further drive Atlas adoption. One of the more exciting features for me that we're launching is the ability to run long-running queries, executed against data at a specific point in time. Lots of people can do that, but we can do it on separate analytics nodes that allow customers to have complicated queries that run for hours without affecting transactional systems. Remember, I told you about all those downtime minutes that occur because of relational database limitations. People running analytics workloads on relational databases is a major part of it. And so people have to stand up separate database systems and synchronize the data to not have that happen, not so with MongoDB. Today, we're also announcing MongoDB Charts, our built-in chart solution, now supports Atlas Data Lake. I played with it for the first time today, and it's awesome. Now customers can build real-time charts and embed them in web pages using a mix of database from their transactional databases, their S3 buckets and -- including time series collection and their data lakes. It's very exciting. Next, but absolutely not last is Atlas serverless, one of our most important announcements. With serverless, customers can use MongoDB without having to pick up -- pick a specific machine type or size. Their application connects to [indiscernible] and we'll take care of scaling the database up or down as the workload changes. We're targeting workloads that run in frequently and application frameworks that don't want to know about back-end infrastructure. This is going to significantly accelerate the adoption of Atlas, we believe, because it makes getting started that much easier. It's an exciting road map for us, helping developers a lot to program applications more simply. This is the list of announcements today. With these features, we solidify both the database and the data platform. You've probably already heard from us that we're the most wanted database by developers, four years running, and these features are going to make developers want to use MongoDB even more. We're the leading modern general-purpose database. And our attention to the needs of the enterprise will make it even easier for companies to adopt MongoDB for their mission-critical applications. So I've tried to give you technical background on what has happened in the world that caused MongoDB and NoSQL to start, what decisions we've made and give you our decision framework and what decisions we continue to make and why they make MongoDB so successful. If I have learned anything in the last 35 years, it's that the data march is going to remain relentless, that modern applications have hit the limits of relational technology. We have indeed built the best database in the world for most operational workloads. We're expanding that with the best application data platform. And our announcements today build that out even more. With our application data platform, modern engineering teams can build end-to-end applications faster. And if I could leave 1 takeaway from today with you, it's that single model databases, including relational, are becoming more and more niche in most of the customers I talk to personally, with general-purpose flexible databases like MongoDB becoming the de facto standard for modern enterprises. Thank you so much for your time today. With that, I'm going to turn you back over to the moderator.

I think in that case, that's me. Thanks, Mark. I appreciate the comments and definitely great to have your unique perspective given your longevity in the database market. So thank you for sharing that. Next up is our customer panel. This has been a popular section and segment in past years. We're fortunate to have a diverse panel in terms of industries and in terms of use cases. We'll hear from Software AG, Current and Shutterfly. Just a quick logistics reminder, before that though, we're going to do Q&A at the end, but please submit your questions through the portal, whether they be on product stuff that we discussed with Sahir or Mark or other things as they come up throughout the session. Please submit and send those in. And with that, I'll turn it over to Dev for the customer panel.

Thanks, Michael. It's good to talk to all of you today. It's my privilege to introduce 3 of our customers. You've already seen some video testimonials. But now you'll hear from them -- hear from a few of our customers live. It's my privilege to introduce Dr. Jürgen Krämer, GM of the IoT & Analytics business at Software AG; Trevor Marshall, who's the Chief Technology Officer at Current; and Oleg Joukov, Principal DBA at Shutterfly. Gentlemen, thank you for joining us. So what I'm going to do is just ask each of you to just tell us a little bit about yourself and how your company is using MongoDB. Jürgen, why don't we start with you?

Yes, sure. Also welcome from my side. Pleasure to be on here with you. My name is Jürgen Krämer. As Dev already said, I'm the General Manager of the business unit, IoT & Analytics. So Software AG, let me start there in case you're not familiar with Software AG. We were founded in 1969, headquartered in Germany. So we're 50 years plus old. We have more than 10,000 customers in more than 70 countries around the world. And the IoT & Analytics business is one of our strategic growth areas. And our flagship product in there is called Cumulocity IoT, and we're using MongoDB as the operational store in Cumulocity. So like you can imagine from the name Cumulocity IoT, it's an IoT platform. What does it? It allows us to -- and our customers to connect and manage different types of devices and asset, get the data into our operational store, which is MongoDB. And then we -- yes, we help our customers to analyze the data, turn insights into actions. We also have integration technology in our portfolio. webMethods might be a brand that some of you are familiar with. So we can then combine the IoT data with the other enterprise data in a business and allow our customers to build powerful apps on top. Cumulocity IoT. We sell it directly to customers. Many of them are makers of connected products. And what they do is they build -- they connect these machines and assets to software-enable their business. They want to sell smarter products and higher-value services to their customers and serve their customers also with a better customer experience. Let me give you some examples. So customer -- the customer will be Nordics. They manufacture and operate wind turbines. Or DMG MORI. They have milling machines and other machines in various industries, automotive, aerospace, et cetera. Dürr, they have painting robots. SMC is another customer. They are in the [indiscernible] industrial business. [indiscernible], they have sun blinds. For STW or with STW, we're tracking buses in London, for example. We have Lyrecos or connected Nespresso machines. Gardner Denver, they do industrial compressors. You can see the variety already. But then we also -- besides these direct customers, we also have service providers. What they do, they take Cumulocity, white-label it and then enrich our platform with their own go-to-markets and ecosystems. So they have their own go-to-markets on top, for example, in manufacturing, building whatever logistics they select, right? And this helps us to scale even faster and drive platform adoption. And examples here are, for example, Deutsche Telekom, Cloud of Things, is a white-label Cumulocity. Same with NTT in Japan or Telstra in Australia or Startup in Singapore. And also industrial players like Siemens and [indiscernible] or Stanley Black & Decker white-label our platform. Because it might be interesting to you, we are offering managed services for MongoDB, right? So we are offering this for our customers. And some customers are even operating the platform on their own.

Jürgen, thank you for that. Next, why don't we go to Trevor? Trevor, why don't you give a little bit of background on yourself and Current?

Thanks, Dev. Thanks for inviting me here. Current is a financial technology company based here in New York. We started in 2015. And actually, we've been working with MongoDB pretty much the whole way through. We've gone through a lot of different iterations of our product throughout the years. But most recently, for the last couple of years, we've been building banking services with our partner banks. We have over 3 million customers here in the U.S. And yes, MongoDB is actually a really fundamental part of the service we deliver. We keep our system of record hosted in a horizontally scalable, charted Atlas cluster that I'd be happy to talk more about. But thanks for having me.

Great. Thank you, Trevor. And Oleg?

Yes. Hey, Dev.

Yes. Sorry. Go ahead, Oleg.

Hey, Dev. My name is Oleg Joukov, and I'm a Principal Database Admin with Shutterfly here in Redwood City, California. Shutterfly is a leading retailer and manufacturer of personalized products and communications. We use MongoDB for all aspects of our applications, including our main e-commerce website where it [indiscernible] the back end for some of the microservices. Also, we use MongoDB as a back-end for a set of our manufacturing platforms. One of our sub-brands, Tiny Prints, is using MongoDB as primarily a ordering system database. So we can say that MongoDB is in the backbone pretty much of our database set here at Shutterfly. Our clusters range from hundreds of megabytes to 130 terabytes in size. And we have, I believe, a few hundreds of them across all our production environments.

Great. Thank you, Oleg. So the first question I'm going to ask is -- for all of you is, which is an obvious follow-up question, I think, for the audience would be, why did you actually choose MongoDB? With all the options and available alternatives out in the marketplace, what was the reason why you chose MongoDB? Trevor, maybe we'll start with you?

Yes, absolutely. As Mark mentioned in the last segment, which was great and also some really exciting stuff that I'm looking forward to using myself, it's -- like the developer flexibility is pretty much unmatched across the ecosystem. And it's something that we were able to -- even in a highly structured industry that we operate, which is finance, you can encode a ton of flexibility into your document structures and ultimately the types of features we can offer. It's really hard to make the right decisions for data modeling upfront as a use case evolves, and then it becomes extremely painful to make migrations in different types of persistence layers. So we've been able to really lean heavily into that flexibility, and it's something that allows us to release new features really quickly.

Great. Jürgen?

Sure. Yes. So there are basically -- yes. Thank you. Sure. There are basically 2 reasons. On the one hand side, number one, it's the scalability and distributed nature. And number two is the flexible data model. Let me maybe elaborate a bit on the first one, so the scalability and distributed nature, and why this is so important for IoT. IoT devices in many use cases are, by nature, very broadly distributed, even geographically distributed, right? And some of our customers, we see actually more and more customers are deploying millions and millions of devices. So these early days of IoT where most of the companies try to figure out whether something is in, in that hype around IoT, these are over, right? So now the business cases are understood. It's clear that there is value. And what we see is now really mission-critical deployment and massive rollouts. We have companies like a multinational company that manufactures escalators, moving walks. And they are moving 1 billion people per day, right, around the globe. And they now roll out a fleet of more than 1 million elevators in the next 3 years on Cumulocity. Or a medical and clinical equipment company in the U.S. They have equipment like hospital beds. They are rolling out 1.2 million and connecting 1.2 million assets over the next 3 years. Or a company in Liechtenstein that develops, manufactures products for the construction and building industry, they are rolling out 9 million connected devices. So you see what's happening there, right? And the fact that MongoDB was built for scale, that's something that was very, very important for us. And then in IoT, we have distributed architectures. We have the cloud, yes, but there's also an edge. And many edge use case -- or you need edge to deal with high-volume data in many low latency use cases. So where you need to analyze the data close to the data sources. And we're using MongoDB in the cloud and at the edge. So there is no different configurate -- there is no different database used in the cloud. It's the same APIs in the cloud and at the edge. So we can develop an application once and deploy it seamlessly in the cloud and at the edge. And with 5G, and you're aware of that trend, this will even further accelerate the adoption of edge platforms. And now the second point I mentioned was the data model, right? So in IoT, you have the heterogeneity of devices, protocols and use cases. Each customer, different devices, different use cases. And these devices, they send data with different payload to the platform, right? We can now try to normalize all that incoming data and force the customers to stick to your format. That's difficult. And we didn't want to do that. We want to make it easy and fast for our customers to write apps with our platform, on top of our platform, develop these apps. And MongoDB is giving us that flexibility in terms of the data model. And that makes it then easier for our customers to get started and to see value out of the IoT projects.

Great. Thank you. So I'm going to ask the next question of Oleg. Part of your architecture was migrating microservices from a relational database to MongoDB. This is something that investors are very interested to try and understand how much of the relational database market is really applicable for MongoDB as a potential opportunity. Can you tell us what was the catalyst for you to start this project and how it went?

Well, our general guideline is to move from on-premise environment into the cloud. And MongoDB Atlas is one of the solutions that we are using and we're planning to use in the future as well. And last year for this particular project, we took a look at our entire e-commerce stack that was using Oracle as a back end for pretty much everything. And well, the application part has been split into multiple microservices. We decided to use to use dedicated back ends for most of those microservices, and we found that it not necessarily has to be Oracle [ with its price ] in the RDBMS model, whereas we can use NoSQL solution. And when we're looking at NoSQL solutions, we always consider MongoDB at the top of the list because of its maturity, flexibility, high availability feature that people just mentioned as well. So one of the examples I can probably give is that we had a system that was serving our media store, where in the database, we would store pointers to the media files that we would eventually store in S3 in AWS. This part was historically served by Oracle Database. But in this case, I believe that MongoDB and NoSQL of MongoDB in particular would be much better choice because you gain also its flexibility, high availability, scalability because we have like 100,000 users sometimes here in the system. So we migrated this part of the application into microservices, and we created a dedicated MongoDB cluster just to serve this part of the application. And eventually, it turned out to be a great solution for us to mention. It's highly available. It is flexible. It is very responsive. And our business is highly seasonal. We have like 70% of our income into 1 quarter during the whole this year. With MongoDB Atlas, we were able to scale this particular part of application painlessly for this season and then downgrade it after the high season is over, having significant cost reduction.

Great. Thank you for that. So Trevor, you've obviously been also a big user of Atlas. And in fact, now you're an early adopter of Atlas Search. For a financial services company using MongoDB as a system of record, that's also something that investors have been really interested in understanding how that works. Maybe you can talk a little bit about your experience using Atlas and what made you consider Search because I believe you're using Elastic before and why you decided to consolidate your application Search functionality onto MongoDB.

Yes, absolutely. I guess a couple of things on Atlas, and like as Mark mentioned, horizontal scaling is really hard. It's hard to execute. And the fact that once you get kind of set up in a position where you've thought through the document structure that you do have a button, MongoDB Atlas gives you that button. And it's whenever you need more, you just you hit the button. And that's like an absolute dream, and it's been something that we've been using for years. And we use Mongo kind of across the stack. We have sort of that system of record. And the flexibility that's required there is we introduced different document types that help feed balances. And so that might be if we're integrating with a new -- like cash deposits -- like a new type of integration, new type of payment, new type of credit that might exist in the customer ledger, we can tie and make the decision about the necessary logic and data that needs to be stored on that document. And we can make those decisions over time. So it's allowed us to be super flexible with the types of partners we work with, which is really important for the type of value we can deliver. On the searching side, it covers a component of our app where we have peer-to-peer payment functionality. And we were sort of in the state -- synchronizing multiple states of basically indexing your searchable data. There's a real art and science to getting that right. It's something that's pretty difficult, notoriously difficult to maintain. And when you have the ability to just apply a search index very natively on top of your store, it's just 10 less things my team has to think about. And since we're a small team, that's like a huge prioritization element. And so that's been a big driver for us. We can kind of -- it's a set and forget. And just recently, I had to change some of the logic -- or my team had to change some of the logic for search. And we go in, we've got our search query. We filter some things out. We add an include statement. And that's kind of the end of that. We don't have to think about, okay, well, what is our change stream that we have to synchronize to an Elastic cluster for this purpose. So it simplifies our workflows massively.

Great. Thank you for that. Jürgen, you are -- obviously, with IoT, IoTs lend itself to time series. I believe you've been aware about our time series announcement. And just wondering how you think about time series for your business. And you obviously have a business where you have to deal with customers on the edge as well as other places that you've gone with -- you're not using Atlas today just given your business model. Can you talk a little bit about your experience there as well?

Sure. So let's start with the time series. In IoT, time series is quite natural for it, right? If you have a sensor like a temperature sensor that gives you a reading every minute, it produces a time series, right? So being able to efficiently analyze time series, index time series is quite valuable. So that's why we're very much interested in the new time series functionality in Mongo because it will help us to serve our customers better with faster analytics so they can get also faster value out of the platform and also a better user experience. Maybe let me give you a customer example where this is relevant. We have a customer in the wind farm area, Nordex. I mentioned the name already. One of the world's largest wind turbine manufacturers, and they have a distributed architecture. So they want to be able to manage critical operation on a wind turbine level as well as on a whole farm level, right? So they have an edge installed in the wind farms, and then these edges are connected to a cloud platform, where the relevant data is then analyzed and then further aggregated. To give you a feeling of the data volumes there, such a wind turbine, they have 5,000 and more operational parameters, which generate real-time updates. Now you want to analyze that data at the edge as well as in the cloud to look for trends, patterns, anomalies, et cetera. And an example would be to detect the icing of a wind turbine and raise an alarm in the control center. And to give you some more numbers, what that means, the Nordex fleet currently connected to Cumulocity is around 7,000 plus wind turbines. And we ingest 25,000 data points per second into Mongo. That means in a 4-week window, we have 25 terabytes of stored data in Mongo -- in the Mongo cluster. And in terms of energy, just to give the audience here a feeling, that's more than 16.5 gigawatts of energy being connected to the platform. That's enough energy for nearly 12 million homes and 15 -- more than 15 nuclear plants would generate, right, just to put that into context.

Great. Thank you. Oleg, you're obviously the principal DBA at Shutterfly. Most investors maybe naively think organizations don't necessarily need DBA since Atlas is a managed service. Since Shutterfly is using Atlas, can you explain how -- you're a big fan of Atlas. Can you explain your role vis-a-vis Atlas and how that works?

Yes, sure. Well, analyst, as you say, eliminates the part of working with hardware in OAS infrastructure. However, you still need people skilled with application, database integration, with application tuning and all other aspects of database maintenance and support. Again, it really decreases the need for a system maintenance and support. However, the database part is still there. So this is where your database admins may come handy.

Great. And I guess a general question for everyone. Obviously, serverless is a new theme now with databases. I'm just wondering, what's your approach to serverless? Have you started thinking about how you may -- obviously, we're in a preview mode, but have you thought about like how serverless potentially may change the use of MongoDB in your environment? Maybe, Trevor, we'll start with you.

Sure. I think there's -- sort of the underpinning concept of serverless is the ability to not think too deeply about the required scale and to predict your traffic. And that's something that is sort of embedded within -- across our entire stack. Like a lot of our services are hosted on Kubernetes, which has really good scaling kind of built in, where you not think too deeply about it, you do need to pay attention. I think for -- I think the use case around like infrequent operations, like example for us might be something like a statement generation, where you've got a PDF that needs to be displayed in a certain amount of time, that type of traffic bursts because people are up -- we have U.S.-based customers that burst during the day, that burst potentially around end of months, things like that, that's a pretty good use case for us for serverless.

Great. Anyone else? Have any points of view on serverless, Oleg or Jürgen?

Not much to add -- sorry, go ahead, Oleg.

Sure. I think one of the features would be the ability for development and application teams to easily pick up a new environment in -- where you're going to have to deal with any extensive planning or other things. You can just easily start up a new cluster if you need one and start using it and even close it as soon as you don't need it anymore. This will make a development workflow very flexible.

Great. Well, I think that's enough time for questions. I want to thank our panel for their time and obviously their support of MongoDB. It's very much appreciated. And what I'll do now is hand it back to Mike.

Great. Thanks, Dave. Appreciate it, and thanks to Oleg, Jürgen and Trevor for sharing their perspectives and for their partnership. We really appreciate it. If you have paid any attention, and the only thing about MongoDB, you know that we're all about the developer, and the developer's at the heart of what we do, and focusing on increasing their impact and productivity. We wanted to find a way to bring that perspective to this discussion, and so we reached out to Steve O'Grady, who's the founder at RedMonk. Steve was among the very early proponents of this idea that the developers were sort of increasingly important and a critical sort of lynchpin in the IT ecosystem. And in fact, he actually published a book back in 2013 entitled The New Kingmakers. RedMonk, his firm, is an industry analyst firm. And they evaluate tech trends, particularly from the perspective of the developer. And so with that, I'll turn it over to Steve. Steve, thanks for joining us.

Awesome. Thank you so much for the introduction. Can everybody hear me? We're good to go. I will assume that somebody will tell me if you can't. So as stated, I'm Steve O'Grady. I'm the Co-Founder of RedMonk, and Mongo has asked me to talk to all of you about sort of what developers want from a data platform, right? And inherent in that question is an assertion, and the assertion is that developers are sort of fundamental to that process. And we'll go through a little bit why. So as mentioned, we have just a little bit about me and sort of where I come from, my background. I was a systems integrator many, many years ago before founding RedMonk. So I ran around and did enterprise implementations of sort of all kinds of software, from databases to enterprise portals and CRM systems and all that. And one of the things that was sort of obvious to me sort of even at that time was that the sort of the typical coverage and the typical analysis that I had read and consumed as an analyst was very sort of dismissive of folks at the bottom of the food chain, the practitioners, right? And as we'll discuss in just a minute, that was not -- it didn't make sense to me sort of as time went along. So when we got together and founded RedMonk sort of way back when in '02, the idea was, all right, why don't we sort of look at who are sort of the influencers moving forward, right? So as sort of in addition to this, I've written a couple of books, one of them mentioned, New Kingmakers, which will -- I'll give you the sort of cliff notes version of momentarily. But essentially RedMonk, you can think of essentially as the embodiment, the analyst firm embodiment of that idea, right? The developers are, in fact, the new kingmakers. So this is just a quick time line. When I typically give talks just on the book, it's much longer than this. There's many more moving pieces. But like I said, this is sort of the cliff notes version. But if you sort of think about some of the points on the time line here, right? So Linux was introduced by Linus Torvalds first in 1991. Salesforce was incorporated in 1999. AWS sort of famously generated the cloud industry in 2006. Apple introduced the App Store 2 years later in 2008. And then Coursera, edX and a couple of other educational institutions followed in 2012. Now the obvious question is what does sort of education and App Stores have to do with open source or software as a service or infrastructure as a service, excuse me, let alone databases. And the answer is essentially that they -- all of these things collectively empower the individual and more specific to our cause here, empower developers. So when you sort of think about it in the old days, certainly when I was an application developer sort of way back before the turn of the century, if I wanted to get any software, I had to go talk to somebody and get a license. I had to typically go through procurement channels to get it. I certainly had to do that for hardware. I certainly had to do that for applications. If I wanted to sort of educate myself on a given topic, I would end up having to try to go and beg for some budget to go to a course somewhere. And I certainly didn't have a direct route to the App Store. I don't know what the percentage is at this point. You folks in the financial community probably know the actual number better than I do, but a huge swath of sort of the world's population from a commercial marketplace standpoint. And these days, obviously, that's not the case, right? I can go and get any piece of software I want typically for -- I can download it and use it for free. I can get applications clearly. I have really any kind of storage or compute or other primitive available to me. I do have these direct routes to consumers, and I can educate myself, right? And what this has all sort of led to is an era where developers are empowered individually in ways that they never were previously. And this has led us to sort of the world that we see every day. So what we do every day, sort of at RedMonk is -- I'm sure similar to what many of you do, which is we spend our days talking to other businesses and the developers that work for them or the folks that sell them software. And what we end up seeing sort of time after time after time is a world that looks something like this. So 5, 10 or 20 years, 20 years ago certainly, the world that certainly I came up in was very top-down. It was sort of somebody at the top of an organization, typically a CIO, will make decisions sort of about what gets used. And that then is sort of imposed from the top down to practitioners at the bottom. These days, more often what we see is what developers want to use is what actually gets used. This is essentially the reality in most enterprises today. And importantly, this is true whether they realize it or not, right? Because I can't tell you how many times over the years I've had conversations with CIOs or other folks at the top of the technology org chart in large enterprises who will sort of definitively assert, "Oh, we're not using this piece of open-source software. We're not using this sort of this software-as-a-service application. We're not using this cloud." And uniformly, they're all wrong. And again, there are any number of anecdotes that we could talk about sort of that speak to this. So again, this isn't a theory, right? This isn't just us, sort of RedMonk sort of the small analyst firm saying this. You'll hear this exact sentiment from some of the vendors that are sort of leading the pace in the industry. This is a direct quote from Andy Jassy. I believe it was 2018, re:Invent, speaking about the role of the developers, the foundational and crucial role the developers played in Amazon's own success. And I certainly don't need to tell any of you sort of what that's meant to the world. So developers are important, okay. I think we can probably all agree that that's the case. Hopefully, that's not a terribly controversial opinion in 2021, the way it was. Certainly, when we started the firm in '02, people thought we were insane. But then the question becomes, all right, what do developers want. And any of you who are developers have done the application development at some point in your career, any of you who have spoken to developers, sort of know any personally. What developers want is just to go fast. Programming is sort of at heart in intellectual pursuit. It's about solving problems sort of in creative ways using code. And when you're a developer, what you're looking for is that next sort of dopamine hit, that next problem to solve, which means that you want to go, go, go, you want new problems to solve because that's ultimately sort of what is personally satisfying for you. Now at times, of course, this can lead to sort of the old Facebook maxim, move fast and break things. And that is absolutely sort of not what sort of developers, frankly, or certainly the enterprises they work for want. But that led to sort of what enterprises historically wanted, right? What the enterprise that employed all these developers wanted for most of the technology industry's history was to basically move at this sort of glacial horse and buggy pace because enterprises typically associated speed with risk, not without some foundation, to be fair. And this was the status quo in the industry for essentially, as we discussed, most of the technology industry's history, right? This was just the sort of world that we all inhabited, that we all lived in. It is not, however, the world that we occupy today for a variety of reasons, which would take certainly more time than we have here today to discuss. What enterprises want most today is to move fast. They want to sort of operate at as high a velocity as they can. And this is -- we mentioned reasons. One of them is certainly an essay I'm sure you've all read and are familiar with, Marc Andreessen's sort of famous software is eating the world. But whether or not it's sort of digital sort of start-ups that are threatening businesses, the fact is that even the incumbents themselves are all operating more quickly and therefore applying competitive pressure to each other to do so. So basically, the sort of prize, the important thing at this point is to move more quickly. So this is a conversation -- taken verbatim from a conversation we had with one of our large clients in a different sector but under some of the same competitive pressures. And what we told them is exactly what you just heard, which is what we're hearing from literally every enterprise is that the top priority is velocity. Now importantly, they don't always use that language, right? They won't always say speed or velocity. They might couch it in terms such as digital transformation, right? But when you boil it down, when you actually talk to them, what do they mean about digital information, ultimately, what it comes down to in most cases is speed. Because if we had that conversation about digital transformation 5 or 10 years ago, it would literally mean that. It would literally mean taking these off-line analog businesses and making them digital. Well, all that work has already been done. All of those businesses at this point are, in fact, digital businesses. What they need now is not to transform it but rather to take that digital business and have it operate at the same velocity as a "digital native" would, right? And you see this over and over. For example, you can have the same conversation with technology executives who are prioritizing "agile," right? What is agile? Why is that important to them? Typically, when you boil it down and when you get down to it, the priority is velocity. So ultimately, when we have conversations with enterprises, and this is true across sort of any category, any sector, the priority -- the #1 priority for them is moving more quickly. So as I said, this is part of a conversation we have with our client. And the client came back and said, "Well, okay, look, we understand velocity is important. And certainly, we value it. It's important to us internally, but it can't be everything, right?" We are -- in that case, it was part of us -- 1 of 6 messaging pillars that they were going to take to market. These are the 6 things that we think sort of enterprises care most about. And what sort of interestingly happened is that they call us about 2 months later after having this conversation because we had the conversation and said, "Okay, this is what we're seeing." They respectfully disagreed and we parted ways amicably. And then they come back 2 months later. And they said, "Hey, we'd like to sort of revisit that. Can we have a conversation?" And we said, "Sure, what happened?" And they said, "Well, we went out and talked to our customer advisory board, which is all Fortune 100 organizations from, pick a category, media, finserve, manufacturing, pharma, on and on and on. And they said we were wrong. All of the priorities that we heard from this customer advisory board was velocity. That was far and away the most important thing to everybody that we spoke with, and we're going to reorient effectively all of our messaging around that idea." So if we can accept, even if just for the sake of argument, that the primary goal, the sort of front and center opportunity for most enterprises is speed, the natural question then is, what is it that developers sort of need or want as it were from a data platform, right? So okay, we want to move more quickly. What role does the data platform play in all of this? And more important, obviously, to all the financial analysts on the line listening, well, what does this mean in terms of who the winners and losers will be of that platform? So one of the things that we sort of lead off with when we have these conversations is developers want a data platform that's as modern as their app platform. So this to me is really undercovered, under-understood, if that's a word, sort of fact in this industry, which is essentially, we have remade completely the way that we build and develop applications. As I mentioned, I was an application developer once upon a time, 20 years ago. And the process that developers use today to build, test, produce, remediate their applications looks nothing like it did, literally nothing like it did when I was sort of getting paged in the middle of the night. And virtually all of those improvements and all of those changes have been made, whether that's tools, process, methodology, culture. All of those changes have been made in large part to make the application development side of the house as fast as possible, right, to get changes through, approved, tested and out and remediated if necessary with as much speed as is humanly possible. On the data side of the house, however, the way the companies are typically working with their databases doesn't look all that different, right? That sort of data platform mindset that persists within enterprises today is certainly in sort of need of some updates. And so the question is, well, what kinds of updates. What are they looking for specifically from the platform? So one of the things that we hear over and over and over from developers is that they want a platform that gets out of their way, right? And this has historically been a strength of Mongo, I probably don't need to tell any of you that, in the sense that historically, if you had to work with the relational database, you're building an application, you might have something called an object-relational mapping layer, right? So essentially, that's just a layer that sits in between the application and the data that allows the application to deal with the data in the way that it's designed and the database to do the same. And it's a hassle. It's an additional layer of software that you shouldn't need. And yet, this was kind of the way that things were done because in the olden days, it was -- the answer is a relational database and now what's the question, right? And what developers want is that they want something that's simpler, right? They want this platform to get out of their way. They don't want to, as another example, have to define and fix and cement the schema upfront and sort of deal with this. So when you take platforms like Mongo, which speaks to languages that developers speak in terms of JSON, the document model doesn't permit you or doesn't force you rather to define and set your schema sort of and fix it sort of upfront, allows you to sort of do ad hoc queries and so on. These are the kinds of things that developers are typically looking for from sort of their data platform in the future. Likewise, I cannot tell you how important this is. And certainly, I think the financial results of Mongo's Atlas platform, I think, speak to this in spades. But developers want a data platform that they do not have to operate. I cannot stress this enough. As a developer firm, we spent a lot of time with a practitioner. That led us pretty early along to understand the importance of managed service platforms. And we've been advocating as far back as '08, '09 to database companies of all shapes and sizes that, look, you need managed services operating because this is the way things are going, and turn off, that's where we are today. Developers don't want to have to find some place to stick a database. They don't want to have to back it up. They don't want to have to operate it. They don't want to have to deal with shorting. They don't want to have to deal with availability zones. They want that stuff to be features, right? They want that stuff to be taken care of by the underlying platform so they can focus on what they do best, which is writing application code. And like I said, this is certainly the same opportunity that Mongo perceives with respect to its Atlas product line. And then lastly, this point was made, I believe, in the Q&A or actually just prior to the Q&A, which is the versatility sort of a platform. The technology industry, like a lot of industries, is -- basically has a pendulum that will swing from one end to the other. And back and forth and back and forth it goes. And we've come from an era of general-purpose relational databases that were used to solve every problem. Again, sort of the answer is relational database. Now what is the question. And that proved to be an insufficient approach for many of the workloads that we saw today. So the pendulum swung way in the other direction, and then we had sort of a database for every last tiny sort of workload under the sun. And all of a sudden, you talk to developers, architects, operators even. And they were looking at this and saying, honestly, I missed the days were I only had one database choice to make and one database to operate and one database to sort of learn and manage over time because depending on sort of the nature of the application and what you're trying to do, you might have 2, 3, 4, 5 different data storage mechanisms involved in a single application, which was, let's just say, unwieldy at best. So what we've seen in recent years is sort of a newfound appreciation for platforms that maybe they don't do every last thing, right? Because it is true that jack of all trades is the master of none, but platforms that target a couple of key workloads, right? Key workloads that are adjacent. And this is clearly the direction you've seen Mongo go in recent years in terms of adding support for further back sort of asset transactions to make it a viable transaction platform. More recently, they've gone the time series routes. You've seen them all add support for large-scale data operations in data lake, search and so on. So the net is that if you go out and talk to developers today and you say, "Hey, you want to operate at velocity." What are they looking for? Well, more often than not, they're looking for a database that's easy to use, that is operated by somebody else and that will let them not have to context switch between whether I'm doing a time series, whether I'm operating on a data-lake basis, whether I just want sort of a web front end, a transactional application. Whatever I'm doing I would prefer sort of in a perfect world, a single API, a single platform to handle all that. And as I said, clearly, this is the direction that Mongo's been heading. So as far as predictions moving forward, you are all in the business of predicting that just as I am. And I think it's pretty clear to me sort of which platforms are prepared for this new world that prioritizes velocity. And hopefully, it's clear to all of you as well. So with that, I'm done. And I'm not terribly difficult to find online. I don't believe we have time for Q&A today. But if anybody has questions after the fact, feel free to hunt me down online. And with that, I will pass it back.

Terrific. Thanks, Steve. Thanks for your insight and your perspectives. Next up, we're going to hear on the partnership front from Alibaba. As you will recall, we announced a 5-year partnership with Alibaba back in late 2019. Alibaba, by virtue of that agreement, became the first company to -- in China to offer an official, certified MongoDB-as-a-service offering. In terms of the mechanics, what that effectively means is that MongoDB is licensing -- sorry, that Alibaba is licensing our technology and offers their database service to their customers, and we are in partnership with them. We provide technical support and are also increasingly working with them on the go-to-market motions in China. We're honored to have Feifei Li from Alibaba join us and share his perspectives. Obviously, given the time zone difference, with Feifei being in China, we unfortunately had to prerecord this live, but I think it's a lively conversation and a good one. And Feifei and the whole Alibaba team have really been great partners to us. So with that, let's roll the interview. Well, let's get started. Maybe just you can help everyone, Feifei, understand, introduce yourself a little bit to the audience and say a little bit about your responsibilities at Alibaba to give everyone a little context.

Yes, sure. Hi, folks. My name is Feifei Li. I'm currently Vice President of Alibaba Group. I'm also an ACM Distinguished Scientist. I'm in charge of the database product business unit of Alibaba Cloud Intelligence, which is one of the largest cloud vendors in the business. And I'm also the Director of the Database and Storage Lab for its research branch, which is called the DAMO Academy. I have won multiple awards from IEEE and ACM for my contribution to the database and large-scale data management systems. And I've been associated editor, PC chairs and core committee members for many prestigious journals, conferences, tech meetings and organizations in the field. So I have led the team of Alibaba Cloud to build cloud-native based systems and products at Alibaba Cloud, including our RDS services; cloud-native relational database, PolarDB; cloud-native data warehouse, AnalyticDB; cloud-native multi-model database, Lindorm, among others. I'm a member of many database and big data committees, and I'm really, really excited of coming to today's conversation with Michael of MongoDB.

Terrific. Great. Well, maybe you can tell us a little bit about the usage and popularity of MongoDB in China?

Yes, totally. As a matter of fact, MongoDB is one of the most popular open-source databases in China. And not only it gains its popularity because of its open-source nature, but many enterprises and companies are using the enterprise version of MongoDB as well as the "cloud version" of MongoDB. And it's known as the programmers' favorite database here in China and in the APAC, Asia Pacific, region. It has a wide range of enterprise customers and applications in China, including gaming, social networking, e-commerce, live online, new retail, online education, finance, IoT, government, from all these broad range of segments. And we find many, many enterprise users, developers, DBAs are a big fan of MongoDB. And it is one of our main products on Alibaba Cloud database platform.

Terrific. And then -- so about 1.5 years ago, Alibaba became the first company in the China market to officially offer a certified version of MongoDB and MongoDB delivered as a service. Maybe you can tell people why Alibaba decided to do that.

Well, as I mentioned in the last question, MongoDB has a huge user base from both enterprise users and among developers here in China and in the APAC region. I think it's a mature open-source system with a very mature and active ecology, and it has a rich experience in its market development. And Alibaba Cloud has a long-term dedication and has a very good market share in China and in the entire region. In fact, we are #1 cloud vendor in this market. So we see a great and huge demand for MongoDB, to offer MongoDB as a managed service on Alibaba Cloud database platform, which enables enterprise customers to quickly complete their digital transformation using MongoDB on Alibaba Cloud platform. They manage the burden of MongoDB services, and Alibaba Cloud provides many unique and important features to the end users such as high availability, excellent scalability and on-demand services, among others. And it's winning for both sides, for both Alibaba Cloud and for MongoDB because with the help of MongoDB, we are able to offer the latest and best version of MongoDB, which is one of the most successful enterprise-level database products out there on the market. And for MongoDB, with the help of Alibaba Cloud, MongoDB can penetrate and serve more customers in China and in the APAC region and serve them better as well with our platform and our service team and our engineering team. Would you share your perspective on why MongoDB chose to partner with Alibaba Cloud as we have?

Sure, yes. No, it's very similar logic. We saw incredible amount of developer interest in China. China is one of the largest markets for downloads of MongoDB. And while we have a sales force that sells the Enterprise Advanced products, we couldn't sell Atlas in China, and so we were eager to find a way to offer a cloud product. Alibaba is clearly the leader in cloud services in China. And so it was important for us to be able to partner with the leading cloud services provider. And that really was very valuable and important to us. And Alibaba has extraordinary technical skills. It's not just the go-to-market. The go-to-market is very important for us in terms of making sure that there's a partner who can popularize or capitalize on the popularity of MongoDB. But the technical skill is also incredibly important. The ability to run services at extreme scale, which the China market demands and which Alibaba has proven, really was a great fit and a great compatibility between MongoDB and Alibaba, and we were very eager to form the partnership.

Thank you so much, Michael. And thank you for your trust.

So, Feifei, you're someone who understands databases extremely well. Tell us what your first experience is with MongoDB.

Yes, totally. So I've been a developer for many years myself and now managing the Alibaba Cloud database platform, serving a large number of customer base and managing a large number of engineers. So I will answer this question from 2 perspectives. First being a developer, I think using relational database for my development for many, many years, then I noticed an important and very upbeating change in the type of application we have to deal with. With new type of data coming out, with IoT applications, with big data, application needs the data to be represented in a more flexible and more manageable fashion. But then I noticed the introduction of MongoDB. And I tried MongoDB replacing our relational database for some of the application code I have written. And I noticed that whenever I need flexible schema management and dealing with large amount of data, multi-model type of applications, the amount of code I need for the application layer, when I write that on top of MongoDB versus I write the same application on top of relational database, coding on MongoDB is much more easier. And the performance of the application becomes much easier to deal with as well because of the many features that MongoDB introduced, I guess we will be talking about that in a minute, such as high availability, scalability. The JSON data type is really cool to deal with. It allow a program actually like myself to dramatically simplify the way you interact with the underlying database kernel. For example, it give you flexible schema design. It gave you an ORM layer in order to interact with the object inside the database. And the sharding feature of MongoDB allows you to scale out your application without worrying about currency control, distributed transactions and those very complex tech jargons. And as a user, I interact with many enterprise users that we are serving. And they all praise MongoDB for its flexible data model, especially for dealing with document data types using the JSON data structure. And all in all, to summarize, I think MongoDB is an extremely well-designed database system for the next-generation applications. And with the new features MongoDB has been pushing out to the market, I think it's very good and among the top choices, as far as I can tell, among the developers and users that we have for cloud native -- for building cloud-native, multi-model applications.

Great. Thank you for that. And maybe you can elaborate a little bit more. What do you think are the core advantages of MongoDB versus other technologies?

Yes. I will talk about from -- I think there are many, many advantages that MongoDB has. But I will emphasize from 2 different aspects. One is the agile development that MongoDB allows and enables for the developers from a developer point of view. The object-oriented JSON data model and schema-free model can avoid the pain of changing the table structures, having new data introduced to database late in the development cycle. And it saves more than 60% of the development time due to this flexibility that MongoDB has. And it greatly shorten the release cycle and support rapid business integration and changes. CI/CD, continuous integration/continuous development, has been the norm for today's cloud-native application development. And MongoDB positioned itself really, really well in this market for our developers. That's from the developer perspective. Now from the end user, end customer point of view, I think the cloud native and the flexibility features MongoDB has offered has attracted a huge amount of users and applications. Flexible development architecture is supported such as you can choose between single node or a replica set of a fragmentation cluster where you deploy your application running against a MongoDB database. And it suits the needs of different business scenarios. For example, single DB -- single node for test and development purposes, multi-node replica set ensures its high availability for financial-level services. A lot of our customer from the finance sector actually use the multi-node replica set so that you have highest-level guarantees on RPO and RTO. And fragmentation cluster is free to [ copy ], and it offers elasticity to expand your application as needed, which is critical for building cloud-native applications. You can scale out on the demands of database applications to support business growth. And under this model, it also supports distributed transaction since version 4.2, which is also available on Alibaba Cloud platform, which provides a one-stop solution for scaling out and distributed transaction processing for your application. I think all this unique features and advantages that MongoDB has is the reason why many developers and enterprise users have chosen MongoDB for their application needs.

Great. Thanks for that. That's, I think, a super helpful perspective, Feifei. Maybe you can talk a little bit about how Alibaba and MongoDB are working together to try and maximize the growth and capitalizing the opportunity of a MongoDB managed offering, MongoDB as a service in China?

Yes. We are proud to be the first major cloud vendor that has reached a partnership agreement with MongoDB. And thanks to the formation of the partnership with Mongo, I think we have seen a tremendous growth for MongoDB and managed service with Alibaba Cloud platform. So some of the things we have done in terms of customer development, MongoDB has set up a CPM, which stands for Cloud Partner Manager, team in China, which is responsible for coordinating the resources of MongoDB and expanding customer projects totally with sales and engineering teams of Alibaba Cloud so that it allows us to continuously create value for customers and increase the revenue of MongoDB products. And this, of course, expands to areas outside China, especially in the Asia Pacific region. And we have a huge market presence in the Southeast Asia region and -- among others. And the CPM for MongoDB has greatly enhanced and helped our team to better -- to better serve our customers. Now in terms of -- secondly, in terms of product R&D effort, the technical team of MongoDB and the tech team from the Alibaba Cloud database team communicate regularly to identify key issues and key needs from the customers and work together to produce product features that actually meet and satisfy those customer needs and which enhance MongoDB as a product and especially the MongoDB version on Alibaba Cloud. For example, we introduced engineering features that allow tighter integration of MongoDB and managed service with our DBaaS, Database-as-a-Service platform running on Kubernetes on Alibaba Cloud, which creates a lot of new value for our end customers. Lastly, in terms of ecological construction, several members of Alibaba Cloud database team have played a core role in MongoDB's community development. We have -- of course, working with MongoDB team closely, we have built community with our customers, with our developers here in China. For example, we organized MongoDB meet-up, Technology Salon and annual summit for many years to share MongoDB technology innovation and best practice topics and customer success stories. With the help of MongoDB team and our own efforts, we have built a web brand and active MongoDB community here in China and in the region. Those 3 aspects summarize how we are working together as a team to maximize and foster the growth of MongoDB service in China and the APAC region.

I think that's right. I think it's been a great initial period so far. So thank you for all that. Maybe I could also ask you to share a little bit of the feedback that you've been given or that you've heard from your sales force about the appeal of a managed MongoDB-as-a-service offering among enterprises in China?

Yes, totally. It's interesting you asked this question. Just looking at the revenue numbers, which I can see here because I'm leading the Alibaba Cloud database team, I know the sales are going really, really well. But on top of the sales numbers, of course, it's important to listen to the feedback from the first-line salesperson. So according to their feedback, I think MongoDB is very, very popular among enterprise customers, especially in certain segments such as in the gaming and online education sectors, in the IoT sectors, in the finance sectors, among others. And it has huge advantages due to the features we have just mentioned such as the convenient and agile development, the flexible schema support, the multi-model data types, the cloud-native features with high availability and scalability, among others. And it's been widely used in business scenarios such as operations, gaming, online education platform. And in the latest effort, we see great demand and huge customer needs from the IoT sectors such as mobile industry, from both manufacturing side and also from the -- when they produce the car, when the car is running on the road, when you need to manage those data in real time, I see a great demand for MongoDB as well. So in summary, I see great potential. We already tapped into the potential already. We see great success with MongoDB so far. And I'm super optimistic about the future of MongoDB and our partnership between MongoDB and Alibaba Cloud.

Great. Terrific. Thank you.

Michael, so MongoDB is a global company, and it's one of the leading global database company. Can you share MongoDB's investment plan for China's growing market?

Sure, yes. No, I'm glad you asked. So as you mentioned, thanks to the partnership with Alibaba, we've made some pretty significant changes to how we approach go-to-market in China. In the past, we had a team that was really focused on selling Enterprise Advanced to enterprises in China. But given the strong early results we've had so far with Alibaba's managed offering, we've decided to diversify this team, and we've added this Cloud Partner Manager role that you mentioned earlier, which is really focused on selling and helping Alibaba sell managed MongoDB. They work closely, as you know, with the Alibaba sales force. They provide enablement and support to make sure the teams are sort of effectively coordinating and that the value proposition of Alibaba's managed MongoDB offering is made clear to potential new customers. Obviously, it's early, but I think both of us have been really encouraged with the results. I know we have. And also, really importantly, the collaboration between the 2 companies continues to be very strong and only get better. So it's early, but we're very optimistic about the market and what we can accomplish given the incredible market opportunity that the 2 of us have.

Likewise. I share exactly the same thing. I'm super excited about the partnership. I really, really -- I'm looking forward to the next phase of our partnership.

Likewise. Well, I know we're out of time here, but Feifei, thank you for your leadership personally. It's been great to get to know you over these couple of years. Thank you, Alibaba, for everything you've done and including participating in this session. And I look very much forward to when we can do this in person again. But thanks for everything.

Well, thank you, Michael. You've been a very, very good business partner and a very close friend of mine. So thank you for everything you've done, and I look forward to meeting you in person in Shanghai. I will extend my invitation again. We will make sure you have a wonderful trip with the rest of the Mongo team, whoever you want to bring here. I really, really look forward to that.

Yes. And I look forward to seeing you again, and hopefully, we can do that soon. Thanks again.

Yes. See you. Thank you. Bye-bye.

Take care.

Take care.

Okay. Now I'll transition for me back to me. So it's great to hear from Feifei though. And as I mentioned, they've really been terrific partners. So next up is our Q&A. Just so we're clear on how the mechanics of that will work, we want to get to as many questions as possible, so please continue to submit those using the portal. We've received questions throughout the afternoon, but there's still time, so please do submit those. Brian Denyeau from ICR has been monitoring them, and he'll sort of act as our moderator for the questions. He'll read them as well as who they come from. And Dave and Mark and Sahir and I will all be on the line in order to answer for them. But before we dive into those, we'll give you a little bit more time to submit questions. We want to play one last video so you can hear from one more customer. [Presentation]

Great. Thanks, Michael. And we'll start our first -- I think I'll start the Q&A now. And we'll take our first question from Raimo Lenschow at Barclays. You announced a long list of new product announcements earlier today. Which one is the most exciting for you as a team?

I may ask the team to respond. So maybe I'll start with Sahir.

I think it's tough to ask a Chief Product Officer to choose which is the favorite announcement. But I will say -- we talked about the individual announcements when Mark went through kind of the value proposition for customers. But what I think is exciting for us as a company is a combination of the serverless consumption model; the versioned API that allows customers to non-disruptively make database changes to the application; and then third, I would say resharding. Because those 3 crucial components together give us a foundation to really move faster with changing the database so they get smarter and more powerful, more automated over time. And so this is more of an internal lens that I'm personally excited about, what that allows us to do for the long term of the architecture and the value we can bring to customers.

Mark, do you want to add to that?

Yes. I've been thinking about the question while Sahir answered. I work 4 hats. From my business hat, I feel like it's all about serverless. From my CTO hat, it's all about time series. Time series is so complex and such a technical achievement for the team. The scientist in me loves charts on Data Lake and the ability to do analysis on data anywhere, in any data store you have with one pane of glass. And then I got to tell you the engineer in me has been so frustrated with my inability to develop on Android that Dart makes me very, very excited. So I can now cross-develop on Dart on both iOS and Android. So I guess that's 4 favorite children.

And Michael, do you have a favorite?

I'll give a shout-out to FedRAMP just for something. I mean I agree with everything that Sahir and Mark said, but I'll give a little shout-out to the FedRAMP piece.

Great. I think I am similar to Sahir. I mean one of the things -- one of the announcements I really like is live resharding. It really just puts an exclamation point of the fact that MongoDB is so far ahead of the market in terms of data distribution and scale. I mean it's just not even close. The second thing I would say kind of aligned to what Sahir said was we're -- what we're really trying to do is make the database get out of a developer's way. We're just trying to make it easy for developers to use a database when they need it without having the -- all the cumbersome and tedious task of how to work around a database coming to their world and the more we do that, the more we make the development experience amazing and the more people want to use MongoDB as their back-end data store. So that's why I'm super excited about the announcements. Brian?

Great. Thanks, Dev. We'll take our next question from Jason Ader at William Blair. It feels like the database market is getting more fragmented versus less. How do you think -- what do you think will be the catalyst for greater consolidation in this market over time?

Yes. When I joined MongoDB, there was no clear winner in the old term of the NoSQL or the modern database space. There were a lot of horses in the running. I think nearly 7 years later, it's become clear that we are, by far, the largest and the fastest-growing modern database and the most popular modern database in the world. I think when that happens, customers start getting more and more comfortable making bets on a single platform. In the past, you have the bozo issue where customers didn't want to look like a bozo by picking on the wrong technology. So they'd actually be skittish about products they want to really bet on what particular new technology. Now with almost 27,000 customers, the developer mindshare that we have around the world, obviously our financial performance, MongoDB looks actually like a safe choice. It's -- no one's going to start questioning you why MongoDB especially when we have people using us for such a wide variety of use cases across different industries and geographies. MongoDB becomes an easier choice for people to make, and we're seeing that in our customer base as we continue to expand inside the environment. So that being said, I also think customers are recognizing that it can't have a net new database for every net new use case. You heard that from some of our customers on the panel today, and that it makes sense to start consolidating use cases onto one platform. I'm not suggesting that there'll be one, uber data platform that does everything that there was in the '80s. But the fact in terms of how developers want to build applications for both today and tomorrow, we think that we are an obvious choice.

Great. Thanks, Dev. We'll take our next question from Brad Reback in Stifel. Mark, this one is for you. Can you talk about why Oracle hasn't been able to address this market? And what do you think has held them back technically and culturally from moving to a next-generation platform?

I worked at Oracle for 13 years, and there's a lot of truly brilliant people there. But I will just tell you right off the bat that the thing that is hurting them right now is their culture. They are not customer-obsessed. There are smart people there, please know that, but they are not customer-obsessed. Every customer they come into ends up feeling awkward or even downright scared to work with them. The other thing that's wrong there is that they are wed to their 3 million line monolith. And by the way, it was 3 million lines when I stopped working on it in 1996. I don't know what it is now. And they're wed. They can't break it out into different products, and yet that monolith has so many legacy ways of thinking in that they just can't. Take their recent JSON launch, which we are flattered by, frankly. We are not even vaguely threatened by it. We know they need to have JSON. Do you know what's under their JSON product? It's a relational database that they've tried to shoehorn JSON on top of them. And so I just don't think they can get out of their own way, frankly, either technically or culturally.

Great. Thanks, Mark. That's helpful. Moving to your next question from Steve Koenig at SMBC Nikko. He got 2 ones here for you. Just first, any update on the adoption of newer products like Realm and Data Lake? And then with the release today of MongoDB 5.0, does that open up any key new use cases for the platform?

Sahir, why don't you take that one?

Yes. Absolutely. So we've definitely seen an inflection point in adoption of some of the new products that have gotten GA in the last year. Our typical process at MongoDB is to have long previews where we get a lot of customer feedback, get those early developer wins. And I think in the last 6 to 12 months, as we've got into production with those applications, we've certainly seen higher scale. Now in terms of new use cases that we're going after, I definitely think we are expecting and excited to hear from the beta customers we just engaged with on the time series implementation. We do see industrial IoT in particular as a segment of the IoT market that is increasing in importance. And so that's clearly why we invested, and we've got a lot of feedback there. That's one kind of pocket of use cases we expect to see more of. The other is definitely on mobile. MongoDB has been used heavily for mobile as a back-end database, but our investment in Unity with the Unity SDK is a nice match for mobile gaming, which is the subsegment of the gaming market, which is actually the fastest growing as well. So now we provide an end-to-end architecture. So I think those are the 2 -- I think off the top of my head, worth calling out as potential interesting areas for new workloads for us.

And then anyone, update on the adoption of Realm and Data Lake?

Yes, definitely. On the Realm side, I think we've seen real -- a real fit in retail use cases in particular, situations where customers are -- want to have a local individual sitting in a store, managing local inventory but may have a flaky connection, how do they synchronize that globally across multiple franchisees in some situations. So we've seen quite a bit of an uptick in particular in that vertical in those use cases with Realm and the synchronization technology coming out of the GA earlier this year. On the Data Lake side, there's really been 3 key use cases that we've honed in on that are -- seem to really be getting traction. First and foremost is clearly data tiering. So customers, especially some of the time series customers that we're working with, have -- need to keep an immense volume of data accessible but don't want to pay the cost of storing that or in a core operational database system. So the online archive capability which Data Lake powers has been certainly the first I'd call out. The second is more of a data-engineering-oriented use case, where we're seeing customers dump any number of different styles and formats of data into a particular object storage like S3. And so you may have files that are generated for 10 different systems all landing there in sort of an S3 Data Lake. And what we've been able to do is use our query engine to be able to ingest that data, transform it and operationalize it on a continuous basis for customers. And that was one that just sort of organically started happening once we let Data Lake out in the hands of our customers. The third is more of an emerging use case but one that I think is going to be increasingly important for analytical workloads in the future. It's federated query capabilities. And what I mean by that is we're seeing customers combine a single query where they have multiple databases that they're querying at once or a combination of databases and data sitting in an object store where they want one unified result set to be able to merge different data sets together without having to ingest and dump everything together [ in a single way ]. So those are the 3 emerging use cases that we're seeing with ADL, both integrated with the database as well as clearly independent.

Great. Thanks, Sahir. We'll take our next question. Actually, this is -- a few different people have asked about M&A. And specifically, would it make sense for you to acquire some stand-alone NoSQL database companies that have niche use cases? Or just in general, as you look at your -- the future, does larger M&A to accelerate time to market something that the company is considering?

So maybe I'll start, and then I'll ask my team to add on if necessary. We don't have any plans to go acquire a niche NoSQL or other type of database. We think -- and as part of Sahir's presentation, we think it's really important to -- for a developer to have a seamless, unified experience when they're trying to build applications for a wide variety of use cases. So by definition, trying to bolt on some third-party solution onto MongoDB will actually impede the goal that we're trying. There is a possibility that we could use M&A to expand into some adjacent markets that we're not in, that are maybe adjacent to the OLTP database. But again, we're not -- we have no plans to do so there. Historically, what we've done is surgical acquisitions. We've acquired technologies like WireTiger that really helped accelerate broad-based use of MongoDB. We've made acquisitions like mLab, and we've done other things like Realm as well, which expand into new markets. So you'll see us probably do more of those things, but clearly, there's a lot of interesting things going on. One thing I would say is that I think what's clear is that companies like MongoDB proven -- is that best-of-breed vendors can not only be -- do well but be very, very successful in growing to large companies. And we want to be a best-of-breed vendor that offers a wide range of capabilities to customers, and that's our focus and both from an organic front and potentially as part of M&A.

I would maybe just add to the comment and the question in the chat that part of what Mark and Sahir were getting at is this whole concept of document model being a superset is before we introduced time series, you might have said, "Oh, should you go introduce to buy a time series company?" Or before we introduce graph capability, "Should you buy a graph database?" I think it just sort of underscores the point that the beauty of MongoDB and the document model is as the superset of the models -- and there isn't a need to go buy the consolidation argument there. So it doesn't really make sense because we've got the product capability just to do it organically with MongoDB rather than having to try to bolt something else on. And so I think from an understanding and approach perspective, hopefully, that's helpful.

Great. Thanks, Michael. Next question comes from Jack Andrews in Needham. He wants to discuss your move to quarterly release cycles. Has it impacted your internal product teams as well as the ability -- as well as what it means in terms of speaking to customer demand and how you're going to be able to communicate your product road map externally?

I don't -- Mark, do you want to take this one since you're on the engineering team?

I think it's a 2-part question. I will take the first part. And then Sahir, you can take the road map piece. So...

Okay.

Look, the reality is that developers love shipping code. Having the code actually sit there for the last 9 months of the year was just frustrating everybody. So we did have to clean up our internal processes to test better, to do a lot of the stuff better, to automate even more than we'd already automated. But from an engineering point of view, I just got to tell you the engineers are delighted with moving to quarterly releases, and our testing and automation and release teams are as well. Now Sahir, do you want to talk a little bit about the road map impact?

Yes. I think there's a couple of facets to this. And we have a very diverse customer base, as you all know. And so first and foremost, we wanted to make sure we were predictable and that every year, we were shipping and continuing to ship an annual release that have long-term support characteristics because, especially for our on-premises enterprise customer base running in their own data centers, those upgrade cycles are still very conservative and oftentimes take multiple years. So we need to maintain that sort of characteristic of predictability of an annual release. However, on the Atlas side especially, we've been updating capabilities in Atlas on a 3-week cadence for a long time. And many of those customers that are very agile were saying, "We'd love it if you could get core database capabilities out to us sooner or even if it's just for development and for testing environments rather than waiting for this annual release cycle." And so what this approach of having a versioned API with quarterly releases does is it allows us to give customers choice. So if they want the ability to be an early adopter, use a capability as soon as we're ready after testing to ship it, it gives us a much more granular way to get capabilities to market sooner. But at the same time, we can still meet the most conservative, traditional enterprise sort of deployment practices with the LTS structure, long-term support structure, that we have with our big dot-0 releases like 5.0. So we really spent a lot of time thinking through how we meet both needs of the market because what we see is a lot of technologies make customers have a trade-off. Either you're very aggressive and you're getting the latest capabilities as soon as they're ready, or you have to wait a full year and oftentimes a lot of internal testing to get there. We're meeting both of those ends of the spectrum.

Great. Thanks, Sahir. Super helpful. Next, we've got a bunch of questions on serverless. I'm just going to kind of summarize the topics here. Can you talk about your vision for serverless, how you expect it to be adopted by customers? Will it open up new use cases that are not -- really hasn't been used for? And how do you think about the impact serverless will have on the growth of Atlas over time?

Yes. So maybe I'll start. We actually think serverless is incredibly additive to our business. Remember, it's part of our strategy to really get the database to get out of the way of developers. Developers don't have to pre-think what kind of capacity they need on the back end. Literally, they can just point a URL to our database and just go. And so we really want to make the development -- developer experience as easy as possible. The thing that this does in terms of additive use cases is that [ it certainly ] makes spiky workloads or workloads are very intermittent in nature, very attractive to deploy on Atlas, so things you heard -- one of the customers in the panel talked about how dev test workloads become even more attractive on Atlas with the advent of serverless. And you'll see other customers do the same. But it's all about just making MongoDB so much easier to use and Atlas so much easier to use that they don't have to pre-think how much capacity do I need. They don't have to worry about seasonal spikes in their business. All that is taken care for them at the back end. And we think that this will just drive incremental demand to our platform. I don't know Sahir or Mark if you want to add anything more to that.

I think you hit the key points, Dev. I think the only thing I would add is in terms of it being additive, it's all about customer choice, right? There are workloads for which serverless makes a lot of sense, the spiky, the sparse workloads, the -- getting started on development where you don't really know the capacity dynamics of that application. And there are many customer needs for which a dedicated database cluster where you need the isolation, the predictability, the performance guarantees, et cetera, is desired especially in regulated environments or more conservative accounts. And so we view serverless not as sort of a new product alternative to what we haven't dedicated but a step in the continuum of offerings that we give to our customers.

Great. Thanks, Sahir. Maybe the next question, we'll take from Sanjit Singh of Morgan Stanley. Can you -- I lost that one for a second there. How do you square the argument that relational can ever be modernized with the fact the largest software IPO in history uses the relational data model? The Postgres continues to be popular with the development community.

Mark, why don't you take this one since you obviously come with a lot of perspective on this topic?

Yes. So I know that Postgres community well, and it is a wonderful community filled with great people, so no harshening there. However, the problem is that it still has all the limitations of that legacy code base. So look at how they've implemented JSON. And if you just have nothing left to do with your day, google using JSON with Postgres examples. It is one of the most contorted things you will ever see in computer science. And yet they support JSON. So the problem is that they're in this model that they've been in now for 20 years, and they can't move away from it. They can't move forward. Now to that other question that I can't remember -- was about how do I square the circle with the largest applications being written on relational, I'm going to say something a little bit controversial here. You don't want to write the largest applications in the world anymore. You want to write applications which teams write -- maybe 50, 100 developers write; and 50, 100 developers write another application; and 50, 100 developers write another application. I talk to more than one CTO a day. I've talked to over 400 since I got here at 340 days ago. And none of them are building these monolithic applications anymore. In fact, all we ever talk with them about is breaking down the monolith, strangling the monolith and -- strangling and smashing the monolith. So I think the problem is that the paradigm has changed. And so the technologies for addressing that paradigm shift are the modern technologies, not the old ones.

Yes. And I think -- I just want to add. Mark touched on this in his presentation, but whether it's Oracle or Postgres or any other relational database, they still have the same fundamental limitations. They come to basically 3 things. One, developers do not think in rows and columns. As Sahir talked about, an object-oriented programming language, you think about objects. So thinking about decomposing an object into rows and columns is additional cognitive load for a developer. The second biggest issue is that as you add more features and capabilities, your data model gets more complex and more brittle. So that chart that Sahir showed that -- the irony is that as you use it more, the harder it is to innovate, whereas the reverse is really what customers want. They want to innovate more quickly as they get more traction. And the third point is that relational databases are not designed for scale. So you have to figure out all these workarounds to scale your environment. Some people have tried to make relational database stuff less, but they still have real limitations in terms of data distribution, performance and scale. So for those 3 reasons, whether it's wrapped in an Oracle brand or an open-source brand like Postgres, they still have the same fundamental limitations, which is why MongoDB is getting so much popularity because it's just such a different and a much better way to work with data.

And I'll just jump in and say, Dev, apparently, you listened to the presentation. So thank you. That was awesome. And then I will also jump in with -- look at, for example, what Aurora did at Amazon with MySQL and Postgres. They couldn't modify the core database. All they did was put in a different storage engine underneath. And you can look up the blog that says the Amazon Aurora storage engine. So I ran Aurora Postgres. And for 6 years, I tried to modify the Postgres engine, and I was unsuccessful.

Great. Thanks, Mark. Maybe another one from Sanjit at Morgan Stanley. One criticism of the NoSQL movement is that it emphasize consistency to achieve massive availability. They're -- [ contracts and others ] have been looking to bring consistency to the forefront. How does Mongo view this initiative around bringing greater consistency to cloud data stores?

So I assume this is about the consistency of the data. I mean -- or it could be the -- or they're implying the flexibility of the database. I'll assume it's the former, not the latter, but we can answer both questions. MongoDB has a tunable consistency model. So as Oleg talked about for Software AG and their IoT use cases, each individual data point is not that important. It's the trend of data that becomes more important. So you want to capture data very quickly and then eventually, consistent model works well. But for, say, being a source of truth or system of record as current as using MongoDB, you need the transactional guarantees of a strongly consistent system. And so the fact that MongoDB supports both is a great example of how versatile MongoDB is. And then with regards to the schema, we have rules around helping people define how the schema should set up. So flexibility is not like both of blessing and a curse. You really have guardrails to help customers define rules around how they set up the schema so people then can create that data much more easily. I don't know, Sahir or Mark, if you want to add more color.

Sure. I think the criticism around lacking consistency in the NoSQL space or criticism around being a free-for-all around data governance and schema, I think by and large, of the segment of non-relational databases, it has been true. And I think Mongo has been the outlier where, for the last 6 or 7 years, we've invested heavily in bringing forward schema and data governance so that you can have control and enforcement where you want consistency in the data model and typing. And then also, if you think about transactional consistency, asset guarantees, I think it's a little-known fact maybe, but MongoDB has always been strongly consistent with asset guarantees from the get-go and inception of the database. And then 3 years ago, we added multi-documents, so once you're manipulating multiple objects in the system, the transaction capability to do so. And so in many ways, from the inception of the company, we believe that just building an eventually consistent database wasn't going to be enough because we had the ambition to be general purpose and be able to replace the core of many of these kind of mission-critical applications. And that wouldn't be possible today, many years later, if we didn't have a similar thinking around strong consistency guarantees.

Great. Thanks, Sahir. Time for a couple more questions. We'll take the next one from Kash Rangan at Goldman. When a customer decides to stay with the legacy relational database, can you just talk to what the trade-offs that they are making when passing on going with MongoDB? Notwithstanding all of the performance advantages you've outlined throughout this presentation today.

Mark, do you want to take that one?

Yes. So one of the advantages that they -- you actually do get, which I want to acknowledge, is that a lot of people out there know SQL and know how to program against relational databases. We're working very hard as a smaller market share player to change that with our academia programs and our start-up programs and our MongoDB University. So that's really exciting there. However, as I said in my presentation, I was quite surprised when I came here that less and less people out of college have any interest in learning relational databases. So I think the ship is coming over the horizon and it's going to be bad news. Now when you get to the technical side, you're going to be using either open-source technologies or commercial technologies. Let's just assume for the moment that you're not silly enough to use commercial technologies that are costing ridiculous amounts of money. Even on the open-source side of the world, the problem is that you're limited by very low innovation and you're limited by very low ability to bring in other pieces of software in the ecosystem. And you have to start bolting things together. So when you look at what's going on in all of the modern data stores, of which we are one and which we listed a number of others, connectivity and integration has been a -- just a hallmark of the modern data stores since day 1. So once you go down the relational path, you're starting to go at it alone on an awful lot of things with your own developers, with your own technology and with your own integrations. And so it's -- I mean you can do it. There's no doubt about it. There are companies out there doing it. But it's probably not the path that you're not going to regret in 3 to 5 years.

Great. Thanks, Mark. And maybe we'll take our last question from Raimo again at Barclays. If you look at the cloud providers, in particular AWS, they're offering different databases for different use cases. Can you just talk about how far Mongo can go in offering all-in-one experience as an alternative to the approach that AWS is taking?

Yes. So as Mark mentioned and Sahir mentioned, we spent a lot of time talking to customers with 27,000 customers, as you imagine. We have lots of conversation with customers. We have never heard a customer saying, "I want to use a net new database for a net new use case." The incremental tax of learning, supporting, provisioning, querying and backing up all that data and all those different silos, as part of Sahir's pitch, it just becomes, over time, overwhelmingly complex. So customer -- this is part of the -- I think related to the question about fragmentation and defragmentation of the database market. We are clearly hearing from customers that they don't want more than 1 to 2 options for the majority of the use cases. So we think that there will be -- in every enterprise, there'll be a legacy standard, some relational standard, and then there'll be a modern standard. And our goal is to be the modern standard in every enterprise. And then maybe there will be some core cases where they use some niche solution for some esoteric use case. That's the way that -- the way we see the world going. And we think Oracle -- I mean, sorry, Amazon's roots around widest selection at lowest prices. And while it works in e-commerce, it doesn't necessarily work in databases. Customers just don't want to manage and support 17 different database technologies. And so I think that's very easily verifiable when you talk to customers. And that's I think why people are viewing MongoDB such an attractive platform to the point that was mentioned earlier. The document model is a superset model. So it just enables a wide variety of use cases. And we feel like we're really well positioned to continue to be the general purpose, modern standard for enterprises.

So do you mind if I jump in there a little bit, Dev?

Go ahead.

Look, the cloud providers built these beautiful houses. They're made of concrete. They have great power. They have great water. They even have really great security systems that you can hook up to. And these people build them and they're great, and you can live in this house. So you can live in the house down the street. However, no one ever contracts with the contractor to build your china cabinet or your furniture. And that's where best-of-breed comes along. So the reality is the cloud providers build great houses. We live in them with our 27,000 customers. But when customers come to us and they say, "I want the thing that adjusts to my needs, and I want it to be the best-of-breed product for what I need to do," they don't want to get a graph with 30 logos on it and in the middle is something called glue that is a product that the cloud providers had to create to produce their -- to glue their own products together. That's just not okay. That's not what developers want and it's not what enterprises want. And so I know I'm getting a little passionate here, but I've lived both sides of that argument. And the reality is, figure out who you want to build your house and figure out who you want to build your furniture and what -- where you want to put your china, which is your data.

Great. Thanks, Mark. Michael, I'll turn it back to you and Dev for -- to wrap it up.

Yes. No, I think we're right up on time. I just want to thank everyone for spending some time with us this afternoon. Hopefully, the announcements from dot live were helpful and then this incremental session where you got to hear particular focus from Dev and Mark and Sahir on the product side of things, to hear from our customers and understand where the product road map is going. We look forward to talking to you all in several weeks, and I hope you're well between now and then. And at some point, we look forward to doing all these in person. But thanks to everyone from the team and to our customers and everyone else for organizing all this. I really appreciate it.

Thank you.

Thank you, everyone.

Thank you, everybody. Bye.