Good afternoon, or good morning, or evening, depending 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. 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 roadmap 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. 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. 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. You'll hear a little bit about our partnership with Alibaba. Lastly, we'll have time for an exec question and answer session with a number of us, and we'll look forward to that. 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 we have considering we're doing all this remote. Interspersed 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 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, feel free to take any breaks as you need. This 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. 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. Overnight on Friday the 13th, governments decided to close all schools. Kids needed to stay at home. At Sanoma Learning, we immediately felt we needed to do whatever we could do to support schools. On Monday, thousands and thousands of pupils and teachers all logged in at the same time, and the platform just wasn't able to cope with that at all. My boss is calling, his boss is calling, journalists are calling. My youngest daughter shoving this tablet in my face saying, "Dad, I can't work with Bingel. There's something happening." Bingel suddenly has now become part of the nation's critical infrastructure. I needed a plan. I really needed a plan fast. I explained the position Bingel was in. Within minutes, there was this kind of virtual war room with the whole of MongoDB Atlas team. Everybody was sitting together there, thinking of an action plan to make this work. I'm literally talking about hours. We managed to migrate critical components of the platform to database component in less than three days. Once we made the switch to the MongoDB Atlas environment, Bingel was available, performance was rock solid again. It's times like these that you really get to appreciate the difference between a supplier and a partner. We've been breaking records on a daily basis here. In a normal period, we would have seen pupils doing 1.5 million-3 million exercises. We now see close to 12 million exercises day after day after day. Headmasters, schools, teachers, even kids, they're sending these thank you notes. It's very heartwarming. At Sanoma Learning, we aim to make the learning experience a fun and rewarding adventure. Being there together with the teachers and the pupils today in the fight that they are having will create an immensely strong bond and will create a very bright future for all. 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. 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 releasing into the platform. 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. 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. 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. 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. 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. 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 may 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. Last, but certainly not least, as organizations become digital interfaces to their customers, it's crucial that they become stewards of their customers' data. 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. 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. 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 slowed 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, 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 three or four years ago. The right to forget, for example, for GDPR are 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. 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. This idea that your teams need to be constantly pushing new capability as soon as it is ready is a crucial requirement for every organization. The challenge is, of course, that for many companies, especially established brands, this is really hard. If you look at the stats from the analysts, whether it's BCG in this case or others, it's typically 70%-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. In many ways, what we've observed is that the requirements for applications, the 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. 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. What we find is this rigid approach to managing data makes experimenting, iterating, providing agile development practices really hard for the average organization. That's fundamentally because the data structures in these legacy systems clash with the way modern programming languages and modern development practices actually work. As a simple example, this little chart on the right, not to get too deep on it, is modeling four basic objects potentially in a data model, just the interdependencies between those four basic objects is hard to reason about when you're trying to move quickly across an organization. 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 weren't architected for that horizontal scale and global reach that many applications now have. This is just a very basic example. When we go into our customer environments, there are oftentimes special printers that print out three or four feet wide pieces of paper that have these complex rows and table diagrams or 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. This is fundamentally what I think slows almost every organization down with traditional development approaches. We see this in our customer base. I chose one example. This happens to be an insurance company here in New England, in the U.S., and they had a heavy initiative to modernize their business insurance practice. This was a top-to-bottom initiative. It wasn't just a data problem. 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 microservices, more modular components of the application with independent teams moving more quickly. They changed their deployment process. They moved to what's called continuous delivery. As their developers build new capability, they could just as easily automate the deployment of that to their test environment into their production environments. All of these were good changes. They were foundational changes to the way they think about software. However, what they found was no matter how many pieces of the process they 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. One of our key constituents in this organization when 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. The business is saying, "I don't care how much you spent on agile microservices 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 this investment. That organization, that insurance company went and embarked on a set of changes that we see as quite typical. They said, "All right, well, there's certain things that that database, that data technology that we've had at the core can't solve. 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." 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. What they found is as they bolted on caching technologies, key-value stores, all these different niche technologies, none of these was fundamentally able to replace the core problem. 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. They had a separate set of technologies and tools that they needed to add ETL vendors in their case that managed shuttling of data from the core transactional system, legacy system, and the surrounding new niche NoSQL technologies that they had built around the edges. And this is 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 being able to be the core of the application. As we dug deeper, we talked to more customers, we found that the problem is even much broader than the core database itself. 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. 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. As we zoom out, what we see is every hour, every individual, every dollar spent on maintaining another one of these boxes, another one of these Band-Aids, is fundamentally an hour, a person, or a dollar spent less on innovation, driving the actual application and that competitive differentiation that everyone's being pulled to embark on up above. The problem doesn't start 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, technology on Android, for example, that are used to have locally persistent data so you can have a great user experience on your mobile phone. At the same time, that imposes more integration work. Custom APIs, push notification code, message queues, 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. 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. Most of the technologies, if not all the technologies that power the application provide no analytical capabilities. 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. 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 one customer tell us this is probably too pretty and 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 him through this and he put his Zoom background up, and the Zoom background was his immensely complicated AWS data architecture for a new application they had built. This is very real, and something we see growing as a problem for architects, for CTOs, for CIOs in the organizations we deal with. There are any number of different technology players in that fit in these boxes, and in some organizations, even MongoDB starts off as one of those boxes. 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 an organization less predictability. 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. 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 is 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. Fundamentally, as we step back, we view this as a tax on innovation. 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. They take all those people, all that talent, and they have them deal with plumbing and this fragmented experience as opposed to differentiating themselves. That's really the problem that we've been focusing on solving. As we looked across the thousands of customers we speak to every day, we did find organizations, and we work with organizations that don't have that problem, that are ahead of the curve, that are on the bleeding edge. We sort of identified four 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 built. First and foremost, they were obsessed with developer productivity. They knew that roughly 50%, if not more, of this comp sci talent every year graduating from computer science schools goes to four or five major tech companies. 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. 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 built foundationally in the way they think about their application development. 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 pike 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 one 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 innovation happening in the public cloud. These principles, that's what informs, frankly, our development at MongoDB. The last few years, many of you have seen us sort of really expand our portfolio, add a lot of core capabilities integrated 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. When we go out to the market today, we really focus in on this idea that we're the first application data platform. What we mean is we're not just solving only a database problem. That's the core of every application. We solve the broader application data architectural problem so organizations can have that simplicity, can accelerate that development for any workload, no matter what they're trying to build. To dig in a little bit here, Mark will go into much more detail. I wanted 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 in legacy computing didn't scale to modern application requirements, that choice is foundational to what drives the company today. 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. 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. 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. We realized, this is seven, eight years ago, that the document model, because of what we were seeing in our customer base, could actually be a superset of other data models. Managing basic key value data for maybe IoT or time series data and financial services is natural in a document model. It's a subset. Relationships are easy to model in the hierarchy that documents create. Graph traversals are easy. Geospatial data is easy. We had a strong foundation to add use case after use case after use case. The next big piece was when we looked at that fragmented user experience was, how do we actually unify the developer experience? 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. What we're seeing here is that that creates complexity, as I mentioned above. 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, so they have one technology and repeatable sort of knowledge that they could use over and over again. After the foundation of the data model and the query language, we started expanding to a wider spectrum of use cases. First and foremost, we doubled down on strong guarantees on consistency of the data. Many of you know, a few years ago, we released multi-document ACID 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. The reason why organizations choose MongoDB to get not only developer agility but to fully modernize traditional systems, this can be back-end payment systems, core banking systems, insurance pricing systems. This requires this capability, and we're one of the first, if not the only, modern technology to bring this forward into the new era. That was really a big step forward and three 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, where as they're coming in, that's actually more complicated than the core database in some environments where they have petabytes of search data that they want to empower. We knew we could do better, and so we integrated that into the database experience. 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 for mobile developers what MongoDB had done for back-end developers. It was create this much more natural experience. 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 offline experiences and manage all that data conflict resolution integration for customers very easily. We heavily invested in real-time analytics, both through workload isolation, 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. 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. We've expanded that to broader analytics with Atlas Data Lake. 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. All of that capability I walked through, the document model, the breadth it 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. Everything at MongoDB, from the early days through today and the latest innovation we 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 so we can meet the demands of global applications. If you need to keep data in Canada for your Canadian customers, Germany for your German customer base, and Sydney for our 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. 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. The problem is they're giving up control of their data to a third party, and that's not only one 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 one 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. 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." We give customers the ability to not have to make that trade-off. We enable things like client-side field level encryption, so organizations could control the keys down to a very granular level for an individual customer, and maintain that control no matter where they run the database, whether it be with MongoDB, in Atlas, or self-managing on a third-party cloud provider. They can delete that definitively without the worry that data's leaked somewhere across multiple spans of control. Finally, we're a clear leader in multi-cloud. We invested early and heavily in not only building on three cloud providers but also providing global reach. I think as of today, we're roughly just over 81 global regions, the most available public database as a service on the planet. Most importantly, the ability to connect those clouds. We're seeing organizations spin up cloud databases that span multiple major cloud providers, whether it be to migrate a database from one provider to another, to span data from one 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. 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. 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. 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. Some of our most advanced customers are following those key principles I mentioned earlier by leveraging this platform. 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. They actually empower unified search, analytics, and core transactional systems all in MongoDB. 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. 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 their larger incumbents. We work with one of the largest government agencies in the U.K. in 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. Finally, we work with one of the largest healthcare 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're 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 a 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 three cloud providers. That was going to be a multi-week project, just a proof of concept that with that many people. By showing him 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 from a 35-person project to a two person project to stand that up and test before lunch. 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. As we look to the use cases across the environments we work with, whether it's product catalogs, customer 360 degree 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. 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. 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. The Department for Work and Pensions is the largest in the U.K. government. We serve over 20 million citizens. We pay out over EUR 190 billion per year in payments to people who need that support. Universal Credit is the biggest change in the welfare state in the U.K. since the Second World War. It's designed to help people get back into work, but also to help those people who may not be able to work. The biggest effect happened kind of in the middle of March. I urge you at this moment of national emergency to stay at home, protect our NHS, and save lives. The people of this country will rise to that challenge, and we will come through it stronger than ever. We saw massive increase in traffic to the Universal Credit online service, in some cases up to 10 times the amount of traffic we'd experienced before. We had to pivot and adjust our service to make sure that people were paid on time and in full. MongoDB proactively got in touch with us, I think within the first few weeks of COVID, to understand how we were getting on, and whether there was any extra additional support they can provide us. We've been working with MongoDB as our database in Universal Credit since the proof of concept we did back in 2013. We managed to keep our on-time payment rates over 88%, which is pretty phenomenal. MongoDB as a database technology has been able to cope with that all the way through. I became much more interested in Atlas as we scaled, wanting to take away some of that stress of worrying about resilience. Universal Credit are looking to migrate our database services, so we're looking to migrate that to Atlas, which is MongoDB's database as a service. It gives us the agility and speed of delivery, which sometimes you don't get from either something you manage yourself or an alternative database technology. At the moment, we've got 5.5 million citizens claiming their benefits through our service at full scale. There's a certain amount of worry and stress about what happens if that fails, that what you've built up yourself is not quite as robust as you think it is. That's going to have a massive impact on real people. I can be confident in the future that I'm not going to need specialists who understand the intricacies of configuring MongoDB database clusters, because I'll be confident that Atlas has my back on that. Hey, everybody. My name's 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. Dev told you about how our products give value to customers. Dev 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. 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. My personal intro is I've lived data, ACID transactions, and uptime my entire career as a developer, operator, and customer, on premises and in all three 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. 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. 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 Lead 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. 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 till 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 joined Grab as CTO, helping Southeast Asia with millions of rides, meals, and payments every day, with over 1,500 databases in our infrastructure. 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. 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 today that it's the next logical step for both me and for the industry. In those 35 years, there was one trend I could always count on. I'll let you look at that slide for a second. 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 vertical axis. The graph represents over a million times growth. 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 it's 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 torrent 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. 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 E.F. 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 talked to their data in similar ways, no matter what database they used. In fact, right after this, the SQL language followed, and was released in 1979 first by the company that would come to be known as Oracle. 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. 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, but 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 re-architecture and downtime. 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 COBOL. Strict rows and columns, a former strength, are now a weakness. To model all the different data an application needs, engineers have to do contortions with lookup tables and mostly empty columns. This is confusing and inefficient. 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 one minute. All of the things above were bad enough. It's even worse. The internet in the early 2000s was taking over. 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. Just when the data systems at companies were most stressed, the requirements had gotten more demanding. Another thing happened in the 2000s. 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. 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. Third, the internet happened. 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's 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. You can see on that slide where in 2003 to 2006, everything slowed down. In 2007, our Founders hit these limits. At DoubleClick, 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 this 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 tech companies, and since the database market is huge, many companies signed up for the challenge. Let's talk a little bit about the NoSQL movement. The NoSQL movement used 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 one 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 time zone, 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. 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 couldn't move their applications. 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. 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 of 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. 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. 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. It's completely different than how other databases stored data before the document model. Developers want to have the same thing in their head, their code, and their databases. Steve from RedMonk will tell you a little bit more about that later today. 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. 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. 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 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 customers tell me all the time that their relational apps couldn't move over. Over 200 customer conversations over one year at the company, and I have heard that exactly zero times. MongoDB also supports key-value. For those simple applications that just need blindingly fast lookup and storage speeds, MongoDB functions perfectly well as a massive distributed key-value store. 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 could 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. 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. As we all know, those boxes cost more and don't benefit from commodity pricing. This is how relational databases 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. 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. 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. 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 one account to another involves the simultaneous update of two documents that you can't have fail. We never lost sight that security is job one. 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. 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. You've seen this picture before. Sahir just showed it to you. I want to just highlight, because of the limitations of relational, customers have had no choice but to deploy these niche databases in front of their relational databases. This is complicated, unreliable, and expensive. Our approach allows MongoDB, the majority of use cases, to handle the workloads that the niche databases were fronting for the relational databases, eliminating that cost and complexity. 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. We haven't stopped there. Two 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 a 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 teams and microservices 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 needs, and it's something that's complex enough that developers get it wrong the first couple 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 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 and 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. 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 Dot 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 two 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. There's a little bit of a nerd feature here. I'm going to give you a warning. We are announcing live resharding. Sharding 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 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 three cloud providers, even on multi-cloud clusters, which is crazy complicated. 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. 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. 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 two 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. Now we're adding support for the three most important ones, the game platform Unity for game developers, the two most popular cross-platform languages, Kotlin and Dart. 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. 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 charts 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 in 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 a specific machine type or size. Their application connects to Atlas, and we'll take care of scaling the database up or down as the workload changes. We're targeting workloads that run infrequently 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 roadmap 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. 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. If I could leave one 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. 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. 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 three of our customers. You've already seen some video testimonials, but now you'll hear from a few of our customers live. It's my privilege to introduce Dr. Jürgen Krämer, GM of the IoT and 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. 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? Yeah, 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 at Analytics. Software AG, let me start there in case you're not familiar with Software AG. We were founded in 1969, headquartered in Germany. We are 50 years plus old, yeah. We have more than 10,000 customers in more than 70 countries around the world. The IoT Analytics business is one of our strategic growth areas. Our flagship product in there is called Cumulocity IoT, and we're using MongoDB as the operational store in Cumulocity. 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 assets, get the data into our operational store, which is MongoDB, and then we, yeah, 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. 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, yeah, to customers. Many of them are makers of connected products. What they do is, 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. The customer would be Nordex. They manufacture and operate wind turbines. DMG MORI. They have milling machines and other machines in various industries, automotive, air space, et cetera. Dürr, they have painting robots. SMC is another customer. They are in the pneumatics industrial business. Priessl, they have sun blinds. For STW or with STW, we're tracking buses in London, for example. We have Lyreco, so connected Nespresso machines. Gardner Denver, they do industrial compressors. You can see the variety already. 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. They have their own go-to markets on top. For example, in manufacturing, building, whatever logistics they select. This helps us to scale even faster and drive platform adoption. Examples here are, for example, Deutsche Telekom Cloud of Things is a white labeled Cumulocity. Same with NTT in Japan or Telstra in Australia or StarHub in Singapore. Also industrial players like Siemens in MindSphere or Stanley Black & Decker white label our platform. Because it might be interesting to you, we are offering managed services for MongoDB. 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, 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. 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. Yeah, MongoDB is actually a really fundamental part of the service we deliver. We keep our system of record hosted in a horizontally scalable sharded Atlas cluster, that I'd be happy to talk more about. Thanks for having me. Great. Thank you, Trevor. Oleg? Yeah. Hey there. Sorry, go ahead, Oleg. My name is Oleg Joukov, 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 serves as a back end for some of the microservices. 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 our ordering system database. We can say that MongoDB is a backbone pretty much of our database set here at Shutterfly. Our clusters range from 100 of GB to 130 TB in size. We have, I believe, a few hundreds of them across all our production and non-production environments. Great. Thank you, Oleg. The first question I'm going to ask 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 let's start with you. Yeah, 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. 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 you 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. We've been able to really lean heavily into that flexibility, and it's something that allows us to release new features really quickly. Right. Jürgen? Sure. Yeah. Thank you. Sure. There are basically two reasons. On the one hand side, number one, it's the scalability and distributed nature. 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. Some of our customers, we see actually more and more customers are deploying millions and millions of devices. These early days of IoT. Where most of the companies try to figure out whether something's in that hype around IoT, these are over, right. Now the business cases are understood. It's clear that there is value. What we see is now really mission-critical deployment and massive rollouts. We have companies like a multinational company that manufactures escalators and moving walks, and they are moving 1 billion people per day around the globe. They now roll out a fleet of more than 1 million elevators in the next three years on Cumulocity. 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 three years. A company in Liechtenstein that develops, manufactures products for the construction and building industry. They are rolling out 9 million connected devices. You see what's happening there, t he fact that MongoDB was built for scale, that's something that was very important for us. In IoT, we have distributed architectures. We have the cloud, yes, but there's also an edge, and many edge use cases, or you need edge to deal with high-volume data and many low-latency use cases. Where you need to analyze the data close to the data sources. We're using MongoDB in the cloud and at the edge. There is no different database used in the cloud. It's the same APIs in the cloud and at the edge. We can develop an application once and deploy it seamlessly in the cloud and at the edge. With 5G, and you're aware of that trend, this will even further accelerate the adoption of edge platforms. Now, the second point I mentioned was the data model, right? In IoT, you have a 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. You 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. 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 their IoT projects. Great. Thank you. 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 in, to try to 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. Last year, for this particular project, we took a look at our entire e-commerce stack, and that was using Oracle as a back end for pretty much everything. Well, the application part was being split into multiple microservices. We decided to use dedicated back ends for most of those microservices, and we found that it not necessarily has to be Oracle with its price and the advanced model, whereas we can use a NoSQL solution. Looking at available 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. 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 and AWS. This part was historically served by Oracle database, but in this case, I believe that MongoDB and NoSQL, especially MongoDB in particular, would be much better choice, because again, of its flexibility, high availability, scalability, because we have hundreds and thousands users sometimes hitting the system. We migrated this part of the application to microservices, and we created a dedicated MongoDB cluster just to serve this part of the application. Eventually, it turned out to be the great solution for us. Again, 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 annual income into one quarter during holiday season. With MongoDB Atlas, we were able to scale this particular part of the application up painlessly for this season, and then downgraded after that high season is over, having significant cost reduction. Great. Thank you for that. 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 were using Elastic before, and why you decided to consolidate your application search functionality onto MongoDB. Yeah, absolutely. I guess a couple of things on Atlas. As Mark mentioned, horizontal scaling is really hard. It's hard to execute. The fact that once you get 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 hit the button, and that's like an absolute dream, and it's been something I've been using for years. We use Mongo across the stack. We have that system of record, and the flexibility that's required there is we introduce different document types that help feed balances. That might be if we're integrating with a new, like cash deposits, like a new type of integration, a new type of payment, a 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. 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 in the state of 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. 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. Since we're a small team, that's a huge prioritization element. That's been a big driver for us. It's a set and forget. Just recently, I had to change some of the logic, or my team had to change some of the logic for a search, and we go in, we've got our search query, we filter some things out, we add an include statement, and that's 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? It simplifies our workflows massively. Great. Thank you for that. Jürgen, you are obviously with IoT. IoT lends 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 also have a business where you have to deal with customers on the edge as well as other places. You're not using Atlas today just given your business model. Can you talk a little bit about your experience there as well? Sure. Let's start with the time series. In IoT, time series is a quite natural flow, right? If you have a sensor like a temperature sensor that gives you a reading every minute, it produces a time series, right? Being able to efficiently analyze time series, index time series, is quite valuable. That's why we're very much interested in the new time series functionality in MongoDB, 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. They want to be able to manage critical operation on a wind turbine level as well as on a whole farm level, right? 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. An example would be to detect the icing of a wind turbine and raise an alarm in the control center. To give you some more numbers, what that means, the Nordex fleet currently connected to Cumulocity is around 7,000+ wind turbines, and we ingest 25,000 data points per second into Mongo. That means in a four week window, we have 25 TB of stored data in Mongo, in the Mongo cluster. In terms of energy, just to give the audience here a feeling, that's more than 16.5 GW of energy being connected to the platform. That's enough energy for nearly 12 million homes and more than 50 nuclear plants, which would generate, right? Just to put that into context. Great. Thank you. Oleg, you obviously are 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, please explain your role vis-a-vis Atlas and how that works. Yeah, sure. Well, Atlas, as you say, eliminates the part of working with hardware and OS 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 system maintenance and support. However, the database part is still there. This is where your database admins may come handy. Great. 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 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. That's something that is sort of embedded across our entire stack. A lot of our services are hosted on Kubernetes, which has really good scaling kind of built in, where you don't have to think too deeply about it. You do need to pay attention. I think the use case around infrequent operations, like an 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. It bursts potentially around ends 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 it. Sorry. Go ahead, Oleg. Sure. I think one of the features would be the ability for development application teams to easily spin up new environments and where you don't 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 you can close it as soon as you don't need it anymore. This will make a development workflow very flexible. Great. Well, I think that is enough time for questions. I want to thank our panel for their time, and obviously their support of MongoDB. It is very much appreciated. What I will do now is hand it back to Michael. Great. Thanks, Dev. Appreciate it. Thanks to Oleg, Jürgen, and Trevor, for sharing their perspectives, and for their partnership. I really appreciate it. If you have paid any attention and know anything 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 linchpin 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. With that, I'll throw it over to Steve. Steve, thanks for joining us. Awesome. Thank you so much for the introduction. Can everybody hear me? We good to go? I'll assume that somebody will tell me if you can't. As stated, I'm Steve O'Grady. I'm the co-Founder of RedMonk. Mongo's asked me to talk to all of you about sort of what developers want from a data platform, right? Inherent in that question is an assertion, and the assertion is that developers are sort of fundamental to that process. We'll go through a little bit why. As mentioned, 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. 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. One of the things that was sort of obvious to me, sort of even at that time, was that 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? As we'll discuss in just a minute, that didn't make sense to me, sort of as time went along. When we got together and founded RedMonk sort of way back when in 2002, the idea was, all right, why don't we sort of look at who are sort of the influencers moving forward, right? As sort of in addition to this, I've written a couple of books, one of them mentioned, "The New Kingmakers," which I'll give you the sort of a CliffsNotes version of momentarily. Essentially, RedMonk, you can think of essentially as the embodiment, the analyst firm embodiment of that idea, right? That developers are, in fact, the new kingmakers. This is just a quick timeline. 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 CliffsNotes version. If you think about some of the points on the timeline here, right? Linux was introduced by Linus Torvalds first in 1991. Salesforce was incorporated in 1999. AWS famously generated the cloud industry in 2006. Apple introduced the App Store two years later in 2008, and then Coursera, edX, and a couple of other educational institutions followed in 2012. 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? The answer is essentially that all these things collectively empowered the individual, and more specific to our cause here, empowered developers. When you think about it, in the old days, certainly when I was an application developer 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 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. 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 the world's population, from a commercial marketplace standpoint. These days, obviously, that's not the case, right? I can go and get any piece of software I want, typically. 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. What this has all led to is an era where developers are empowered individually in ways that they never were previously. This has led us to the world that we see every day. What we do every day 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. We end up seeing time after time after time is a world that looks something like this. 5, 10 or 20 years ago, certainly, the world that certainly I came up in was very top-down. It was somebody at the top of an organization, typically a CIO, will make decisions about what gets used. That then is 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. Importantly, this is true whether they realize it or not, right. 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 definitively assert, "Oh, we're not using this piece of open source software. We're not using this software as a service application. We're not using this cloud." Uniformly, they're all wrong. Again, there are any number of anecdotes that we could talk about that speak to this. Again, this isn't a theory, right. This isn't just us, RedMonk, the small analyst firm saying this. You hear this exact sentiment from some of the vendors that are leading the pace in the industry. This is a direct quote from Andy Jassy, I believe it's 2018, at re:Invent, speaking about the role of the developers, the foundational and crucial role developers played in Amazon's own success. I certainly don't need to tell any of you what that's meant to the world. 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 2002, people thought we were insane. The question becomes, all right, what do developers want? Any of you who are developers, or have done application development at some point in your career, any of you who have spoken to developers, know any personally, what developers want is to go quick, is to go fast. Programming is at heart an intellectual pursuit. It's about solving problems in creative ways, using code. When you're a developer, what you're looking for is that next dopamine hit, that next problem solved, which means that you want to go, go. You want new problems to solve because that's ultimately what is personally satisfying for you. At times, of course, this can lead to the old Facebook maxim, "Move fast and break things." That is absolutely not what developers frankly, or certainly the enterprises they work for want. That led to 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 glacial, horse and buggy pace. Enterprises typically associated speed with risk. Not without some foundation, to be fair. 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 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 operate at as high velocity as they can. We mentioned reasons. One of them is certainly, and I say, I'm sure you've all read and are familiar with Marc Andreessen's famous software is eating the world. Whether or not it's digital startups 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. Basically, the prize, the important thing at this point is to move more quickly. 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. 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. They won't always say speed or velocity. They might couch it in terms such as digital transformation. When you boil it down, when you actually talk to them, what they mean about digital transformation, ultimately what it comes down to in most cases is speed. If we had that conversation about digital transformation five or 10 years ago, it would literally mean that. It would literally mean taking these offline analog businesses and making them digital. Well, all that work has already been done. All 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 quote, unquote, "digital native" would. You see this over and over. For example, you can have the same conversation with technology executives who are prioritizing, quote, unquote, "agile." Well, what is agile? Why is that important to them? Typically, when you boil it down, when you get down to it, the priority is velocity. Ultimately, when we have conversations with enterprises, and this is true across any category, any sector, the number one priority for them is moving more quickly. As I said, this is part of a conversation we had 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." In that case, it was part of one of six messaging pillars that they were going to take to market. These are the six things that we think enterprises care most about. What interestingly happened was that they called us about two months later after having this conversation, because we had the conversation, said, "Okay, this is what we're seeing." They respectfully disagreed, and we parted ways amicably. Then they come back two months later, and they said, "Hey, we'd like to revisit that. Can we have a conversation?" We said, "Sure. Well, what happened?" 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. 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 our messaging around that idea. If we could accept, even if just for the sake of argument, that the primary goal the front and center opportunity, for most enterprises is speed. The natural question then is, what is it that developers need or want as it were from a data platform? Okay, we want to move more quickly. What role does the data platform play in all of this? 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? One of the things that we lead off with when we have these conversations is developers want a data platform that's as modern as their app platform. This to me is a really under-covered, understood, if that's a word, 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. 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 writing code in the middle of the night. 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. 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 that companies are typically working with their databases doesn't look all that different. That sort of data platform mindset that persists within enterprises today is certainly in need of some updates. 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? 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 a relational database, you're building an application, you might have something called an object relational mapping layer, right? 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. It's a hassle. It's an additional layer of software that you shouldn't need. Yet this was kind of the way that things were done because in the olden days, the answer is a relational database, now what's the question, right? 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 in cement the schema upfront, and sort of deal with this. When you take platforms like a MongoDB, which speaks the 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 then 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 of the future. I cannot tell you how important this is, and certainly, I think the financial results of MongoDB's Atlas platform, I think speak to this in spades. 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. We've been advocating as far back as 2008, 2009, to database companies of all shapes and sizes that, look, you need managed services offerings because this is the way things are going. Sure enough, 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 sharding. 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. Like I said, this is certainly the same opportunity that MongoDB perceives with respect to its Atlas product line. 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, basically has a pendulum that will swing from one end to the other, and back and forth, and back and forth it goes. We've come from an era of general purpose relational databases that were used to solve every problem. Again, it's sort of the answer is relational database, now what is the question? That proved to be an insufficient approach for many of the workloads that we saw today. The pendulum swung way in the other direction, then we had sort of a database for every last tiny sort of workload under the sun. All of a sudden, you talk to developers, architects, operators even, and they were looking at this and saying, "Honestly, I miss the days where 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, or 5 different data storage mechanisms involved in a single application, which was, let's just say, unwieldy at best. 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, the 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 ACID transactions to make it a viable transaction platform. More recently, they've gone the time series routes. You've seen them add support for large scale data operations in Data Lake, Search and so on. 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. As I said, clearly, this is the direction that MongoDB's been heading. As far as predictions moving forward, you are all in the business of predicting that, just as I am. 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. 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. 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 five year partnership with Alibaba back in late 2019. Alibaba, by virtue of that agreement, became the first company in China to offer an official certified MongoDB as a service offering. In terms of mechanics, what that effectively means is that Alibaba's licensing our technology, and offers their database service to their customers. 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 pre-record this live. I think it's a lively conversation and a good one. Feifei and the whole Alibaba team have really been great partners to us. With that, let's roll the interview. Well, let's get started. Maybe just if 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. Yeah, 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. 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 HUE and ACM for my contribution to the database and large-scale data management systems. I've been Associate Editor, PC Chairs, and Core Committee Members for many prestigious journals, conferences, tech meetings, and organizations in the field. I have led the team of Alibaba Cloud to build cloud-native database 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 excited of coming to today's conversation with Michael at MongoDB. Terrific. Great. Maybe if you can tell us a little bit about the usage and popularity of MongoDB in China? Yeah, totally. As a matter of fact, MongoDB is one of the most popular open source databases in China. 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. It's known as the programmer's 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, governments, from all these broad range of segments. We find many enterprise users, developers, DBAs are big fan of MongoDB, and it is one of our main products on Alibaba Cloud Database platform. Terrific. About a year and a half ago, Alibaba became the first company in the China market to officially offer a certified version of MongoDB and MongoDB delivered as a service. Yeah. 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. It's a mature open source system with a very mature and active ecology, and it has a rich experience in its market development. 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 number one cloud vendor in this market. 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 on Alibaba Cloud, provides many unique and important features to the end users, such as high availability, excellent scalability, and on-demand services, among others. It's a winning for both sides, for both Alibaba Cloud and for MongoDB. 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. 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. Yeah, no, it's very similar logic. We saw incredible amount of developer interest in China. China's one of the largest markets for downloads of MongoDB. While we have a sales force that sells the enterprise advanced product, we couldn't sell Atlas in China, so we were eager to find a way to offer a cloud product. Alibaba's clearly the leader in cloud services in China, so it was important for us to be able to partner with the leading cloud services provider. That really was very valuable and important to us. 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. 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. We were very eager to form the partnership. Oh, thank you so much, Michael, and thank you for the intro. Feifei, you're someone who understands databases extremely well. Tell us about your first experience with MongoDB. Totally. 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. I will answer this question from two perspective. First thing, a developer, I've been using relational database for my development for many, many years. I noticed an important and very updating 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. I noticed the introduction of MongoDB, and I try MongoDB replacing relational database for some of the application code I have written. I noticed that whenever I need flexible schema management and dealing with large amount 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. Deployment 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 programmer, actually, like myself, to dramatically simplify the way you interact with the underlying database kernel. For example, it give you flexible schema design. It give you a ORM layer, in order to interact with the object inside the database. The sharding feature of MongoDB allows you to scale out your application without worrying about concurrency control, distributed transactions, and those very complex tech jargons. 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. All in all, to summarize, I think MongoDB is extremely well-designed database system for the next generation applications. 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 user we have for building cloud-native multi-model applications. Great. Thank you for that. Maybe you can elaborate a little bit more. What do you think are the core advantages of MongoDB versus other technologies? I think there are many, many advantages that MongoDB has, but I will emphasize from two 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 your database late in the development cycle, and it saves more than 60% of the development time due to this flexibility that MongoDB has. It greatly shorten the release cycle and support rapid business iteration changes. CI/CD, continuous integration, continuous development, has been the norm for today's cloud-native application development. MongoDB positions itself really, really well in this market for our developers. Now, that's from the developer perspective. From the end user, end customer point of view, I think the cloud native and the flexibility features that MongoDB have offered, have 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 or the fragmentation cluster when you deploy your application running against a MongoDB database. It suits the needs of different business scenarios. For example, single node for test and development purposes. Multi-node replica set ensures high availability for financial-level services. A lot of our customers from the finance sector actually use the multi-node replica set, so that you have highest level guarantees on RPO and RTO. Fragmentation cluster is free to config, 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 your business growth. Under this mode, it also supports distributed transactions, seems very important too, 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 these 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 capitalize on the opportunity of a MongoDB managed offering, MongoDB as a service in China. Yeah. We are proud to be the first major cloud vendor that has reached a partnership agreement with MongoDB. Since the formation of that partnership with MongoDB, I think we have seen tremendous growth for MongoDB and managed service on Alibaba Cloud platform. 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 in MongoDB and expanding customer products jointly with the sales and engineering teams of Alibaba Cloud. That it allows us to continuously create value for customers and increase the revenue of MongoDB products. This, of course, expands to areas outside China, especially in the APAC region, Asia-Pacific region. We have a huge market presence in the Southeast Asia region and among others. The CPM from MongoDB has greatly enhanced and helped our team to better serve our customers. 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 allows 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 values for our end customers. Lastly, in terms of ecological construction, several members of Alibaba Cloud's 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 meetups, 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 vibrant and active MongoDB community here in China and in the APAC region. Those three aspects summarize how we are working together as a team to maximize and foster the growth of MongoDB service in China and in 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. Yeah, totally. It's interesting you ask 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. On top of the sales numbers, of course, it's important to listen to the feedback from the first-line salesperson. 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. 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. It's been widely used in business scenarios such as operations, gaming, online education platform. In the latest effort, we see a great demand and huge customer needs from the IoT sectors, such as mobile industry from both the manufacturing side and also when they produce a 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. In summary, I see great potential, and we already tap into that 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, 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. Yeah, no, I'm glad you asked. 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've had a team that was really focused on selling Enterprise Advance to enterprises in China. 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. Also really importantly, the collaboration between the two companies continues to be very strong, and only get better. It's early, but we're very optimistic about the market and what we can accomplish given the incredible market opportunity that the two of us have. Likewise. I share exactly the same feeling. I'm super excited about the partnership. I'm looking forward to the next phase of our partnership. Yeah. Likewise. Well, I know we're up out of time here, 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 that you've done, including participating in this session. I look very much forward to when we can do this in person again. Thanks for everything. Oh, thank you, Michael. You've been a very good business partner and a very close friend of mine. Thank you for everything you have 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 Mongo team, whoever you want to bring here. I really look forward to that. Yeah. No, I look forward to seeing you again, and hopefully we can do that soon. Thanks again. Yeah. See you again. Thank you. Bye-bye. Take care. Take care. Now I'll transition from me back to me. It was great to hear from Feifei, though, and as I mentioned, they've really been terrific partners. Next up is our Q&A. Just so we're clear on how the mechanics of that will work, we want to get through as many questions as possible, so please continue to submit those using the portal. We've received questions throughout the afternoon. 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. Dev and Mark and Sahir and I will all be online in order to answer for them. 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. The Vaillant Group is a company which are producing heating appliances for hot water and cooling, and also for the heating at the home. We are in a family company. We also want to drive digital transformation. All our components, all our infrastructure is in the cloud. All teams are cross-functional. We are all working in an agile way. We try to always be state-of-the-art and to give our developers the best experience in their work so that they also have fun doing what they do. We have partnerships in Europe with over 340,000 installer partners. In our IoT project, we are responsible to connect each of those systems to push data in the cloud. The data was never designed to be streamed to the internet. The second big challenge was we underestimated how our partners will adopt it and how many devices will be connected in what timeframe. After a year, we recognized that our system goes slower. We have to scale up and down our cluster nearly every week to keep all our systems running. Very fast, we made the decision we want a managed solution. After some research, we found out that there is a managed solution for MongoDB, Atlas. We had to transfer 20 billion records. We started in June 2018 and said, "We have to implement everything and migrate until end of August because we are going live with our product in September." Everybody said this is not realistic. The whole migration really took about 90 minutes. We just had to switch our services from one connector string to another connector string. It was there. This without any downtime. We went to the manager, we said we are finished, then we opened the fridge, some beers, and did a little bit party because it was so easy. We did this with an enormous saving in memory, especially in index, and also increased the performance of our API. That was, for me, the big aha moment where I said, "Okay, it was definitely the right choice to move to MongoDB." We don't have to scale up and down our database all the time. We are now able to use the aggregation pipeline. Over 99% innovation is unbelievable. This is a so good approach, and I also never thought that the benefit would be so great. It is now not my daily business to look at the database because it's just running. We could more concentrate on the things we really want to do. That means implement new services or new applications. This makes life easier for me, the work easier. After switching to MongoDB, it just runs. Great. Thanks, Michael. We'll start the Q&A now. We'll take our first question from Raimo Lenschow at Barclays. You announced a long list of new product announcements earlier tonight. Which one is the most exciting for you as a team? Well, I'm going to ask the team to respond, so maybe I'll start with Sahir. I think it's a tough task, a Chief Product Officer to choose which is the favorite announcement. I will say, we talked about the individual announcements when Mark went through the value proposition for customers. But what I think is exciting for us as a company is the 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 three crucial components together give us a foundation to really move faster with changing the database, make it smarter and more powerful, more automated over time. This is more of an internal lens, but I'm personally excited about what that allows us to do for the long term with the architecture and the value we can bring to customers. Mark, do you want to add to that? Yeah. I've been thinking about the question while Sahir answered. I wear four 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. 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. I can now cross-develop on Dart, on both iOS and Android. I guess that's four favorite children. Michael, do you have a favorite? I'll give a shout-out to FedRAMP just for something. I agree with everything Sahir and Mark said, but I'll give a little shout-out to the FedRAMP piece. Great. I think I'm similar to Sahir. One of the announcements I really like is live resharding. It really just puts an exclamation point on the fact that MongoDB is so far ahead of the market in terms of data distribution and scale. It's just not even close. The second thing I would say, kind of aligned to what Sahir said, was 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 all the cumbersome and tedious tasks of how to work around a database come into their world. 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. That's why I'm super excited about the announcements. Brian? Great. Thanks, Dev. Yeah, take our next question from Jason Ader at William Blair. It feels like the database market is getting more fragmented versus less. What do you think will be the catalyst for greater consolidation in this market over time? Yeah. 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 seven 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'd have the bozo issue, where customers didn't want to look like a bozo by picking up the wrong technology, so they'd naturally be skittish about how much they want to really bet on one 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. 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 their environments. That being said, I also think customers are recognizing that they 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. I'm going to take our next question from Brad Reback at 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. There's a lot of truly brilliant people there, 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. 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. By the way, it was 3 million lines when I stopped working on it in 1996. I don't know what it is now. They're wed. They can't break it out into different products. Yet that monolith has so many legacy ways of thinking in it 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. I just don't think they can get out of their own way, frankly, either technically or culturally. Great. Thanks, Mark. That's helpful. I'm going to go to our next question from Steve Koenig at the SMBC Nikko. We've got two here for you. Just first, any update on the adoption of newer products like Realm and Data Lake? 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? Yeah, absolutely. We've definitely seen an inflection point in adoption of some of the new products that have gone 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-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, that's clearly why we invested, and we 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 has a nice match for mobile gaming, which is a sub-segment of the gaming market, which is actually the fastest-growing as well. Now we provide an end-to-end architecture. I think those are the two, I think off the top of my head, worth calling out as potential interesting areas for new workloads for us. Anyone want to update on the adoption of Realm and Data Lake? Definitely. On the Realm side, I think we've seen a real fit in retail use cases, in particular. Situations where customers 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? 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 three key use cases that we've honed in on that seem to really be getting traction. First and foremost is clearly data tiering. Customers, especially some of the time series customers that we're working with, have a need to keep an immense volume of data accessible, but don't want to pay the cost of storing that in a core operational database system. 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, in particular, object storage like S3. You may have files that are generated from 10 different systems all landing there in sort of an S3 data lake. 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. That was one that just sort of organically started happening once we let Atlas 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, is federated query capabilities. 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. Those are the three emerging use cases that we're seeing with ADL, both integrated with the database as well as clearly independent. Great. Thanks, Sahir. Take our next question. This is a few different people have asked about M&A, and specifically, would it make sense for you to acquire some standalone NoSQL database companies that have niche use cases? Or just in general, as you look at the future, just larger M&A to accelerate time to market, something that the company is considering. 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. As part of Sahir's presentation, we think it's really important for a developer to have a seamless, unified experience when they're trying to build applications for a wide variety of use cases. By definition, trying to bolt on some third-party solution onto MongoDB would 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. Again, we have no plans to do so there. Historically, what we've done is surgical acquisitions. We've acquired technologies like WiredTiger 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. 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 have proven is that best-of-breed vendors can not only do well but be very successful and then grow into large companies. We want to be a best-of-breed vendor that offers a wide range of capabilities to customers, and that's our focus, 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 the document model being a superset is before we introduced time series, you might have said, "Oh, should you go buy a time series company?" Or before we introduce graph capability, should you go buy a graph database? I think it just sort of underscores the point that the beauty of MongoDB and the document model is as this 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. 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. How does it impact your internal product teams, as well as what it means in terms of speaking to customer demands and how you're going to be able to communicate your product roadmap externally? I don't know. Mark, you want to take this one since you run the engineering team? I think it's a two-part question. I will take the first part, and then, Sahir, you can take the roadmap piece. Sure. Look, the reality is that developers love shipping code. Having the code actually sit there for the last nine months of the year was just frustrating everybody. We did have to clean up our internal processes to test better, to do a lot of stuff better, to automate even more than we'd already automated. 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. Sahir, do you want to talk a little bit about the roadmap impact? Yeah. I think there's a couple of facets to this. We have a very diverse customer base, as you all know. First and foremost, we wanted to make sure we were predictable and that every year we were continuing to ship an annual release that had 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. We needed to maintain that sort of characteristic of predictability of an annual release. On the Atlas side, especially, we've been updating capabilities in Atlas on a three week cadence for a long time, 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, even if it's just for development and for testing environments rather than waiting for this annual release cycle." What this approach of having a versioned API with quarterly releases does is it allows us to give customers choice. If they want the ability to be an early adopter, use a capability as soon as we're ready after testing to ship it gives us a much more granular way to get capabilities to market sooner. 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.0 releases like MongoDB 5.0. 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 out ready, or you have to wait a full year and oftentimes a lot of internal testing to get there. We were meeting both of those ends of the spectrum. Great. Thanks, Sahir. Super helpful. 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 MongoDB really hasn't been used for? How do you think about the impact serverless will have on the growth of Atlas over time? Yeah. 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 the 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. We really want to make the developer experience as easy as possible. The thing that this does in terms of additive use cases is that it suddenly makes spiky workloads or workloads that are very intermittent in nature, very attractive to deploy on Atlas. Things you heard one of the customers on the panel talk 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. 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 of in the back end. We think that this will just drive incremental demand to our platform. I don't know if Sahir or Mark, 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 an application. 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. We view serverless not as sort of a new product alternative to what we have in Dedicated, but a step in the continuum of offerings that we give to our customers. Great. Thanks, Sahir. Maybe next question we'll take from Sanjit Singh of Morgan Stanley. I lost that one for a second there. How do you square the argument that relational can't ever be modernized with the fact the largest software app in history uses a relational data model, that PostgreSQL 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. Yeah. I know the PostgreSQL community well, and it is a wonderful community filled with great people, so no harshing there. However, the problem is that it still has all the limitations of that legacy code base. Look at how they've implemented JSON, and if you just have nothing left to do with your day, Google using JSON with PostgreSQL examples. It is one of the most contorted things you will ever see in computer science. Yet they support JSON. 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. 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 and 100 developers write another application, and 50 and 100 developers write another application. I talk to more than one CTO a day. I've talked to over 400 since I got here 340 days ago. 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 smashing the monolith. I think the problem is that the paradigm has changed. The technologies for addressing that paradigm shift are the modern technologies, not the old ones. I think I just want to add, Mark touched on this in his presentation, but whether it's Oracle or PostgreSQL or any other relational database, they still have the same fundamental limitations. They come to basically three things. One, developers do not think in rows and columns. As Sahir talked about, in object-oriented programming languages, you think about objects. Think 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. It's 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. The third point is that relational databases are not designed for scale. You have to figure out all these workarounds to scale your environment. Some people have tried to make relational databases suck less, but they still have real limitations in terms of data distribution, performance, and scale. For those three reasons, whether it's wrapped in an Oracle brand or an open source brand like PostgreSQL, 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. I'll just jump in and say, Dev, apparently you listened to the presentation, so thank you. That was awesome. I will also jump in with, look at, for example, what Aurora did at Amazon with MySQL and PostgreSQL. They couldn't modify the core database. All they did was put in a different storage engine underneath. You can look up the blog that says the Amazon Aurora storage engine. So I ran Aurora Postgres, and for six years, I tried to modify the Postgres engine, and I was unsuccessful. Great. Thanks, Mark. Another one from Sanjit at Morgan Stanley. One criticism of NoSQL movement is that it emphasized consistency to achieve massive availability. There are CockroachDB and others that are looking to bring consistency to the forefront. How does Mongo view this initiative around bringing greater consistency to cloud data stores? I assume this is about the consistency of the data, or it could be the implied flexibility of the data itself. It was the former, not the latter, we can answer both questions. MongoDB has a tunable consistency model. As Oleg talked about for Software AG, their IoT use cases, each individual data point is not that important. It's the trend of data that becomes more important. You want to capture data very quickly, and an eventually consistent model works well. For, say, being a source of truth or system of record as Current is using MongoDB, you need the transactional guarantees of a strongly consistent system. The fact that MongoDB supports both is a great example of how versatile MongoDB is. With regards to the schema, we have rules around helping people define how the schema should set up. Flexibility is not like both a blessing and a curse. We have guardrails to help customers define rules around how to set up a schema so people then can query that data much more easily. Here, Mark, if you want to add any 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. I think MongoDB has been the outlier where for the last six or seven 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. Also, if you think about transactional consistency, ACID guarantees, I think it's a little-known fact maybe, but MongoDB has always been strongly consistent with ACID guarantees from the get-go inception of the database. Then three years ago, we added multi-document. Once you're manipulating multiple objects in the system, the transaction capability to do so. In many ways, from the inception of the company, we believed 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 any of these mission-critical applications. That wouldn't be possible today, many years later, if we didn't have similar thinking around strong consistency guarantees. Great. Thanks, Sahir. Time for a couple more questions. Take the next one from Kash Rangan at Goldman. When a customer decides to stay with a legacy relational database, can you just talk through 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? One of the advantages that they 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 startup programs and our MongoDB University. 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. I think the ship is coming over the horizon, and it's going to be bad news. 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. When you look at what's going on in all of the modern data stores, of which we are one, in which we listed a number of others, connectivity and integration has been just a hallmark of the modern data stores since day one. Once you go down the relational path, you're starting to go it alone on an awful lot of things with your own developers, with your own technology, and with your own integrations. 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 three to five years. Great. Thanks, Mark. Maybe we'll take our last question from Raimo again at Barclays. Looking 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? Yeah. As Mark mentioned, and Sahir mentioned, we spend a lot of time talking to customers. With 27,000 customers, as you imagine, we have lots of conversations 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 in all the different silos as part of this CEO's pitch, it just becomes over time overwhelmingly complex. Customer, this is part of that I think relates to the question about fragmentation and defragmentation of the database market. We are clearly hearing from customers that they don't want more than one to two options for the majority of use cases. 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. Then maybe there'll be some corner cases where they use some niche solution for some esoteric use case. That's the way we see the world going. We think Amazon's roots around wide selection and low prices and while it worked in e-commerce, doesn't necessarily work in databases. Customers just don't want to manage and support 17 different database technologies. I think that's very easily verifiable when you talk to customers. That's, I think, why people are viewing MongoDB as 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. We feel like we're really well positioned to continue to be the general purpose modern standard for enterprises. 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. These people build them, and they're great, and you can live in this house, or you can live in a house down the street. No one ever contracts with the contractor to build your china cabinet or your furniture. That's where best of breed comes along. The reality is, the cloud providers build great houses. We live in them with our 27,000 customers. 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 have had to create to glue their own products together. That's just not okay. That's not what developers want, and it's not what enterprises want. I know I get a little passionate here, but I've lived both sides of that argument. The reality is, figure out who you want to build your house, and figure out who you want to build your furniture, and where do you want to put your china, which is your data. Great. Thanks, Mark. Michael, I'll turn it back to you and Dev to wrap it up. Yeah, 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 MongoDB.live were helpful, then this incremental session where you got to hear a particular focus from Dev and Mark Porter here on the product side of things, to hear from our customers and understand where the product roadmap is going. We look forward to talking to you all in several weeks, hope you're well between now and then. At some point, we look forward to doing all these in person. 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.