Good afternoon or good morning or evening depending on where you're tuning in. Thanks for joining us. Today is the 1st day of our annual user conference, mongodb. Live. We're doing it remotely this time again given circumstances, but look or to the event returning.
We believe it's really a great opportunity to remind you and remind our community about where we are heading. And so our goal today is really to inform you, to talk about our market, to talk about our strategy and to share some of our product 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. So just a quick look at the agenda. Here is the agenda that we have for the day.
Sahir, our Chief Product Officer is going to start us off. After Sahir, Mark Porter, our CTO is going to talk. Then Dave is going to host and moderate a customer panel That will have participants from Software AG, Current and Shutterfly. From there, we're going to hear from Steve O'Grady, Who's the founder of RedMonk, which is a research firm focused on developers. And then you will hear a little bit about our partnership with Alibaba.
And then lastly, we'll have time for an exact question and answer session with a number of us. I will look forward to that. Please submit your questions throughout the day. We'll try to get to as many of them as we can. Hopefully, You'll bear with any technical difficulties that we have during doing all this remote.
In our smooths throughout the day to try and mimic what you might have been able to do in Real live user conference is we've got sort of customer vignettes and stories that are sort of interspersed throughout the day under the theory that the more that you can hear directly from customers, the better we think you'll understand the company. It's a really packed schedule. We've tried to jam a lot into Really short period of time. So thanks for your patience and enduring our ambition here. Obviously, people take any breaks.
As you need, the session is being recorded and will be hosted on our website for some time. Again, we are doing this virtually for the first time. So please excuse any technical challenges that we have. And then with that, we'll get started. Before I turn it over to Sahir though, I wanted to start off with a customer testimonial that has a lot of personal significance to us in MongoDB.
Overnight on Friday 13th, governments decided to close all schools. Kids needed to stay at home. At Sonoma 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 of them 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 shelving this tablet in my face saying, Dad, Dad, I can't With Bingo, there's something happening.
Bingo 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 Bingle 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 component of the platform, the database component, in less than 3 days, once we made the switch to the MongoDB Atlas environment, Bingo was available, Performance was rock solid again. It's times like these that you really get to appreciate the difference between a supplier and We've been breaking records on a daily basis here. In a normal period, we would have seen pupils doing 1,500,000 to 3,000,000 Precisely, we now see plus 12,000,000 exercises day after day after day.
Headmaster schools, teachers, even kids, They're sending these thank you notes. It's very heartwarming. Sonoma 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
All right. So thank you all for joining. As Michael mentioned, I wanted to spend some time going through Some context in terms of what we're seeing in our customer base as well as some context in the sort of challenges we're trying to solve with the evolution of our strategy Over the last couple of years. So really wanted to kind of give a little bit of that context before we get into some details from Mark on our technical differentiation and the new So to get started, 1st and foremost, I don't think this is a controversial statement, But we believe firmly that modern business and competitive advantage is derived heavily and directly from Software and how well organizations are at building that software and leveraging their data to empower those digital experiences. Now the challenge we see is that as organizations make this shift to being digital in the way they drive commerce, There are really no barriers to entry.
So for example, if you're a local bank, it used to be that you were only competing with organizations perhaps in the same State, the same geography, the same country. But now it's just as easy for a challenger bank from across the world to enter your market and come out with more compelling, easily available We also see that competitive advantage can't be bought. And what we meant by what we mean by this is, It's not like software is new to most enterprises. We've all been running software for 20, 30, 40 years in some cases. But in order to create differentiation, when software and technology are the interface to your business, we believe that buying a SaaS vendor, using
a cloud platform as an infrastructure provider isn't enough.
You need to build 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.
And last but certainly not least, as organizations become digital interfaces to their customers, It's crucial that they become stewards of their customers' data. So things like data security, data privacy are Top of mind for almost every organization we speak to as they start to make this transition and lean into technology and software as a differentiator. Now, we see that 1st and foremost, if you want to deliver a modern customer experience, that is heavily tied and reliant on the underlying data infrastructure. But in fact, that modern application or customer experience has changed drastically over the last decade. It's now normal that customers Expect everything to be real time performant, not to be lag or slow down.
Slow is the new down in software in many ways. People expect highly personalized experiences. They expect their providers and their brands to interact with them and show them only the relevant information automatically at the right time. The way organizations and individuals interact with software has fundamentally changed. The canonical way to interface with applications today is Mobile, mobility to both because of its reach and its convenience is becoming the standard interface that organizations interact with their customers.
Data privacy is something that organizations have regulations around, requirements around that weren't even around 3 or 4 years ago. So the Right to forget, for example, for GDPR 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. And of course, every organization is looking to always improve.
The idea of updating your mobile banking application, Insurance quote application, whatever it may be, once a quarter, once a year is no longer good enough. So this idea that your teams need to be constantly pushing new capability as soon as it's ready It's a crucial requirement for every organization. The challenge is, of course, that for many companies, especially established brands, This is really hard. And if you look at the stats from the analysts, whether it's BCG in this case or others, it's typically 70% to 80% of enterprises that go 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 Modern applications is really working with the data, wrangling and understanding the context that needs How are those applications buried in the proprietary data that an organization creates and owns?
And so in many ways, what we've observed is that The requirements for applications, requirements from the business on applications has fundamentally changed in some pretty profound ways, as I just mentioned. However, the typical underlying data infrastructure in the average enterprise hasn't. And that's fundamentally because Data infrastructure is built around a relational core of systems, rows and columns organized in a certain way. That was formulated 40 years ago with the inception of accounting applications originally on the mainframe. And what we find is this rigid approach to managing data Makes experimenting, iterating, providing agile development practices really hard for the average organization.
And that's fundamentally because the data structures in these legacy systems clash with the way modern programming languages and modern development practices actually work. And as a simple example, this little chart on the right, not to get too deep on it is, modeling 4 basic objects potentially in a data model, Just the interdependencies between those four basic objects is hard to reason about when you're trying to move quickly across an organization. And fundamentally, from an architectural standpoint, the technologies of the past weren't built to support an always on application That doesn't have performance degradation, that automatically fails over should something go wrong in the infrastructure. They just won't architect it for that horizontal scale and global reach that many applications Now have. And this is just a very basic example.
I mean, when we go into our customer environments, there are oftentimes Special printers that print out 3 or 4 feet wide pieces of paper that have these complex rows and table diagrams, these energy relationship diagrams Paste it on the wall just so they can get a glimpse of it in totality to start to rationalize the changes that need to happen at any given time. And This is fundamentally what I think slows almost every organization down with traditional development approaches. And we see this in our customer base. I chose one example. This happens to be an insurance company here in New England in the United States.
And they had a heavy initiative to modernize their business insurance practice. And this was a top to bottom initiative. It wasn't just a data problem. So they first started with changing processes. They moved from traditional waterfall development 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. And they changed their deployment process. They move to what's called continuous delivery. So as their developers build new capability, they could just as easily automate the deployment of that to their test environment into their production environments.
And all of these were good changes. 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. And so, one of our key constituents in this organization we embarked on this project years ago is basically was we implemented all of these things, but it still took us days or weeks to ultimately get a We get a change out to our customer base. And so the business is saying, I don't care how much you spent on Agile and 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 of this investment.
And so that organization, the insurance company went and embarked on a set of changes that we see is quite typical. They said, All right. Well, there are certain things that, that database, that data technology that we've had at the core can't solve. So let's start surrounding it With newer technologies, let's choose some NoSQL data stores around the edges to try to deal with those shortcomings. So they added A key value store for some metadata.
They added some graph traversal databases to be able to understand relationships between different policies, for example, in their customer base. And what they found is, as they bolted on caching technologies, key value stores, all these different niche technologies, None of these was fundamentally able to replace the core problem. So they effectively became a Band Aid. It was more infrastructure, more technology Under the covers of this application that was trying to keep up and meet with those modern requirements. And then that imposed an even more challenging problem of Keeping data in sync.
So they had a separate set of technology and tools that they needed to add ETL vendors in their case that managed shuttling of data from the core transactional Legacy system and the surrounding new kind of 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. But As we dug deeper, we talked to more customers. We found that the problem is even much broader than the core database itself. And what we found is that Almost every application, not even consumer applications that we use day in, day out, but even internal applications, core back office systems that empower employee productivity, They all have a requirement for human readable relevancy based search.
And what organizations have to do is Yet again, stand up a separate technology and integrate the data from their core to that separate technology, typically Elasticsearch Solar in most of the environments we see. And as we zoom out, what we see is every hour, every individual, every dollar Then 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. But 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 Phones, Technology on Android phones, for example, that are used to have locally persistent data. So you can have a great user experience on your mobile phone. But at the same time, that imposes more integration work. So custom APIs, push notification code, message 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.
And of course, we're seeing the same thing happening in the analytical space. Increasingly, we're seeing organizations want to empower those smarter applications Or even just report operationally and provide operational analytics across multiple sources of data across this architecture. And most of the technologies, if not all the technologies that power the application, provide no analytical capabilities. So organizations are For us to stand up a data warehouse or some other technology just to enable real time operational analytics on what's happening in their business. So if we zoom out, what ends up happening in most organizations is we end up with this sprawl, this spaghetti architecture.
This is actually probably we had one customer tell us this is probably too pretty, too organized, but it's a conceptual diagram. Mark and I were on a call with CTO of 1 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. So this is very real and something we see growing as a problem for architects, for CTOs, for CIOs in the organizations we deal with. And there are any number of different technology players that fit in these boxes.
And in some organizations, even MongoDB starts off as one of those boxes. But this challenge, this architectural spaghetti, fundamentally in our experience creates a very fragmented developer experience. What it means is that every development team needs to now rationalize and reason about multiple APIs, multiple query language, There's multiple technologies and their capabilities just to enable those modern requirements I talked about upfront. It gives the organization less predictability. So they have multiple operational paradigms, multiple security surfaces to have to reason about.
And that creates just fundamental complexity and cost in the organization. It leads to unnecessary data integration. It's of course, there are going to be multiple data systems in a large organization. But What we see is this creates unnecessary duplication where data 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. And so Fundamentally, as we step back, we view this as a tax on innovation.
Every organization is trying to compete for development And compete with the best resources and designers and everything to be able to build great differentiated experiences. And they take all those people, all that talent, And they have them deal with plumbing and this fragmented experience as opposed to differentiating themselves. And that's really the problem that we've been focusing on solving. And so As we looked across the thousands of customers we speak to every day, we did find organizations and we work with organizations that Don't have that problem, that are ahead of the curve, that are on the bleeding edge. And we've sort of identified 4 key guidelines or principles, Tenants, 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.
1st 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 4 or 5 major tech companies. So if they're going to be able to compete in that market, Every developer they bring on, every DevOps engineer they bring on, every designer they bring on has to be extremely Proficient and extremely productive and can't just scare linearly with the size of the requirements coming in from the business. 2nd, they focus heavily on elegant and repeatable architectures. So every application doesn't have a different blueprint, That doesn't have a different set of technologies so that they can bring on a consolidation of skills and get leverage in their organization as they get smarter and stronger with a 4 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. And finally, the most advanced organizations look at multi cloud, Not as a burden or something to be afraid of that they've got to manage coming down the 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. And so these principles, that's what informs, frankly, our development at MongoDB. And so The last few years, many of you have seen us sort of really expand our portfolio, add a lot of core capabilities, integrate it and around the database. It's fundamentally focused on removing that tax, that architectural spaghetti, that application data complexity so that organizations can move more Quickly and focusing on core differentiation. So when we go out to the market today, we really focus In on this idea that we're the 1st application data platform.
And what we mean is we're not just solving only a database problem. That's the core of every application. But we solved the broader application data architecture problem, so organizations can have that simplicity, can accelerate that development for any workload, no matter what they're trying to build. Now to dig in a little bit here, and Mark will go into much more detail, but I want to give at a high level an overview here How we do this, it starts fundamentally with the data model that we chose, that our founders chose when they started the company and the technology over 12 years ago. And that is the document model.
The idea that the traditional rows and tables of a relational system that's pervasive in legacy computing Didn't scale to modern application requirements is and that choice is foundational to what drives the company today. Because the document model thinks fundamentally in objects. And if you follow kind of computer science over the last 20 years, Object oriented programming languages have become the norm. So the idea of being able to naturally think about business objects in your code And then persist that naturally down to objects and documents in the database, removes an immense amount of cognitive load overhead, Extra reasoning that goes into common development. And so that's the foundation of everything we think about at Mongo is how do we build on top of that Flexibility offered by this model.
The second point, which is a little bit more nuanced is the document model is Quite broad. And so we realized this is 7, 8 years ago that the document model, because of what we were seeing in our customer base, Could actually be a superset of other data models. So managing basic key value data for maybe IoT or time series data and financial services It's 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.
So we had a strong foundation to add use case after use case after use case. The next big piece was when we looked at our fragmented user experience was how do we actually unify the developer Because what we're seeing, especially in the public cloud, is a plethora of choice. Every developer in every organization has access to dozens and dozens of different technologies today. And what we're seeing here is that, that creates complexity, as I mentioned above. So we knew that if we were going to add capability, we had to match that capability With a unified and elegant interface for developers to interact, say, one technology and repeatable sort of knowledge that they can 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. And 1st and foremost, We doubled down on strong guarantees on consistency of the data. And so many of you know, a few years ago, we released multi document 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. So the reason why organizations choose MongoDB To get not only developer agility, but to fully modernize traditional systems. This could be back end payment systems, core banking systems, Insurance Pricing Systems, this requires this capability and we're one of the first, if not the only modern technology to bring this forward into the new era. So that was really a big step forward and 3 years of major investment to get there. Next, we tackled the search problem.
We recognize that managing a dedicated search engine was perhaps in many organizations, and we're seeing that in our customer base now with Atlas Search. As they're coming in, that's actually more complicated than the core database in some environments when they have petabytes of search data that they want to empower. And so we knew we could do better. And so we integrated that into the database experience. So the developer feels like it's a core part of the experience, But they're not operating a separate system and they can actually run unified queries across their operational data and their search queries for the application to be even more powerful.
On the mobile side, we acquired a technology here for that mobile persistence, for unifying all the different plethora of Platforms we see on mobile devices. In many ways, Realm did what for mobile developers to what MongoDB had done for back end developers. It was Create this much more natural experience. And what we did is we integrated that mobile database with a novel sync protocol Back to the cloud, back to our core database so that organizations don't have to deal with bespoke integration work, bespoke plumbing. We can handle Variable connections, we can handle offline experiences and manage all that data conflict resolution integration for customers very easily.
We heavily invested in real time analytics. So both through workload isolation, so you could run analytical queries on the database While not disrupting the core operations of that application, that was one of our first steps in the distributed architecture. But then we added things like native visualization because what we saw was People wanted graphs, charts, empowering not just a dashboard, but the actual live application experience that internal or external customers are looking at. And we've expanded that to broader analytics with Atlas Data Lake. So the ability to federate and combine analytical queries, Perhaps with data that even originated outside of MongoDB, that's stored in S3, for example, on Amazon and being able to combine and transform that data And either operationalize it or merge it together for broader queries for bigger understanding of what's happening in the business.
Now all of that capability I walked through, the document model, the breadth 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. And so Everything at MongoDB from the early days through today and the latest innovation we're rolled out on the Atlas side is about distributing data. It's about making sure that we leverage the best of cloud native architecture for availability, for performance, for cost, but also that we can so we can meet The demands of global applications. So that if you need to keep data in Canada for your Canadian customers, Germany for your German customer base and Sydney, for 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 compliance and security controls. So Organizations today unfortunately have to make a trade off. They have this immense desire to drive innovation by leveraging cloud Application data platforms like Atlas, like other cloud data companies. But the problem is they're giving up control of their data to a third party.
And that's not only 1 third party. If you're using a SaaS service, for example, or a SaaS cloud database or cloud application, you're not only dealing with 1 third party, you're potentially dealing with multiple. You're dealing with the underlying infrastructure cloud provider, the data center provider, the networking provider. There may be multiple levels of control there. So organizations were then saying, okay, I want to leverage the best of what the cloud offers, but I can't because I've got regulatory reasons or other reasons to Control the most sensitive PII or personal health information.
And so we give customers the ability to not have to make that trade off. And so we enabled things like client side field level encryption. So organizations could control the keys down to a very granular level for an individual, for an individual And maintain that control no matter where they run the database,
whether it
be with MongoDB, and Atlas or self managing on a third party cloud provider. And they can delete that definitively without the worry that that data has leaked somewhere across multiple spans of control. And finally, we're a clear leader in multi cloud. We invested early and heavily in not only building on 3 cloud providers, but also providing global reach. I think as of today, we're roughly just over 81 global regions, the most available public database as a service on the planet.
But most importantly, the ability to connect those clouds. So we're seeing organizations spin up cloud databases that span multiple major cloud providers, Whether it be to migrate a database from 1 provider to another, to spend data to from 1 provider to another to get availability in a single geography, a variety of different use cases. Certainly, we believe this is an important tailwind for customer value that we are well ahead of the market on and will be Ever more important as you move into the future. And so if I step back, the developer experience fragmentation, The complex operational and security model, the unnecessary data duplication I talked about earlier, these are the foundational problems that we Aim to solve today in 2021 and beyond as we start to really expand our strategy into becoming this application data platform more broadly than even today. And we do that by providing a unified developer experience, an architecture that's repeatable and easy to reason about for operations and security That provides automated and transparent data movement.
So you don't need other technologies just to manage the correct storage and performance profiles for these use cases And ultimately reduces the amount of data duplication required across an organization. And some of our most advanced customers are Following those key principles I mentioned earlier by leveraging this platform. So I mentioned one of our large insurance customers earlier. They finally closed that last mile gap on delivery and started getting code out in hours instead of days or weeks by moving to MongoDB for the core of their systems. We work with a challenger bank.
I believe this one's out of Canada, and they actually empower unified search, Analytics and core transactional systems, all in MongoDB. And the reason that's so important for them They've got a relatively small team comparatively to the large organizations that they're trying to disrupt. So every ounce of Speed they can get out of consolidating that architecture is crucial to them. So 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 UK and making sure we can secure citizen data by allowing them to delete Keys if they need to delete a particular citizen's information while leveraging the best of the public cloud platforms.
And finally, we work with 1 of the largest healthcare providers, 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.
So 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 CTO of Asset Management, a major investment bank. He was focused on a project. I believe it was somewhere around 35 or 40 individuals from operations, security, networking, database Team that was looking at spanning a database across Sydney, the Eastern U.
S. And Switzerland across 3 cloud providers. And that was going to be a multi week project, just a proof of concept that with that many people. And by showing him how easily we could stand that up with a couple clicks in the UI or just an API call, his statement to us was he just took that to From a 35 person project to a 2 person project to stand that up and test before lunch. So I think we're in the early days of customers really seeing the power of that just Given where they are in their multi cloud journey, but we're really excited about how we can partner with organizations on that journey.
And so as we look to The use cases across the environments we work with, whether it's product catalogs, customer 360 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. And that's the vision and the focus of the company today and definitely what you'll see us continuing on in the coming years as we invest even more. So with that being said, I believe the next step is to have another customer story of one of the great examples of a 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,000,000 citizens. We pay out Over £190,000,000,000 per year in payments to people who need that support.
Universal Credit is The biggest change in the world by state in the UK since the 2nd World War, it's designed to help people get back to 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
We saw like massive increase in traffic to the Universal Credit online service, in some People were paid on time and in full. MongoDB proactively
got in touch with us, I think, within the 1st few weeks of COVID to kind of understand how we Getting on and whether there was any extra additional support that they can provide us.
We've been working with MongoDB as our database in Universal Credit since 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 Stress of worrying about resilience. Universal Credit are looking to migrate our database services, and 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 1,000,000 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 Build 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 But 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 is Mark Porter. Welcome today. It's great to see you and thanks for your time. I would love to remind all of you that you can queue up questions for the Q and A sessions by just typing them into the Q and A box you see on your window.
So, Tahir told you about how our products give value to customers. I'm trying to get the there we go. Sahir told you about how our products give value to customers. I'm going to tell you about what our technical advantages are in delivering those products. But first, I think it's important for you to understand some of the history of data and how it's evolved, and we'll start a little bit with my own personal evolution.
Finally, I'll close by telling you about today's exciting product announcements. So my personal intro Is I've lived data, asset 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 1990s, I worked on Oracle 5, 6, 7 and 8 And Oracle RAC. And for those of you who use it, I hope you were delighted.
And if you didn't like it, I'm sorry. Oracle RAC is the backbone of Oracle's high performance, expensive and proprietary Exadata machines. After a decade of retirement, I came back as a CTO of News Corp, working on a mass student data system. And I got to use MongoDB. It was literally, even in 2011, The only platform that had the functionality and the scale we needed.
Next was AWS, where I was the General Manager And development and leader of Amazon RDS, Aurora and the database migration service, which has migrated over 300,000 legacy databases Such as Oracle and SQL Server into AWS. However, I ultimately became disillusioned By the restrictions of relational technology, despite being in it for 30 years and a number of other barriers to innovation, and I decided to move on. As a result of the experience up 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 then joined Grab as CTO, helping Southeast Asia with millions of rides, meals and payments Every day with over 1500 databases in our infrastructure. And even some of those databases were MongoDB. In 2019, I joined MongoDB on the Board and I quickly realized that I could have the impact on data at MongoDB that I had always wanted. And I asked Dave if I could be his CTO. He agreed, which brings us up to today.
Now you may wonder why this story matters. You might think it's controversial for me, who's been a core member of the relational technology community for decades to come to MongoDB. On the contrary, I intend to show you that today I intend to show you today that it's the next logical step for both me and for the industry. Now in those 35 years, there was one trend I could always count on. I'll let you look at that slide for a second.
And that trend was that data is growing exponentially and that growth is actually accelerating. Here you see the amount of corporate data in the world over the last 30 years with a logarithmic virtual access. The graph represents over a 1000000 times growth. And here's the kicker. The vast majority of that data, maybe 70% or 80% depending on who you talk to, is not row and column data, But 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 tour of data has created challenges, which creates opportunities.
All of that data needs to be persisted, stored, backed up. And as a tech guy, with every order of magnitude of data growth, back end technology has to change fundamentally. And I've lived through all of those changes. But I want to take you back in a time machine to 1970 when things were a little bit different. Before 1970, all data was stored in proprietary systems with proprietary access methods.
In 1970, the revolutionary relational data model was published by Yefkad, and here's his paper. It was a way to manage data and avoid duplication when storage was wildly expensive and horribly slow. It was a way to write applications that talk to their data in similar ways, no matter what database they used. And in fact, right after this, The SQL language followed and was released in 1979 first by the company that would become to be known as Oracle. However, it's important to note that, that time was 51 years ago last month.
Computer systems have grown literally millions of times more powerful since then, and the constraints of that time are just not the constraints of today. However, It was better than anything that came before. And as you know, relational became the standard for corporate data systems. Over time, Storage became faster and cheaper, developers became more expensive and speed became more important, not only speed of the computers, that's obvious, The speed of your company. By the turn of the century, relational technology was struggling.
I felt it. I was there. Relational systems are strictly defined and hard to change, often requiring rearchitecture and downtime. So central IT departments, maybe at the companies you're at, manage them frustrating and slowing down developers. In fact, many new college grads at both our company and at companies that we talk to say they have no wish to work on relational systems anymore.
Relational skills are becoming the new COBOL. And strict rows and COBOLs and strict rows and columns, sorry, Our former strengths are now a weakness. To model all the different data and application needs, engineers have to do contortions with lookup tables and mostly empty columns. This is confusing and inefficient. Also relational databases just don't scale well.
And I say this as a guy who spent his career trying. Relational can scale reads across many machines, but it can't scale rights. They all have to go to a single machine, Limiting performance and risking huge outages if that machine crashes or becomes overloaded. My personal experience Is that the majority of the outage minutes at Amazon and Grab were caused by the operational complexity and scaling limits of relational databases. Think about that for a minute.
All of the things above were bad enough, But it's even worse. The Internet in the early 2000s was taking over and applications might need to scale by orders of magnitude literally overnight, Instead, a couple percent per week, which was what the world was used to pre Internet. So just when the data systems at companies were most stressed, The requirements have gotten more demanding. Another thing happened in the 2000s. And as a CTO, I get to give you a text slide.
This graph showing computer performance from 1995 to 2011. As you can see, the slope of the curve starts flattening out in 2,003. And by 2,006, it was clear that Moore's Law had officially run out of gas. 1st, correlational tech couldn't and still can't scale past a single machine. 2nd, Databases, machines have stopped getting faster, fast enough.
And third, the Internet happened. So these are the technical and market forces that made the NoSQL movement happen when it did. It's not a mystery. It's not a coincidence. In fact, this was the reason sorry, I just realized the slide didn't come up.
There is the slide I've been talking about. I'll let you look at it for a second. In fact, this was the reason that Dwight Merriman, Kevin Ryan and Elauwit Horowitz founded MongoDB. And you can see on that slide We're 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 the same problem, they saw an opportunity. They set out to build the world's best modern general purpose database, one that would scale without limit and would be the new way for developers to build applications. In fact, MongoDB wasn't alone in seeing that wall. This technology crisis opened the door for disruption by many, many tech companies. And since the database market is huge, Many companies signed up for the challenge.
So let's talk a little bit about the NoSQL movement. The NoSQL movement 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 a week, Nothing is more important than scale and performance.
Next, velocity of development became key And that meant that engineers needed flexible data structures that they can define, deploy and iterate on without getting their central IT T 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. So the blush came off the NoSQL rows pretty quickly For mission critical use cases. The NoSQL players hadn't built in the robust query technologies of the relational players, Tuned and improved over decades, so enterprises could move their applications. And many NoSQL players took their flexibility too far.
Production apps must be able to lock down their data structures and the data in them for control, compliance and regulatory needs. And companies thought Naively that they could get away without enterprise security features, encryption, single sign on, etcetera, 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 and look what company's name I have on my badge.
MongoDB didn't fool themselves that enterprises would put up with anything other than mission critical functionality. We just never played that game. This different approach is fundamental to the speed and success of our company, and I'm going to walk you through that approach now. Sahira has already told you about the document model and how it's key to our success. It's what got developers so excited when we launched And it's completely different than how other databases stored data before the document model.
You've heard us tell you before it's flexible and maps to how developers think in code. First, developers want to have the same thing in their head, Their code and their databases. And Steve from RedMonk will tell you a little bit more about that later today. Next, Objects need to be different sometimes and computers shouldn't make that hard for them. Custom objects in relational mean new columns, new tables, new lookups.
In MongoDB, think about this for a minute, the developer just updates their code, the database automatically creates the data structures behind it. No DBA, no operations, no ticket. It turns out that computers like documents too, not just people. Since all the data that is read together or written together is stored together, documents are faster than following rows and columns across all the tables. And MongoDB's implementation of documents is very mature with over a decade of work.
We have bigger documents than some of our competitors And we have the most flexible documents and operators on those documents of anyone in the industry. And this adds up to the fact, And it is a fact that developers are more productive and engaged when working with modern document technologies. Another area we also tell you sorry, we also tell you that documents or objects Our 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 Come to MongoDB and have people customers tell me all the time that their relational apps couldn't move over. Over 200 customer conversations over 1 year at the And I have heard that exactly 0 times. MongoDB also supports key value For those simple applications that just need blindingly fast lookup and storage speed, MongoDB functions perfectly well as a massive distributed key value store. And for graph use cases like social media, fraud and recommendations, ones I'm very familiar with from Amazon and Grab, You can model documents as nodes and edges and use our GraphQL support to traverse them.
In fact, Referring back to my earlier comment, since applications are a combination of these multiple data models, why would you stand up multiple data Stores for relational, key value, object, graph and geo, when you can stand up a single general purpose data store And do reads and writes and queries across them. The next thing I'd like to talk about is scale. It's another area where MongoDB has distinguished itself from both relational and NoSQL competitors. So first, A quick reminder on how vertical and horizontal scaling work. With traditional vertical scaling systems, Whenever you need the ability to do more rights per second, you move to a larger sized box.
You buy another box or you go to the cloud provider and click on the console. Eventually, you run out of larger sized boxes. And 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. Or they don't let you control the data distribution, which might be essential for performance or data sovereignty like Sajir 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 Sajir talked about, or across the world for local performance and data sovereignty. And you can do it all in whatever cloud providers you choose, Simultaneously, nobody else can do that. And we're going to make it better. We believe in letting customers make Their data and their database match their needs rather than forcing them to use our data structures and our database.
It's complicated to balance GDPR, application speed, cost and complexity. With MongoDB's run anywhere philosophy, customers can get The mix they need. Now, the final key pillar of the approach is that enterprises need mission critical systems, no matter whether they're in retail, banking, trading or any other vertical. To meet these needs, We have a rich query tech on par with relational databases and in many ways better. Just check out our aggregation pipelines.
They're better than relational. So customers can migrate their legacy apps and write powerful new ones. We also added fully compliant ACID transactions Because indeed, many workloads need them. For example, moving money from one account to another involves the simultaneous update of 2 documents that you can't have fail. And we never lost sight that security is job 1.
And so we have full encryption capabilities on premises, in the cloud, Between clouds, and that was hard, and full integration with every cloud provider security system. And in addition to the basic encryption at rest and in flight, Sahir told you about our unique client side encryption so that your data is encrypted So that the network provider, the cloud provider and even MongoDB can never see it if you don't wish us to. These features are what enterprises are looking for. Now you've seen this picture before. Sajir just showed it to you.
And I want to just highlight, Because of the limitations of relational, customers have had no choice to deploy these niche databases in front of their relational databases. This is complicated, Our approach It allows MongoDB for the majority of use cases to handle the workloads, the niche databases were fronting for the relational databases, Eliminating that cost and complexity. So, so far, we've talked about the technical advantages of our core database, Document model, scalability without compromise and enterprise scalability and enterprise feature focus. These are formidable technical advantages that will benefit us for years But we haven't stopped there. 2 years ago, we started releasing parts of our next journey, our application data platform.
I'm really excited about it, as is Tahir that you heard about. Here's the picture of that general purpose database again. An application data platform builds everything around that database that customers need to build end to end applications In the small 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 of times they write it.
Trust me. Most applications also need search, Another thing developers get wrong and Sahir told you about how it's just a couple of clicks away. No infrastructure to stand up, No programming to do, just integrate the search box directly into your app. Finally, we've added Atlas Data Lake 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. And this is a picture of that architecture. Now I'd like to switch gears and talk about what's next for MongoDB. Today is a big day. It's my first stop 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 in a separate store sits right beside your normal MongoDB data. You can join the 2 together. No need to stand up separate time series databases and synchronize all the data back and forth.
We're really excited about this and it's just the beginning of our time series journey. Next, There's a little bit of a nerd feature here. I'm going to give you a warning. We are announcing live 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 what how you'd like to distribute the data And it will perform hours or days' worth of work to move it all around on your clusters without downtime or application interruption. It's a pretty amazing feature for operators.
We're also adding new security controls. One of our key features you've heard about is client side encryption, Where not even the cloud provider or us can see it. We're extending that feature to better integrate with all 3 cloud providers, Even on multi cloud clusters, which is crazy complicated. And we're letting you configure your security filters now online without downtime And without going offline at all, to respond to new events or new threats or new questions you want to ask. And this is all how we put security first Without interrupting customer applications.
Next, we've recently announced that we are FedRAMP ready And we're launching our new initiative called Atlas for Government. Government agencies can now move forward to take advantage of MongoDB Atlas for their critical workloads. And even better, MongoDB partners can now sell their products that use MongoDB underlying them to the government easier. This announcement positions us better for growth in a very critical vertical worldwide. Sahir talks 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. And now we're adding support for the 3 most important ones.
The game platform Unity for game developers, The 2 most popular cross platform languages, Kotlin and Dart. And we're making Realm Sync more selective and customizable in what it syncs, So that the data on your phone is smaller, faster and exactly what you need. By continuing to make Realm more ubiquitous, We're bringing our application data platform right out on the glass that's in front of every user and we're positioning it to become the default mobile database And further drive Atlas adoption. 1 of the more Exciting features for me that we're launching is the ability to run long running queries, execute it against data at a specific point in time. Lots of people can do that, but we can do it on separate analytics nodes that allow customers to have complicated queries that run for hours Without affecting transactional systems.
Remember I told you about all those downtime minutes that occur because of relational database limitations. People running analytics workloads on relational databases is a major part of it. And so people have to stand up separate database systems and synchronize the data To not have that happen, not so with MongoDB. Today, we're also announcing MongoDB Charts, our built in chart solution, now supports Atlas Data Lake. I played with it for the first time today and it's awesome.
Now customers can build real time charts and embed them in web pages using a mix of database from their transactional databases, their S3 buckets And including time series collection and their data lakes. It's very exciting. Next, but absolutely not last, is Atlas Serverless, one of our most important announcements. With Serverless, Customers can use MongoDB without having to pick up or pick a specific machine type or size. Their application connects And we'll take care of scaling the database up or down as the workload changes.
We're targeting workloads that run-in frequently 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, 4 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 Tension to the needs of the enterprise will make it even easier for companies to adopt MongoDB for their mission critical applications. So I've tried to give you technical background on what has happened in the world That caused MongoDB and NoSQL to start. What decisions we've made and give you our decision framework and what decisions we continue to make And why they make MongoDB so successful.
If I've learned anything in the last 35 years, it's that the data march is going to remain relentless, That modern applications have hit the limits of relational technology. We have indeed built the best database in the world for most operational workloads. We're expanding that with the best application data platform, and our announcements today build that out even more. With our application data platform, modern engineering teams can build end to end applications faster. And if I could leave 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 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 and A at the end, but please submit your questions through the portal, Whether it be on product stuff that we discussed with Sahir or Mark or other things as they come up throughout the session, please submit and send those in. And with that, I'll turn it over to Dave for the customer panel.
Thanks, Michael. It's good to talk to all of you today. It's my privilege to introduce 3 of our customers. You've already Seeing some video testimonials, but now you'll hear from them hear from a few of our customers live. It's my privilege to introduce Doctor.
Jurgen Kramer, GM of the IoT and Analytics Business at Software AG Trevor Marshall, who's the Chief Technology Officer at Current And Oleg Zhukov, Principal DBA at Shutterfly. Gentlemen, thank you for joining us. So what I'm going to do is Just ask each of you to just tell us a little bit about yourself and how your company is using MongoDB. Jurgen, why
don't we start with you? Yes, sure. Also welcome from my side, pleasure to be on here with you. My name is Jurgen Kramer. As Dave I'm the General Manager of the Business Unit IoT and Analytics.
So Software AG, let me start there in case you're not familiar with Software AG. We're founded in 1969, headquartered in Germany, so we have 50 years plus built. We have more than 10,000 customers in more than 70 countries around the world. And the IoT and Linux business is one of our strategic growth areas. And our flagship product in there is Called Cumulocity IoT, and we're using MongoDB as the operational store in Cumulocity.
So Like you can imagine from the name, Cubelocity 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 Yes. We help our customers to analyze the data, turn insights into actions.
We also have integration technology in our portfolio. WebMethods might be a brand that some of you are familiar with. So we can then combine the IoT data with the other enterprise data in the business and allow our customers to build powerful apps on top. Cumulocity IoT, we sell it directly to customers. Many of them are makers of connected products.
And what they do is they build they connect these machines and assets to Software enable their business. They want to sell smarter products and higher value services to their customers and Serve their customers also with a better customer experience. Let me give you some examples. So customer the customer will be Nordics. They manufacture and operate wind turbines.
Or DMG Mori. They have milling machines and other machines in various industries, automotive, Airspace, etcetera. Durer, they have painting robots. SMC is another customer. They are in the Ploomatics Industrial Business.
Grieser, they have Sunblinds. For SDW or with SDW, we're tracking buses in London, for example. We have Lyrico's or connected Nespresso machines, Gardner Denver, they do industrial compress. As you can see, the variety already. But then we also besides these direct customers, we also have service providers.
What they do, they take Humulocity, white label it and then enrich our platform with their own go to markets and ecosystems. So they have their own go to market on top. For example, in manufacturing, building, whatever logistics They select, right? And this helps us to scale even faster and drive platform adoption. And examples here are, for example, Deutsche Telekom Cloud of Things Is a white label's cumulative.
Same with NTT in Japan or Telstra in Australia or a startup in Singapore. And also industrial players like Siemens Did MindSphere or Stanley Black and Decker white label our platform? Because it might be interesting to you, We are offering managed services for MongoDB, right? So we are offering this for our customers. And some customers are even operating the platform on their own.
Jurgen, 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, and thanks for inviting me here. Current is a financial technology Based here in New York, we started in 2015, and actually we've been working with MongoDB pretty much the whole way through. We've gone through a lot of different iterations of our product throughout the years. But most recently, for the last couple of years, we've been building banking services with our partner banks. We have over 3,000,000 customers here in the U.
S. And yes, MongoDB is actually a really fundamental part of the service we deliver. We keep our system of record Hosted in a horizontally scalable sharded Atlas cluster that I'd be happy to talk more about. But thanks for having me.
Great. Thank you, Trevor. And Oleg?
Yes. Hey, Leon.
Sorry, go ahead,
My name is Olin Giacob, and I'm a Principal Visa Business admin with Charterflight here in Redwood City, California. Charterfly 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 on the back end for Some of the microservices. Also, we use MongoDB as a backend for a set of our manufacturing platforms. 1 of our sub brands, Tiny Prints, is using MongoDB as Primarily, ordering system database.
So we can say MongoDB is the backbone pretty much of our database set here at SharePoint. Our clusters range from 100 of megabytes to 130 terabyte in size. And we have, I believe, a few hundreds of them across all production and non production environments.
Great. Thank you. Thank
you, Oleg. So the first question I'm going to ask is for all
of you
is, which is an obvious follow-up question, I think for the audience would be why did you actually choose MongoDB? With all the options and available alternatives out in the marketplace, What was the reason why I chose MongoDB? Trevor, maybe I'll start with you.
Yes, absolutely. As Mark mentioned in the last segment, which was great and also some really exciting stuff I'm looking forward to using myself. It's like the developer flexibility is pretty much unmatched across the ecosystem. And it's something that we were able to even in a highly structured industry that we operate, which is finance, you can encode a ton of flexibility Into your document structures and ultimately, the types of features we can offer. It's really hard to make the right decisions for data modeling upfront as a use It evolves and then it becomes extremely painful to make migrations in different types of in different types of persistence layers.
So we've been able to really lean heavily into that flexibility. And it's something that allows us to release new features really quickly.
Great. Jurgen?
Sure. Yes. So there are basically yes, thank you. Sure. There are basically two reasons.
On the one hand side, number 1, it's the scalability and distributed nature. And number 2 It's the flexible data model. Let me maybe elaborate a bit on the first one, so the scalability and distributed nature and why this is so important for IoT. IoT devices in many use cases are by nature very broadly distributed, even geographically distributed, right? And some of our customers, we see actually more and more customers are deploying millions and millions of devices.
So these early days of IoT, Where most of the companies try to figure out whether something's in that hype around IoT, these are over, right? So now the business cases Understood. It's clear that there is value. And what we see is now really mission critical deployment and massive rollouts. We have Companies like a multinational company that manufactures escalators at moving walks.
And they are moving 1,000,000,000 people per day, right, around the globe. And they now roll out the fleet of more than 1,000,000 elevators in the next 3 years on Cumulocity. Or a medical and clinical equipment Company in the U. S, they have equipment like hospital beds. They are rolling out 1,200,000 and connecting 1,200,000 Assets over the next 3 years or a company in Liechtenstein that develops, manufactures Products for the construction and building industry, they are rolling out 9,000,000 connected devices.
So you see what's happening there, right? And The fact that MongoDB was built for scale, that's something that was very, very important for us. And then In IoT, we have distributed architectures. We have the cloud, yes, but there's also an edge. And Many edge use cases, you need edge to deal with high volume data in many low latency use cases.
So where you need to analyze the data close to the data sources. And we're using MongoDB in the cloud and at the edge. So there is no different configurate there is no different database used in the cloud. It's The same APIs in the cloud and at the edge, so we can develop an application once and deploy it seamlessly in the cloud and at the edge. And with 5 gs, and you're aware of that trend, this will even further accelerate the adoption of edge platforms.
And now the second point I mentioned was the data model, right? So in IoT, you have the heterogeneity of devices, protocols and use cases. Each customer, different devices, different use cases. And these devices, they send data with different payloads to the platform, Right. So 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. And MongoDB is giving us that flexibility in terms of the data model. And that makes it then easier for Customers to get started and to see value out of the IoT projects.
Great. Thank you. So I'm going to ask the next question of Oleg. Part of your architecture was migrating microservices from a relational database to MongoDB. This is something that investors are very interested in.
So we're trying 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 in 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. In last year, for this particular project, we took a look at our entire E commerce stack that was using Oracle as a back end for pretty much everything. And Well, the application part was being split into multiple microservices. We decided to use dedicated back ends From Octolus Microservices, we found that it not necessarily has to be Oracle with its Price in the RDBMS model, whereas we can use a NoSQL solution.
And then looking at NoSQL Also available non SQL solutions, we always consider MongoDB at the top of the list because of its maturity, flexibility, We built a feature that people just mentioned as well. So one of the examples I can probably give is that We had a system that was serving our media store, where in the database, we would Store pointers to the media files that we would eventually store in S3 and AWS. This part was historically served by Oracle Database. But in this case, I believe that MongoDB and non single search It would be much better choice because, again, all of its flexibility, high reliability, scalability, because we have like 100 I have thousands of users sometimes here in the system. So we migrated This part of the application into microservices, and we created a dedicated MongoDB cluster just to serve this part Of the application.
And eventually, it turned out to be a great solution for us. Ian, to mention, it's highly available. It is flexible. It is It's very responsive. And our business is highly seasonal.
We have like 70% of our revenue coming into 1 quarter during the whole this year. With MongoDB Atlas, we were able to This particular part of application up painlessly for this season and then down Good evening. After that high season is over, having significant cost reduction.
Great. Thank you for that. So Trevor, you've obviously been also a big user of Atlas and in fact now you're an early adopter of Atlas Search For a financial services company using MongoDB as a system of record, that's also something that investors have been really interested in understanding How that works? Maybe you can talk a little bit about your experience using Atlas and what made you consider cert, because I believe you're using Elastic before And why you decided to consolidate your application sort of functionality onto MongoDB?
Yes, absolutely. I guess a couple of things on Atlas. Like, As Mark mentioned, horizontal scaling is really hard. It's hard to execute. And the fact that once you get kind of set up in a position where you Thought through the document structure that you do have a button, Mongo's EV Atlas gives you that button.
And it's whenever you need more, you just You hit the button. And that's like an absolute dream, and it's been something that we've been using for years. And we use Mongo kind of Across the stack, we have sort of that system of record. And the flexibility that's required there is we introduce different document types that help feed balances. And so that might be if we're integrating with a new, like, cash deposits, like a new type of integration, new type of payment, new type of credit that might exist The customer ledger, we can tie and make the decision about the necessary logic and data that needs to be stored on that document, And we can make those decisions over time.
So it's allowed us to be super flexible with the types of partners we work with, which is really important for the type of value we can deliver. On the searching side, it covers a component of our app where we have peer to peer payment functionality. And we were sort of in the state 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. And when you have the ability to just apply a search index Very natively on top of your store.
It's just 10 less things my team has to think about. And since we're a small team, That's like a huge prioritization element. And so that's been a big driver for us. We can kind of it's a set and forget. And just recently, I had to change Some of the logic or my team had to change some of the logic for search.
And we go in, we've got our search query, we filter some things out, we add an include statement. And that's kind of the end of that. We don't have to think about, okay, well, what is our change stream that we have to synchronize to an Elastic cluster for this purpose. So It simplifies our workflows massively.
All right.
Thank you for that.
Jurgen, you are obviously with IoT, IoT has lent itself to time series. I believe you've been aware about our time series announcement and just wondering how you think about time series for your business. And you obviously have a business where you have to deal with customers on the edge as well as other places. So you've gone You're not using Atlas today, just given your business model. Can you talk a little bit about experience there as well?
Sure. So let's start with the time series. In IoT, time series is a quite natural format, right? If you have a sensor like a temperature sensor That gives you a reading every minute. It produces a time series, right?
So being able to efficiently analyze time series, index time series It's quite valuable. So that's why we're very much interested in the new time series functionality in Mongo, because it will help us to serve our customers better with fast Analytics, so they can get also pass the value out of the platform and also better user experience. Maybe let me give you a customer example where this is relevant. We have a customer in the wind farm area, Nordex, I mentioned the name already, one of the world's Largest wind turbine manufacturers. And they have a distributed architecture.
So they want to be able to manage critical operation on a wind turbine level As well as on a whole farm level, right? So they have an edge installed in the wind farms and then these edges are connected to a cloud platform Where the relevant data has been 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, etcetera. And an example would be to detect the icing of a wind turbine and raise an alarm in the control And to give you some more numbers, what that means, the Nordex fleet currently connected to cumulocity is around 7,000 plus wind turbines.
And we ingest 25,000 data points per second into Mongo. That means in a full week window, we have 25 Terabytes of stored data in Mongo in the Mongo cluster. And in terms of energy, just to give the audience here a feeling, That's more than 16.5 gigawatts of energy being connected to the platform. That's enough energy For nearly 12,000,000 homes and 15 more than 15 nuclear plants, which would generate, right, just to put that into context. Great.
Thank you. Oleg, you obviously the principal DBA Shutterfly, most investors Maybe naively think organizations don't necessarily need DBA since Atlas is a matter of service. Since Shutterfly is using Atlas, can you explain how and you're a big fan of Atlas, can you explain your role visavis Atlas and how that works?
Yes, sure. Well, Atlas, as you say, eliminates The part of working with hardware and OAS Infrastructure. However, you still need people skilled With application database integration, with application tuning and all other aspects of Database maintenance and support. Again, it really Decreases the need for a system and maintenance and support. However, The database part is still there.
So this is where your database admins may come handy.
Great. And I guess a general question for everyone. Obviously, serverless is a new theme now with databases. I'm just wondering what's your approach to serverless? Have you started thinking about how you may Obviously, we're in a preview mode, but have you thought about like how Surplus 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 The ability to not think too deeply about the required scale and to Predict your traffic. And that's something that is sort of embedded within across our entire stack. Like a lot of our services Our host 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 for I think the use case around Like 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 Surless, Oleg or Jurgen?
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 New environments in 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 1 and start using it and even close it as soon as you don't need it This will make a development workflow very flexible.
Great. Well, I think that's enough time for questions. I want to thank our panel For their time and obviously their support of MongoDB. It's very much appreciated. And what I'll do now is hand it back to Mike.
Great. Thanks, Dave. Appreciate it. And thanks to Oleg, Gergen and Trevor for sharing their perspectives and for their We 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 developers 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 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 is an industry analyst firm and they evaluate tech trends, particularly from the Spelled through your perspective of the developer. And so 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're good to go? I will assume that somebody will tell me if you can't.
So as stated, I'm Steve O'Grady. I'm the co founder of RedMonk. And Mongo has asked me to talk to all of you about sort of what developers want from a data platform, right? And inherent in that question is an assertion. And the assertion is that developers are sort of fundamental to that process.
And We'll go through a little bit why. So as mentioned, we have just
a little bit about
me and sort of where I come from my background. I was a systems integrator many, many years ago before founding RedMonk. So I ran around and did enterprise implementations of sort of all kinds of Software from databases to enterprise portals and CRM systems and all that. And one of the things that was sort of obvious to me, sort of even at that Time was that the sort of the typical coverage and the typical analysis that I had read and consumed As an analyst, it was very sort of dismissive of folks at the bottom of the food chain, the practitioners, right? And as we'll discuss in just a minute, that was not it didn't make sense to me sort of as time went along.
So when we I got together and founded RedMonk sort of way back when in 'two. The idea was, all right, why don't we sort of look at Who are sort of the influencers moving forward, right? So as sort of in addition to this, I've written a couple of books, one of them mentioned New Keymakers, which will I'll give you the sort of Cliff knows version of momentarily. But essentially, RedMonkey, you can think of essentially as the embodiment, the analyst firm embodiment of that idea, Right. The developers are in fact the new key makers.
So 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 cliff notes version. But if you sort of think about some of the points on the timeline here, Right.
So Linux was introduced by Lenis Torvalds 1st in 1991. Salesforce was incorporated in 1999. AWS sort of famously generated the cloud industry in 2006. Apple introduced the App Store 2 years later in 2,008. And then Coursera, edX and a couple of other educational institutions, followed in 2012.
Now the obvious question is, What does sort of education in app stores have to do with open source or software as a service or infrastructure as a service, Excuse me, a little on databases. And the answer is essentially that they all these things collectively empowered the individual And more specific to our cause here, empowered developers. So when you sort of think about it in the old days, certainly when I was an application developer, sort of way back before the turn of the century, If I wanted to get any software, I had to go talk to somebody and get a license. I had to typically go through procurement channels to get it. I certainly had to do that for hardware.
I certainly had to do that for applications. If I wanted to sort of educate myself on a given topic, I would end up having to try to go and beg for some budget to go to a course somewhere. And I certainly didn't have a direct route to The App Store, I don't know what the percentage is
at this
point. You folks in the financial community probably know the actual number better than I do, Quite a huge swath of sort of the world's population from a commercial marketplace standpoint. And these days, obviously, that's not the case, Right. I can go and get any piece of software I want, typically, for I can download it and use it for free. I can get applications clearly.
I have really any kind of storage or compute or other primitive available to me. I do have these direct routes to consumers and I can educate myself, right. And what this is all sort of led to is An era where developers are empowered individually in ways that they never were previously. And this has led us to sort of the world that we see every day. So what we do every day sort of at RedMonk is, I'm sure similar to what many of you do, which is we spend our days talking to other businesses and the developers that work for them or the folks that sell them software.
And we end up seeing sort of time after time after time as a world that looks something like this. So, 5, 10 or 20 years ago, certainly, the world that certainly I came up in was very top down. It was sort of somebody at the top of an organization, typically a CIO, will make decisions sort of about what gets used. And that then is sort of imposed from the top down to the practitioners at the bottom. These days, more often what we see is what developers want to use is what actually gets used.
This is essentially The reality in most enterprises today, and importantly, this is true whether they realize it or not, right, because I can't tell you how many times over the years I've had conversations with CIOs or other folks at the top of the technology org chart in large enterprises who will sort of Definitively assert, oh, we're not using this piece of open source software, we're not using this sort of software as a service application, we're not using this cloud And uniformly, they're all wrong. And again, there are any number of anecdotes that we could talk about sort of that speak to this. So again, this isn't a theory, right? This isn't just us sort of RedMonk sort of the small analyst firm saying this. You hear this exact sentiment From some of the vendors that are sort of leading the pace in the industry, this is a direct quote from Andy Jassy, I believe it's 2018, re:Invent speaking about The role of the developers, the foundational and crucial role that developers played in Amazon's own success.
And I certainly don't need to tell any of you Sort of what that's meant to the world. So developers are important. Okay. I think we can probably all agree that that's the case. Hopefully, that's not a terribly controversial opinion in 2021 the way it was certainly when we started the firm in 'two, people thought we were insane.
But then the question becomes, all right, what do developers want? And any of you who are developers, who have done application development at some point in your career, Any of you have spoken to developers, sort of know any personally, what developers want is to go fast. Programming is sort of at heart an intellectual pursuit. It's about solving problems in sort of in creative ways using code. And when you're a developer, what you're looking for is that next sort of dopamine hit, that next problem to solve, Which means that you want to go, go, go.
You want new problems to solve because that's ultimately sort of what is personally satisfying for you. Now at times, of course, this can lead to sort of the old Facebook Maxim, move fast and break things. And that is Absolutely. Sort of not what sort of developers, frankly, or certainly the enterprises they work for want. But that led to sort of what enterprises historically wanted, right?
What the enterprise that employed all these developers wanted For most of the technology industry's history was to basically move at this sort of glacial Horse and buggy pace, because enterprises typically associated speed with risk, not without some foundation, To be fair. And this was the status quo in the industry for essentially, as we discussed, Most of the technology industry's history, right? This was just the sort of world that we all inhabited, that we all lived in. It is not, however, the world that we occupy today. For a variety of reasons, which would take certainly more time than we have here today to discuss what enterprises want most today is to move fast.
They want to sort of operate As high a velocity as they can. And this is we mentioned reasons. One of them is certainly NSA, I'm sure you've all read and are familiar with Mark Anderson's sort of famous software leading the world. But whether or not it's Sort of digital sort of startups that are threatening businesses. The fact is, is that even the incumbents themselves are all operating more quickly And therefore applying competitive pressure to each other to do so.
So basically, the sort of prize, the important thing at this point is to move more quickly. So this is a conversation, taken verbatim from a conversation we had with 1 of our large clients In a different sector, but under some of the same competitive pressures. And what we told them is exactly what you just heard, Which is what we're hearing from literally every enterprise is that the top priority is velocity. Now importantly, they don't always use that language, Right. They won't always say speed or velocity.
They might couch it in terms such as digital transformation, Right. But when you boil it down, when you actually talk to them, what do they mean about digital information, ultimately what it comes down to in most cases is speed. Because if we had that conversation about digital transformation 5 or 10 years ago, it would literally mean that. It would literally mean taking these 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 digital native would, right? And you see this over and over. For example, you can have the same conversation with Technology executives who are prioritizing agile, right? What is agile? Why is that important to them?
Typically, when you boil it down, when you get down to it, the priority is velocity. So ultimately, when we have conversations with Enterprises, and this is true across sort of any category, any sector. The priority the number one priority for them is moving more quickly. So 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, right?
We are in that case, it was part of 1 of 6 messaging pillars that they were going to take to market. These are the 6 things that we think sort of enterprises care most about. And what sort of interestingly happened was that they call us about 2 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. And then they come back 2 months later and they said, hey, we'd like to sort of revisit that.
Can we have a conversation? And said, sure, what happened? And I said, well, we went out and talked to our customer advisory board, which is all Fortune 100 organizations from pick a category, media, FinServ, manufacturing, pharma, on and on and on. And they said we were wrong. All of the priorities that we From this customer advisory board was Velocity.
That was far and away the most important thing to everybody that we spoke with. And we're going to reorient Effectively all of our messaging around that idea. So if we could accept, even if just for the sake of argument, that the primary goal, The sort of front and center opportunity for most enterprises is speed. The natural question then is, what is it the developers sort of need or want, as it were from a data platform, Right. So, okay, we want to move more quickly.
What role does the data platform play in all of this? And more important, obviously to all the Financial analysts on the line listening. Well, what does this mean in terms of who the winners and losers will be of that platform? One of the things that we sort of lead off with when we have these conversations is, developers want a data platform that's as modern as their app platform. So this to me is really under covered, under understood, if that's a word, sort of fact in this industry, Which is essentially we have remade completely the way that we build and develop applications.
As I mentioned, I was an application developer once upon a time In the 20 years ago. And the process that developers use today to build, test, produce, Remediate their applications looks nothing like it did, literally nothing like it did when I was sort of getting paged in the middle of the night. And virtually all of those improvements and all of those changes have been made, whether that's tools, process, methodology, culture, All of those changes have been made in large part to make the application development side of the house as fast as possible, right, to get changes Through approved, tested and out and remediated if necessary with as much speed as is humanly possible. On the data side of the house, however, the way that companies are typically working with their databases doesn't look all that different, Right. That sort of data platform mindset that persists within enterprises today is Certainly, in sort of need is some updates.
And so the question is, what kinds of updates? What are they looking for specifically from the platform? So one of the things that we hear over and over and over from developers is that they want a platform that gets out of their way, Right. And this has historically been a strength of Mongo. I probably don't need to tell any of you that.
In the sense that Historically, if you had to work with a relational database, you're building an application, you might have something called the object relational mapping layer, Right. So essentially, that's just a layer that sits in between the application and the data that allows the application to Deal with the data in the way that it's designed and the database to do the same. And it's a hassle. It's an additional layer of software that you shouldn't need. And yet, this was kind of the way that things were done, because in the olden days, it was the answer is relational database, now what's the question, right?
And what developers want is that they want something that's simpler, right? They want this platform to get out of their way. They don't want to, As another example, have to define and fix and cement the scheme upfront, and sort of deal with this. So when you take platforms like a Mongo, 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 and fix it sort of upfront, allows you to sort of do ad hoc queries and so on.
These are the kinds of things that developers are typically looking for from sort of their data platform of the future. Likewise, I cannot tell you how important this is. And certainly, I think the financial results of Mongo's Atlas platform, I think speak to this in spades. But developers want a data platform that they do not have to operate. I Cannot stress this enough.
As a developer firm, we spent a lot of time with a practitioner that led us pretty early along to understand the importance of managed service platforms. And we've been advocating as far back as 'eight, 'nine 2 database companies of all shapes and sizes that look, you need managed services operating because this is the way things are going. And 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 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.
And like I said, this is certainly the same opportunity that Mongoose perceives With respect to its Atlas product line. And then lastly, this point was made, I believe, in the Q and A, Or actually just prior to the Q and A, which is the versatility sort of a platform. The technology industry, like a lot of industries, is basically has a pendulum that will swing from one end to the other and back and forth and back and forth it goes. And we've come from an era of general purpose relational databases that were used to solve every problem. Again, it's sort of the answer is relational database, now what is the question.
And that proved to be An insufficient approach for many of the workloads that we saw today. So the pendulum swung way in the other direction. And then we had sort of a database for every last Tiny sort of workload under the sun. And all of a sudden, you talk to developers, architects, Operator is Ethan. And they were looking at this and saying, honestly, I missed the days where I only had one database choice to make and one database to 1 database to sort of learn and manage over time, because depending on sort of the nature of the application and what you're trying to do, You might have 2, 3, 4, 5 different data storage mechanisms involved in a single application, Which was, let's just say, unwieldy at best.
So what we've seen in recent years is sort of a new found 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 asset transactions to make it a viable transaction platform. More recently, they've gone the time series routes. You've seen them all add Support for large scale data operations in data lake, search and so on.
So the net is that if you go out and talk to developers today, 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 like basis, whether I just want sort of a web front end, a transactional application, whatever I'm doing, I would prefer sort of in a perfect world, a single API, a single platform to handle all that. And as I said, clearly this is the direction that The Mongo has been heading.
So as far as predictions moving forward, you are all in the business of predicting that, just as I am. And I think it's pretty clear to me, sort of which platforms are prepared for this new world That prioritizes velocity and hopefully it's clear to all of you as well. So with that, I'm done. And I'm not terribly difficult to find online. I don't believe we have time for Q and A today.
But if anybody has questions after the fact, Feel free to hunt me down online. And with that, I will pass it back.
Terrific. Thanks, Steve. Thanks for your insight and your perspectives. Next up, we're going to hear on the partnership front from Alibaba. As you will recall, we announced a 5 year partnership with Alibaba back in late 2019.
Alibaba, by virtue of that agreement, became the 1st company to in China to offer an official certified MongoDB as a service offering. In terms of the mechanics, what that effectively means is that MongoDB is licensing sorry, that Alibaba is licensing our technology and offers their database service to their customers, and we are in partnership with them. We provide technical support and are also increasingly working with them on the go to market motions in China. We're honored to have Fei Fei Li from Alibaba Join us and share his perspectives. Obviously, given the time zone difference with Fei Fei being in China, we were unfortunately had to Prerecord this live, but I think it's a lively conversation and a good one.
And Fei Fei and the whole Alibaba team have really been great partners to So with that, let's roll the interview. Well, let's get started. Maybe just you can help everyone, Fei Fei, And introduce yourself a little bit to the audience and say a little bit about your responsibilities at Alibaba to give everyone a little context.
Yes, sure. Hi, folks. My name is Fei Fei Li. I'm currently Vice President of Alibaba Group. I'm also an ACM Distinguished Scientist.
I'm in charge of the database product business unit of Alibaba Cloud Intelligence, which is one of the largest Cloud vendors in the business and I'm also the Director of the Database and Storage Lab for its research branch, which is called the Daimler Academy. I have won multiple awards from HUE and ACM for my contribution to the database and large scale data management systems. And I've been associate editor, PC chairs and core community members for many prestigious journals, conferences, tech meetings and organizations in the field. So I have led the team of Alibaba Cloud to build cloud native database systems And products at Alibaba Cloud, including our RDS Services, Cloud Native Additional Database, Polar DB, Cloud Native Data Warehouse, Analytic DB, Cloud Native, Multi Model Database, Lindor, among others. I'm a member of Many database and big data committees.
I'm really, really excited of coming to today's conversation with Michael and MongoDB.
Terrific. Great. Well, maybe, Viphi, you can tell us a little bit about the usage and popularity of MongoDB in China.
Yes, totally. As a matter of fact, MongoDB is one of the most popular open source databases In China, not only is GaN's 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, A cloud version of MongoDB. And it's known as the programmers' favorite database here in China and in the APAC Asia Pacific region. We have a wide range of enterprise customers and application in China, including gaming, social networking, e commerce, Live online, new retail, online education, finance, IoT, governments from all this, a broad range of segments. And we find many, many enterprise users, developers, DBAs, a big fan of MongoDB and it is one of our main products Alibaba Cloud Database platform.
Terrific. And then so 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. Maybe you can tell people Why Alibaba decided to do that?
Well, as I mentioned in the last question, MongoDB has a huge user base from both enterprise users and among developers here in China and in the APAC region. I think it's a mature open source system with a very mature and active ecology And it has a rich experience in its market development. And Alibaba Cloud has a long term Thank you, Shankh and have a very good market share in China and in the entire region. In fact, we are number 1 Cloud vendor in this market. So we see a great and huge demand for MongoDB to offer MongoDB as a managed Service on Alibaba Cloud, a database platform, which enables enterprise customers to quickly Complete their digital transformation using MongoDB on Alibaba Cloud Platform.
They manage the version 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. And it's a win win for both sides, for both Alibaba Cloud and for MongoDB because with the help of MongoDB, We are able to offer the latest and best version of MongoDB, which is one of the most successful enterprise level database products out there on the market. And for MongoDB, with the help of Alibaba Cloud, MongoDB can penetrate and serve more customers In China and in the API region and serves them better as well with our platform and our service team and our engineering team. Would you share your perspective on why MongoDB choose to partner with Alibaba Cloud as we have?
Sure. Yes. No, it's very similar logic. We saw incredible amount of developer interest in China. China is one of the largest markets For downloads of MongoDB.
And while we have a sales force that sells the enterprise advanced products, we couldn't sell Atlas in China. And so we were eager to find a way to offer a cloud product. Alibaba is clearly the leader in cloud services in China. And so it was important for us to be able to Partner with the leading cloud services provider. And that really was very valuable and important to us.
And Alibaba has extraordinary Technical skills, it's not just the go to market. The go to market is very important for us in terms of making sure that there's a partner who can Popularize or capitalize on the popularity of MongoDB. But the technical skill is also incredibly important. The ability to run Services at extreme scale, which the China market demands and which Alibaba has proven, Really was a great fit and a great compatibility between MongoDB and Alibaba, and we were very eager to form the partnership.
Thank you so much, Michael, and thank you for your trust.
So Fei Fei, you're someone who understands databases extremely well. Tell us about your first experience with MongoDB.
Yes, hopefully. So I've been a developer for many years Myself and now managing the Alibaba Cloud database platform, serving a large number of customer base and managing a large number of engineers. So I will answer this question from 2 perspectives. 1st, being a developer, I've been using relational database for my development for many, many years. That I noticed important and very upfitting 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. And then I noticed the introduction of MongoDB, and I tried MongoDB Replacing our relational database for some of the application code I have written. And I noticed that whenever I need flexible Skiva Management and dealing with large, small 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 Right. The same application on top of additional database, coding on MongoDB is much more easier.
And the performance of the application becomes Much easy 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 gave you flexible schema design. It gave you ORM layer in order To interact with the object inside the database, and the sharding feature of MongoDB allows you to scale out You have a question without worrying about concurrency control, distributed transactions and those very complex Tech jargons.
And as a user, I interact with many enterprise users that we are serving. And the all Chris MongoDB for its flexible data model, especially for dealing with document data types using the JSON data structure. And all in all, to summarize, I think MongoDB is extremely well designed Database system for the next generation applications. And with the new features MongoDB has been Pushing out to the market. I think it's a very good and among the top choices as far as I can tell, among the developers and users that we have for cloud native for building cloud native, modern model applications.
Great. Thank you for that. And maybe you can elaborate a little bit more. What do you think are the core advantages of MongoDB versus other technologies?
Yeah. I want to talk about from I think there are many, many advantages that MongoDB has. But I will emphasize From 2 different aspects. 1 is the agile development that MongoDB allows and enables for the developers from a developer point of view. The object oriented JSON data model and schema free model can avoid the pain of changing the table structures, Having new data introduced to database late in the development cycle and it saves more than 60% of the development time Due to this flexibility that MongoDB has and it's gracefully shorten the release cycle and support rapid Business iteration changes.
CICD, continuous integration, continuous development has been the norm for today's cloud native application development. And MongoDB positioned itself really, really well in this market for our developers. That's from the developer perspective. Now from the end user and customer point of view, I think the cloud native And the flexibility features that MongoDB has offered has attracted a huge amount of users and applications. Flexible development architecture is supported, such as you can choose between single node A replica side of the fragmentation cluster, when you deploy your application running against a MongoDB database.
It suits the needs of different business scenarios. For example, single DB simple node For test and development purposes, Martinode Replicate Set ensures high availability for financial level services. A lot of our Customer from the finance sector actually use the multi node replica set so that you have highest level guarantees on RPO And RTO. And Recognition 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 support your business growth.
And under this mode, it also supports distributed transactions, Sync's version 4.2, which is also available Alibaba Cloud Platform, which provides a one stop solution for scaling out and Distributed transaction processing for your application. I think all of these unique features and advantages that MongoDB has It 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, Fei Fei. Maybe you can talk a little bit about how Alibaba and MongoDB are working together to try and the growth and capitalizing the opportunity of MongoDB, a managed offering, MongoDB as a service in China.
Yes, we are proud to be the 1st major cloud vendor that has reached a partnership agreement With MongoDB. And since the formation of the partnership with MongoDB, I think we have seen tremendous growth for MongoDB as a managed service on Alibaba Cloud Platform. So some of the things we have done. In terms of Customer Development. MongoDB has set up a CPM, which stands for Cloud Partner Manager Team in China, which is responsible for coordinating the resources of MongoDB and expanding customer projects jointly with Sales and engineering teams of Alibaba Cloud, so that it allows us to continuously create value for customers And increase the revenue of MongoDB products.
And this, of course, expands to areas outside China, Especially in the APAC region, Asia Pacific region. We have a huge market presence in the Southeast Asia region and among others. And the CPM from MongoDB has greatly enhanced and helped our team to better our to better serve our customers. Now in terms of secondly, in terms of product R and 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 burden on Alibaba Cloud. For example, we introduced engineering features that Allow tighter integration of MongoDB as a managed service with our DDoS, database as a service platform running on Kubernetes on Alibaba Cloud, which creates a lot of new value for our end customers.
Lastly, in terms of ecological construction, Several members of Alibaba Cloud database team have played a core role in MongoDB's community development. We have, of course, working with MongoDB team closely, we have built community With our customers, with our developers here in China, for example, we organized MongoDB Meetup 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 entire region. Those three aspects summarize how We are working together as a team to maximize and foster the growth among the BMS service in China in the impact
No, I think that's right. I think it's been a great initial period so far. So thank you for all that. Maybe I could also ask you to share a little bit of the feedback that you've been given or that you've heard from your sales force about the Appeal of a managed MongoDB as a Service offering among enterprises in China.
Yes, totally. It's interesting you asked this question. Just looking at the revenue numbers, which I can see here because I'm leading the Alibaba Cloud database team, I know the sales are going really, really, really well. But on top of the sales numbers, of course, it's important to listen to the feedback from the first line salesperson. So according to their feedback, I think MongoDB is very, very popular among enterprise customers, especially in certain segments, such as in the gaming and online education sectors, in the IoT sectors, in the finance sectors, Among others, and it has a huge advantages due to the features we have just mentioned, such as The convenient and agile development, the flexible schema support, the multi model data types, The cloud native features with high availability and scalability among others.
And it's been widely used in business scenarios such as operations, gaming, online education platform. And in the latest effort, we see a great demand and huge customer needs From the IoT sectors, such as mobile industry, from the both manufacturing side and also from the When they produce the car, when the car is running on the road, when you need to manage those data in real time, I see a great demand for MongoDB as well. So in summary, I see great potential and is we already tapped 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, so MongoDB is a global company and it's one of the leading global database company. Can you share MongoDB's investment plan for China's Going
market? Sure. Yes. No, I'm glad you asked. So as you mentioned, thanks to the partnership with Alibaba, we've made some pretty significant changes to how we approach Go to market in China.
In the past, we've had a team that was really focused on selling enterprise advance to enterprises in China. But given the strong early results we've had so far with Alibaba's managed offering, we've decided to diversify this And we've added this cloud partner manager role that you mentioned earlier, which is really focused on selling and helping Alibaba sell Management MongoDB. They work closely, as you know, with the Alibaba sales force. They provide enablement and to make sure the teams are sort of effectively coordinating and that the value proposition of Alibaba's managed MongoDB offering is Clear to potential new customers. Obviously, it's early, but I think both of us have been really encouraged with results I know we have.
And also really importantly, the collaboration between the two companies continues to be very strong and only get better. So it's early, but we're very optimistic about the market and what we can accomplish given the incredible market opportunity that the 2 of us have.
Likewise, I share exactly the same thing. I'm super excited about the partnership. I really, really I'm looking forward to the next phase of
Likewise. Well, I know we're up out of time here, but Fei Fei, thank you for your leadership personally. It's been great to get to know you over these couple of years. Thank you, Alibaba, for everything you've done and including participating in this session. And I look very much forward to when we can do this in person again.
But thanks for everything.
Thank you, Michael. You've been a very, very good business partner and a very close friend of mine. So Thank you for everything you have done, and I look forward to meeting you in person in Shanghai. I will send my invitation again. We will make sure you have a wonderful trip with the rest Mango team, whoever you want to bring here.
I really, really look forward to that.
Yes. And I look forward to seeing you again, and hopefully, we can do that soon. Thanks again.
Yes. See you again. Thank you. Bye bye.
Take care.
Okay. And now I'll transition from me back to me. So it's great to hear from Fei Fei though. And as I mentioned, they've really been terrific partners. So next up is our Q and 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, but there's still time, so please do submit those. Brian Denue from ICR He has been monitoring them, and he'll sort of act as our moderator for the questions. He'll read them as well as who they come from.
And Dave and Mark and Here and I will all be on the line in order to answer for them. But before we dive into those, we'll give you a little bit more time to submit questions. We want to play one last Video so you can hear from 1 more customer.
The Weidner 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 the kitchen transformation. All our components, all our infrastructure is in the 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
The data was never designed To be streamed to the Internet. And the second big challenge was we underestimated how our partners will adopt it And how many devices will be connected? In what time frame?
And after You recognize that our system will slow out.
We have to scale up and down our cluster nearly Every week to keep all 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,000,000,000 records.
We started in June 2018 and said, we have to implement everything and integrate until end of August Because we are going live with our product in September, everybody said this is not realistic.
Our migration really took about 90 minutes. We just had to switch our services from one connection string to another connection string, And it was there.
And it's a result of any downtime. We gone through the manager. We said, We are finished. Then we opened the fridge, some beers and did a little bit of party because it was So easy.
And we did this with an enormous saving in memory, Especially in index and also increased the performance of our API. And so that was, for me, the big moment 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% optimization is This is so good approach. And I also never thought this, that the benefit would be so great. This 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
Great. Thanks, Michael. And we'll start our first I'll take the start of the Q and A now. We'll take our first question from Raimo Lenschow at Barclays. You announced a long list of new product announcements earlier today.
Which one is the most exciting for you as a team?
Well, I may ask the team to respond. So maybe I'll start with Sahir.
I think it's tough to ask a Chief Product Officer to choose which is the 4th announcement. But I will say, We talked about the individual announcements when Mark went through kind of the value proposition for customers. But what I think is exciting for us as a company is The combination of the serverless consumption model, the versioned API that allows customers to non disruptively make database Changes to the application. And then 3rd, 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. And so this is more of an internal lens, but I'm personally excited about what that allows us to do for the long term of the architecture and the value we can bring to customers.
Mark, you want to add to that?
Yes. I've been thinking about the question while Sahir answered. I wear 4 hats. From my business hat, I feel like it's all about serverless. From my CTO hat, it's all about time series.
Time series is so complex and such A cool achievement for the team. The scientist in me loves charts on data lake and the ability to do analysis on data anywhere in any data store you have With one pane of glass. And then I got to tell you, the engineer in me has been so frustrated with my inability to develop on Android that Dart makes me very, very excited So I can now cross develop on Dart, on both iOS and Android. So I guess that's 4 favorite children.
And Michael, do you have a favorite?
I'll give a shout out to FedRAMP just for something. I mean, I agree with everything we see here, Mark said, but I'll give a little shout out to
Great. I think I am similar to Sahir. I mean, one of the things One of the announcements I really like is live resharding. It really just puts an exclamation point of the fact that MongoDB is so far ahead of the market in terms of data distribution And scale, I mean it's just not even close. The second thing I would say kind of aligned to what Siyir said was what we're really trying to do is make the database We're just trying to make it easy for developers to use a database when they need it without having the All the cumbersome and tedious tasks of how to work around a database come into their world.
And the more we do that, the more we make the development experience Amazing. And the more people want to use MongoDB as their backend data store. So that's why I'm super excited about the announcements. Brian?
Great. Thanks, Dave. We'll take our next question from Jason Ader at William Blair. It feels like the database market is getting more fragmented versus less. How do you think what
do you think will
be the catalyst for greater consolidation in this market over time?
Yes. When I joined MongoDB, there was no clear winner in the old term of the NoSQL of the modern database space. There were a lot of Horses in the running. I think nearly 7 years later, it's become clear that we are by far the largest and the fastest growing modern database And the most popular modern database in the world. I think when that happens, customers start getting more and more comfortable making bets on a single platform.
In In the past, you have the bozo issue where customers didn't want to look like a bozo by picking on the wrong technology. So they'd actually be skittish about Obviously, I want to really bet on one particular new technology. Now with almost 27,000 customers, The developer mind share that we have around the world, obviously our financial performance, MongoDB looks actually like a safe choice. No one's going to start questioning why MongoDB, especially when we have people using us for such a wide variety of use cases Across different industries and geographies, MongoDB becomes an easier choice for people to make and we're seeing that in our customer base as we continue to expand inside the environment. So that being said, I also think customers are recognizing that 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, Dave. We'll take our next question from Brad Reback in Stifel. Mark, this one is for you. Can you talk about why Oracle hasn't been able to address this market?
And what do you think has held them back Technically and culturally for moving to a next generation platform.
I worked at Oracle for 13 years and there's a lot of truly brilliant people there. But I will just tell you right off the bat that the thing that is hurting them right now is their culture. They are not customer obsessed. There are smart people there, please know that, But they are not customer obsessed. Every customer they come into ends up feeling awkward or even downright scared to work with them.
The other thing that's wrong there is that they are wed to their 3,000,000 line monolith. And by the way, it was 3,000,000 lines when I stopped working on it in 1996. I don't know what it is now. And they're wet. They can't break it out into different products.
And 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. And so I just don't think they can get out of their own way, frankly, either technically or
Great. Thanks, Mark. That's helpful. May I take our next question from Steve Koenig at SMBC Nikko. We've got 2 ones here for you.
Just first, any update on the adoption of newer products Like, Realm and Data Lake. And then with the release today of MongoDB 5.0, does that open up any key new use cases For the platform.
Sohir, why don't you take that one?
Yes, absolutely. So we've definitely seen an inflection point in Adoption of some of the new products that have 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 Get those early developer wins. And I think in the last 6 to 12 months, as we've got into production with those applications, we've certainly seen higher scale.
Now in terms of new use cases that we're going after, I definitely think we are expecting and excited to You'll hear from the beta customers we just engaged with on the time series implementation. We do see industrial IoT in particular as a segment of the IoT Market that is increasing in importance. And so that's clearly why we invested, but we got a lot of feedback there. That's one kind of pocket of use cases we expect 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 the sub segment of the gaming market, which is actually the fastest growing as well. So now we provide an end to end architecture. So I think those are the 2, I think off the top of my head, worth calling out as potential interesting areas for new workloads for us.
And then, anyone update on the adoption of Realm and Data Lake?
Yes, definitely. On the Realm side, I think we've seen a real fit in retail use cases, in particular, Situations where customers are want to have a local individual sitting in a store managing local inventory, but may have A flaky connection, how do they synchronize that globally across multiple franchisees in some situations? So we've seen quite a bit of an uptick In particular in that vertical and 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 are seem to really be getting traction. 1st and foremost is clearly data tiering.
So customers, especially some of the time series customers that we're working with, need to keep an immense volume of data accessible, but don't want to pay the Cost of storing that or in a core operational database system. So the online archive capability, which Data Lake powers has been certainly The first I'd call out. The second is more of a data engineering oriented use case where we're seeing customers Dump any number of different styles and formats of data into, in particular, object storage like S3. And so you may have Files that are generated for 10 different systems, all landing there in sort of an S3 data lake. And what we've been able to do is use our Query Engine to be able to ingest that data, transform it and operationalize it on a continuous basis for customers.
And that was one that just sort of organically started happening once we let our data lake out in the hands of our customers. The third is more of an emerging use case, but one that I think is increasingly important for analytical workloads in the future is federated query capabilities. And what I mean by that is We're seeing customers combine a single query where they have multiple databases that they're querying at once or a combination of databases And data sitting in an object store where they want one unified result set to be able to merge different data sets together without having to ingest and dump everything together in a single So those are the 3 emerging use cases that we're seeing with ADL, both integrated with the database as opposed clearly independent.
Great. Thanks, Dheer. To our next question, actually, this is a few different people have asked about M and 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 your the future, just larger M and A to accelerate time to market, Something that the company is considering.
So maybe I'll start and then I'll ask my team to add on if necessary. We don't have any plans to go acquire a niche NoSQL or other type of database. We think and as part of Sahir's presentation, we think it's really important to for a developer to have a seamless unified experience when they're trying to build applications for a wide variety of use cases. So by definition, trying to bolt on some third party solution onto MongoDB, we actually impede The goal that we're trying. There is a possibility that we could use M and A to expand in some adjacent markets that we're not in that are maybe adjacent to The OLTP database, but again, we're not we have no plans to do so there.
Historically, what we've done is surgical acquisitions. We've Acquired technologies like Wiretiger that really helped accelerate broad based use of MongoDB. We've made acquisitions like Mlab and we've done other things like Realm as well, which expanded to new market. So you'll see us probably do more of those things. But clearly, there's a lot of interesting things going on.
One thing I would say is that I think what's Clear is that companies like MongoDB have proven is that best of breed vendors can not only be do well, but be very, very successful and then grow into large companies. And we want to be a best for me vendor that offers a wide range of capabilities to customers and that's our focus and both from an Organic front and potentially as part of M and A. I
would maybe just add to the comment and the question in the chat. Part of what Mark and Sahir were getting at is this whole concept of the document model being a super That is before we introduce time series, you might have said, oh, should you go introduce buy a time series company or before we introduce graph capability, should you go Biograph database, I think it just sort of underscores the point that the beauty of MongoDB and the document model is as the superset Of the models, there isn't a need to go buy the consolidation argument there. So it doesn't really make sense because we've got the product capability just to do it organically with MongoDB rather than having to try to bolt something else on. And so I think from an understanding and approach perspective, hopefully that's helpful.
Great. Thanks, Michael. Next question comes from Jack Andrews in Needham. I want to discuss your move to quarterly release cycles. How does it impact your internal product teams as well as the ability as 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.
Mark, you want to take this one since you're on the engineering?
I think it's a 2 part question. I will take the first part and then, Tahira, you can take the roadmap piece. So look, the reality is, is that developers love shipping code. Having the code actually sit there for the last 9 months of the year was just frustrating everybody. So we did have to clean up our internal processes to test better, to do a lot of stuff better, to automate even more than we'd already automated.
But from an engineering point of view, I just got to tell you, the engineers are delighted with moving to quarterly releases and our testing and automation and release teams are as well. Now, Sahir, do you want to talk a little bit about the roadmap impact?
Yes. I think there's a couple of facets to this. And we have a very diverse customer base, As you all know. And so 1st and foremost, we wanted to make sure we were predictable and that every year we were shipping and continuing to ship an annual release that had long term Because especially for our on premises enterprise customer base running in their own data centers, those Upgrade cycles are still very conservative and oftentimes take multiple years. So we needed to maintain that sort of characteristic of predictability of an annual release.
However, on the Atlas side, especially, we've been updating capabilities in Atlas on a 3 week cadence for a long time. And many of those customers that are very agile were saying, we'd love it if you could get core database out to us sooner, even if it's just for development and for testing environments rather than waiting for this annual release cycle. And so what this Approach of having a versioned API with quarterly releases does is it allows us to give customers choice. So if they want the ability To be an early adopter, use a capability as soon as we're ready after testing to ship it. It gives us a much more granular way to get capabilities to market sooner.
But at 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 point 0 releases like Vivo. So we really spent a lot of time thinking through how we meet Both needs of the market because what we see is a lot of technologies make customers have a trade off, either you're very aggressive and you're getting the latest capabilities as soon as They're not ready or you have to wait a full year and oftentimes a lot of internal testing to get there. We're meeting both of those ends of the spectrum.
Great. Thanks, Yaron. Super helpful. Next, we've got a bunch of questions on serverless. I'm just going to kind of summarize the topics here.
Can you talk about your vision for serverless? How you expect it to be adopted by customers? Will it open up new use cases that I know it hasn't been used for. And how do you think about the impact Cerbos will have on the growth of Atlas over time?
Yes. So maybe I'll start. We actually think serverless is incredibly additive to our business. Remember, it's part of our strategy to really get the database To get out of the way of developers, developers don't have to pre think what kind of capacity they need on the back end. Literally, they can just Point a URL to our database and just go.
And so we really want to make the developer experience As easy as possible. The other thing that this does in terms of additive use cases is that it It suddenly makes spiky workloads. The workloads are very intimate in nature, very attractive to deploy on Atlas. So things you heard one of the customers in 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. But it's all about just making MongoDB so much easier to use and Atlas so much easier to use that they don't have to pre think How much capacity do I need?
They don't have to worry about seasonal spikes in their business. All that is taken care of them at the back end. And 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, Dave. 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 The dynamics of an application and there are many customer needs for which a dedicated database cluster where you need the isolation, the predictability, The performance guarantees, etcetera, is desired, especially in regulated environments or more conservative accounts. And so we view Serverless, not as sort of a new product alternative to what we 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. Can you We lost that one for a second there. How do you square the argument that relational tends to ever be modernized with the The largest software API in history uses a relational data model.
The Postgres continues to be popular with the development community.
Mark, why don't you take this one since you obviously come a lot of perspective on this topic?
Yes. So I know the Postgres community well and it is a wonderful community filled with great people. So no harshing there. However, the problem is, is that it still has all the limitations of that legacy code base. So look at how they've implemented JSON.
And If you just have nothing left to do with your day, Google using JSON with Postgres examples, it is one of the most Contorted things you will ever see in computer science. And yet, they support JSON. So the problem is They're in this model that they've been in now for 20 years and they can't move away from it. They can't move forward. Now to that other question And then 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 1500 developers write another application and 1500 developers write another application. I talk to more than one CTO a day. I've talked over 400 Since I got here 3 40 days ago, and none of them are building these monolithic applications anymore.
In fact, all we ever talk with them about is breaking down the monolith, strangling the monolith and strangling and smashing the monolith. So I think the problem is that the paradigm has changed. And so the technologies for addressing that paradigm shift Are the modern technologies, not the old ones?
Yes. And I think I just want to add, Mark touched on this in his presentation, but Whether it's Oracle or Postgres or any other relational database, they still have the same fundamental limitations. They come to basically 3 things. 1, Developers do not think in rows and columns. As Tahir talked about, in object oriented programming language, you think about objects.
So think about decomposing an object into rows and columns is additional cognitive load for developer. The second biggest issue is that as you add more features and Your data model gets more complex and more brittle. So that chart that Shahir showed that the irony is that as you use it more, the harder it is to innovate. Whereas the reverse is really what customers want. They want to innovate more quickly as they get more traction.
And the third point is that relational databases are not designed for scale. So you have to figure out all these workarounds to scale your environment. Some people have tried to make relational databases suck less, But they still have real limitations in terms of data distribution, performance and scale. So for those three reasons, whether it's Wrapped in an Oracle brand or an open source brand like Postgres, they still have the same fundamental limitations, which is why MongoDB is getting so much Popularity because it's just such a different and a much better way to work with data.
And I'll just jump in and say, Dave, apparently you listened to the presentation, So thank you. That was awesome. And then I will also jump in with look at, for example, what Aurora did at Amazon with MySQL and Postgres. They couldn't modify the core database. All they did was put in a different storage engine underneath.
And you can look up the blog that says the Amazon Aurora So I ran Aurora Postgres, and for 6 years, I tried to modify the Postgres engine, and I was unsuccessful.
Great. Thanks, Mark. And then another one from Sanjit at Morgan Stanley. One criticism of NoSQL movement is that it empathizes consistency to achieve massive availability. Their Cockroach and others have been looking to bring consistency to the forefront.
How does Mongo view this initiative around bringing greater consistency to cloud data stores?
So I assume this is about the consistency of the data. I mean, or it could be the Or then applying the flexibility of the database. I'll assume it's the former, not the latter, but we can answer both questions. MongoDB has a tunable consistency model. So As Oleg talked about for Software AG, their IoT use cases, each individual data point is not that It's the trend of data that becomes more important.
So you want to capture data very quickly and eventually consistent model works well. But 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. And so the fact that MongoDB supports both It's a great example of how versatile MongoDB is. And then with regards to the schema, we have Rules around helping people define how the schema should set up. So flexibility is not like both 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. I don't know, Sahir or Mark, if you want to add more color.
Sure. I think the criticism around Lacking consistency in the NoSQL space or criticism around being a free for all around data governance and schema. I think by and large of the segment of non relational databases, it has been true. And I think Mongo has been the outlier where for the last 6 or 7 years, we've invested Heavily in bringing forward schema and data governance so that you can have control and enforcement where you want consistency in the data model and typing. And then also if you think about transactional consistency, asset guarantees, I think it's a little known fact maybe, but MongoDB has always been at strong Strongly consistent with asset grade guarantees from the get go inception of the database.
And then 3 years ago, we added multi documents. So once you're manipulating multiple objects in the system, the transaction capability to do so. And so in many ways, from the inception of the company, we believe that Just building an eventually consistent database wasn't going to be enough because we had the ambition to be general purpose and Be able to replace the core of many of these kind of mission critical applications. And that wouldn't be possible today, many years later, if we didn't have Similar thinking around strong consistency guarantees.
Great. Thanks, Seir. Time for a couple more questions. Take the next one from Kash Regan at Goldman. When a customer decides to stay with the legacy relational database, can you just talk through what the trade offs that they are making when passing on going with MongoDB, not All of the performance advantages you've outlined throughout this presentation today.
Mark, you want to take that one?
Yes. So 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. So that's really exciting there. However, as I said in my presentation, I was quite surprised when I came here That less and less people out of college have any interest in learning relational databases.
So I think the ship is coming over the horizon and it's going to be bad news. Now when you get to the technical side, you're going to be using either open source technologies or commercial technologies. Let's just assume for the moment that you're not enough to use commercial technologies that are costing ridiculous amounts of money. Even on the open source side of the world, The problem is that you're limited by very low innovation and you're limited by very low ability To bring in other pieces of software in the ecosystem. And you have to start bolting things together.
So when you look at what's going on in all of the modern data stores, We are 1 in which we listed a number of others. Connectivity and integration has been just a hallmark of the modern data stores Since day 1. So 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. And so it's I mean, you can do it. There's no doubt about it.
There are companies out there doing But it's probably not the path that you're not going to regret in 3 to 5 years.
Great. Thanks, Mark. And maybe we'll take our last question from Raimo again at Barclays. If you look at the cloud providers, in particular AWS, They're offering different databases for different use cases. Can you just talk about how far Mongo can go in offering all in one Experience is an alternative to the approach that AWS is taking.
Yes. So As Mark mentioned and Sujeer mentioned, we spend a lot of time talking to customers with 27,000 customers. As you imagine, we have lots of conversation with We have never heard a customer saying I want to use a net new database for a net new use case. The incremental tax of learning, Supporting, provisioning, querying and backing up all that data and all those different silos as part of this Sivir's pitch It just becomes over time overwhelmingly complex. So customer this is part of the I think it 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 1 to 2 options for the majority of use cases. So we think that there will be in every enterprise, there'll be a legacy standard, some relational standard and then there'll be a modern standard and our goal is to be the modern standard And 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. And We think Oracle I mean, sorry, Amazon's roots around wider selection at lowest prices. And while we work in e commerce doesn't necessarily work in databases.
Customers just don't want to manage and support 17 different database technologies. And so I think that's very easily verifiable when you talk to customers. And that's why I think why people are viewing MongoDB such an attractive platform. To the point I was mentioned earlier, the document model is a superset model, so it just enables A wide variety of use cases. And we feel like we're really well positioned to continue to be the general purpose modern standard for enterprise.
So do you mind if I jump in there a little bit, Dave?
Go ahead.
Look, the cloud Providers built these beautiful houses. They're made of concrete. They have great power. They have great water. They even have really great security systems that you can hook up to.
And these people build them and they're great and you can us. However, no one ever contracts with the contractor to build your China cabinet or your furniture. And that's where best of breed comes along. So the reality is the cloud providers build great houses. We live in them with our 27,000 customers.
But when customers come to us and they say, I want the thing that adjusts to my needs and I want it to be the best of breed product For what I need to do, they don't want to get a graph with 30 logos on it and in the middle is something called Glue that is a product that the cloud providers have had to create To produce their to glue their own products together. That's just not okay. That's not what developers want and it's not what enterprises want. And so I know I'm getting a little passionate here, but I've lived both sides of that argument. And the reality is figure out who you want to build your house and figure out who you want to build your furniture And where you want to put your China, which is your data?
Great. Thanks, Mark. Mike, I'll turn it back to you and Dave for to wrap it up.
Yes. No, I think we're right up on time. I just want to thank everyone for spending some time with us this afternoon. Hopefully, the announcements from Dot Live were helpful and then this incremental A session where you got to hear particular focus from Dave and Mark and Zakia on the product side of things to hear from our customers and understand where the product roadmap is going. We will look forward to talking to you all in several weeks and hope you're well between now and then.
And at some point, we look forward to doing all these in person. But thanks To everyone from the team and to our customers and everyone else for organizing all this. I really appreciate it.
Thank you.
Thank you, everyone.
Thank you, everybody. Bye.