Good afternoon, everyone. We're going to get started here. Thank you all for coming to our second annual Investor Day. Appreciate everyone coming. It's great to see so many familiar faces and some new faces as well, so thank you. If I have it correct, we're being live-streamed, so just so anyone knows, in case you have questions, we'll repeat that so folks on the bridge can hear. We've got a pretty packed agenda, but we'll try and run through everything. The key focus here really is on the customer side and on the product side.
Consistent with the keynotes and the product announcements you heard, we really want to try and provide some incremental insight and understanding about how are people actually using MongoDB, what do some of these products and features mean, and we'll go through a fair amount of depth and hopefully understand for a non-developer audience. Obviously, we'll have time for Q&A as well, and we'll look forward to getting into it. Without any further ado, I'm going to turn it over to I don't actually have a clicker, but Gary. Here's one. Thank you all for coming. This is probably a safe harbor thing. Oh, no. Well, just assume there's a safe harbor thing that shows up there. You're all familiar with it. You've seen it. You know it. It still applies.
With that, I'm going to turn it over for our first customer story for Gary Hoberman, Founder and CEO of Unqork, to talk to us about what Unqork does and how data fits into that. Thank you for coming, Gary.
Thank you, Michael. Okay. Can you hear me well? Yes?
There we go.
Yeah.
Yeah. Got it.
Thank you. Thanks for having me here today. Gary Hoberman, CEO, founder for Unqork. I started using MongoDB a long time ago. Not that long ago, but actually in 2011 was when I first started using MongoDB. I'm a hacker by background. I've been coding since fifth grade, punch card machines, my dad's business, and it was just amazing the art of the possible of what application software can do. Understanding databases and always looking for the best solution to solve problems. I get to give you a view of the world from the inside out and then outside in. Inside out meaning I spent 25 years in Wall Street corporate technology, Fortune 50 companies, understanding the pains and suffering of what it's like to get things done, deliver value.
With that, I was one of the youngest managing directors in Citi's Ops and Tech group, 500 developers working there before I jumped in 2012. Before jumping in 2012, I actually introduced Citi to MongoDB, and it became one of their solutions there. When I entered MetLife in 2012 as their global CIO with 10,000 developers across 47 countries, I actually had MongoDB onboarded before I joined on my garden leave, during my three-month garden leave, figuring it would take that long, and it did. The goal was to actually deliver value. Even in MetLife, I got to actually use products like Mongo to deliver real value in something called The Wall, which was featured in Fortune and Forbes and Financial Times.
The last years in MetLife, we used MongoDB the first time in Japan to displace one of the biggest database companies for a highly compliant sales tool for the FSA and 48,000 independent agents. That was the last time I spoke to a group of analysts. This was MetLife's Analyst Day in front of hundreds or thousands of people, and I got to actually do that. It's amazing being back here in this family though, because I was on stage, I think, during that time back here, and it was an amazing event. I'm going to give you a very brief history of inside out software. For those who don't know what it's like to build solutions and what it takes to get something live from an application level out, I'm going to give you the briefest history I could.
There's three generations of software build to talk you through. The first is going to be, it's building a house. It's waterfall methodology, step by step. "Hey, business, you want to live there. That's great. That's what's going to get you customers. That's your house. You're going to entertain there. It's great. The windows, the lighting, everything's going to be great. Guess what, business? We need to do this first. We need to sit down and plan. We need to have the architecture drawings, the diagrams. Where do you want the window? Where should the kitchen cabinets be? You know what? That's great. You signed off on all that. Let's begin construction." For the next three years, we're going to build this. Those walls, the two-by-fours, is code. Basically, software programming code.
At the end of that, the business walks through, and we're excited. We're like, "Here, three years later. It's good. Here's the keys." They're disappointed every single time. The business says, "The light's coming in the wrong place. The cabinets don't open the right way. What's wrong with you? You should have known this." We go back and we say, "Look what you signed off on. You gave us those requirements. You signed off on the spec." Suddenly, distrust between two groups emerges. It's happening every day in every company, no matter what industry you're in today. Along about 10 years ago, 15 years ago, software comes in, and NoSQL software comes in. The software packages promise the future. They say, "Guess what? You're going to basically go ahead and out of the box, this gives you everything you've ever dreamed of.
Just install it and use it, you're done." This is the application level above database. Every single time that happens, what happens? It does 70% of what you need, and the customization of that to do what you really want, results in a fragile, insecure system which does nothing for the business but sit there, and now it's termed legacy the second it's turned on. Another reality of life. The third generation of software, the one you hear most about, agile. It works amazing for small deliverables, small projects. It's great. Doing a large transformation agile is you and the business together putting up the walls. Let's do it together. We're partners in crime. We're going to do this great. The reality is, you're ready to deploy your first product, the business will look at you and go, "This is wonderful.
We're going live Friday, but there's only one story, and where do my kids sleep? Where's the plumbing?" We, IT, say, "Look at the backlog. It's all there. Don't worry. It's coming later." It never comes. Introducing to a little bit as to how the generations happen and what we actually do to get here. What we say in Unqork is there's a better way. We're calling ourselves that fourth dimension, the fourth way to build software, and MongoDB is the back end of that software. It's the only database product and one of the few licensed products we, as an enterprise software company, actually use ourselves. Specifically, what is Unqork? We call ourselves a do-it-yourself enterprise system, basically meaning, very simple, the entrance point is you can't write code. No more programming. To use the system, no code is allowed.
It's just an entrance point for DIY. Specifically, what it means is that the person who knows what needs to get done best is enabled to do it and takes control over that. The person who knows it best actually takes control of driving that and deploying that themselves, whether that's the business or whether that's technology. How do we do that? We look at this and we say the biggest clients you could imagine, the biggest names, and these are nine of the names that we could talk publicly about, the ones that we could disclose. There's an entire list of other names we aren't allowed to disclose. The biggest names, we sit down and we basically say, "Look, guys, 90% of what you're doing in your company today with those tens of billions of dollars of technology costs is commodity. It's actually not valuable add.
Let us actually show you how to do it a different way." These are all production deployments and amazing results from that. What each of these companies is actually doing is using MongoDB behind the scenes as we're doing the hosting, we're doing security, we're doing everything, as you'll see. When we do that, we do that across product lines, and I'll talk a little bit more about flexibility in a little while. To us, it doesn't matter about industry or product. It matters about knowing the problems to solve, which is what it's all about. Application development is all about knowing the business, knowing the problem to solve, and getting it done. For us, businesses span from everything from life insurance to annuities to groups, to individuals, to P&C, to commercial specialty, to banks, to capital markets, to wealth and assets.
Our newest industry we announced two weeks ago is public sector, public enterprise and real estate specifically. To us, the industries are wide open. Everyone has the same pain points, everyone has the same problem, and everyone's trying to do things faster and better to get value. There's an interesting story. When you think about cloud, about seven years ago, I was quoted as saying, "If you have a data center, you're strategically disadvantaged." It was nothing to do with AWS coming along or Azure popping up. It had to do with one thing, which was you're declaring that your business's competitive advantage is infrastructure. Unless you're actually nanoseconds away from the trading floor and actually need that as an advantage, you don't, and you're confused. Cloud comes along and says, "We could do it better.
We could take over your infrastructure, your security, trust us." They do, and they're proving it as you know, inside out. SQL comes along. SQL's been around a while. Since I've been coding, SQL's been there. SQL says, let's think of things as entities and tables and relationships and joins. If you want to modify a table, it's pretty painful once it's out. When SQL comes along, it actually is trying to define models and data in a different way. What we see with MongoDB and NoSQL is there's a different way to do it as well.
With Atlas DB, which we are a consumer of, I think we've been a consumer, one of the early ones since 2017, we actually see Atlas DB as, again, like cloud saying, "By the way, don't hire any DBAs, don't hire any SAs to run those database servers. We've got it for you," and we are using that service. We don't have a DBA in my entire company. Why do we use MongoDB? I'm going to give you a few variations here of how. I'm going to start with the bottom and just tell you, I hired a CISO as my fifth employee before any engineers. Actually, the first platform version I built with my CTO ourselves, and then we basically brought on a CISO before the engineers, because no company, Fortune 50 company or Fortune 100 company, will trust us unless we are secure.
We're walking into them and saying, "You're going to go store your customers' data, their privacy data, their rules. You're going to not just store that, by the way, but you're going to store how you run your business in Unqork. Trust us." We're three people. You can imagine what that takes in those conversations. Of course, from the seven architects all looking at you with their arms crossed like this. We get through every conversation. We haven't failed a single audit. Specifically, security is top of mind. Security is something which we need. We don't know if a customer in Unqork is defining a date of birth or a effective date. One's privacy, one's not, so we assume they're both PII. We assume they both need to be encrypted and stored.
Everything in our system is encrypted and stored, and we have to treat it like that. We view the world from the CIO view out because that's our inside view. Everything we did in Unqork was, would I kick myself out of my office? The one thing we tell our customers is, number one, we host you in whatever cloud provider you choose, except on-prem is not an option. We'll give you a choice of AWS or Azure, Google Cloud in the future, but we do the hosting. You pick where you want to be hosted, and that push-button deployment allows us within one click to create a single-tenant environment. For those who don't know what that means, a lot of the software you read about is called multi-tenant.
It means there's a lot of people working in the same database at the same time, a lot of different companies. No one would trust us with their most critical information if we're multi-tenant. If we were combining business rules across customers or data across customers, we would not be trusted. We tackled the problem as single-tenant, top to bottom. Your database is your database. Every single thing is yours. Internally in Unqork, we built using Atlas and other tools, orchestration to one-click provision and upgrade everyone with one shot. Every single client from Goldman Sachs, who's a customer, and we could talk publicly to Liberty Mutual, they're running on the same version of software, which we upgrade automatically every week without even anyone knowing. Specifically, push-button deployment is critical, single-tenant. Data residency, where does data reside?
We had one customer call us up and said, "You got to move quickly. Our data's got to move from Ohio into Brazil." It took us five minutes using Atlas, we moved the data. Their entire application, without ever resetting or going down, was moved. They then called up one minute later and said, "Move it back. We made a mistake. We can't have it in Brazil," we switched it back. That's the reality of life. Now, in reality, in an enterprise, that one scenario I just gave you would've been weeks and weeks of planning and work, rollback would've been painful and costly. Scalable. We had one bank with seven architects sitting there looking at us like we're crazy.
You're going to take over our software and our application developers, what will the 10,000 developers do back there?" They basically said their final point they were trying to get to say no was scalability. "You can't handle our volume of our customers and our transactions." We were able to actually stand up an environment with 10 million accounts in each account with multiple products, in each product, multiple transactions-
Wow.
enormous Mongo instance overnight, we were able to show them 200-millisecond response time end user last mile, 27-millisecond response time internal with a million transactions a minute, faster than any system they've ever seen. Faster than any system in their bank, it's more secure. Scalability is something which is critical for us and one of the reasons we chose Mongo. We have flexible data structures. I showed you a slide saying we have banking customers, capital markets, asset management, insurance. I could tell you can't find another software company that even covers in P&C insurance, individual and commercial and specialty. Just P&C insurance. Our platform enables us to handle every product line, every product type, every front office to back office. It's because we're using JSON as a structure, which is the internal storage here. What does Unqork do?
Above a database stack, if you've ever seen this at an enterprise, this is all the components that you need to run a business. It's every component that a business is running on today, no matter what you're doing with your phone, with your tablet, with your PC, this is what's there. We actually replace it all. Every aspect from the API layer to the actual workflow, to the rules, to the presentation, to the tier, we actually do it all. One stop. Our goal is that it is the only software that will be there. That's where Unqork comes in. Unqork, again, is using cloud. It's using MongoDB, and specifically, it's a new way to build software. It is the fourth generation of build, as we call it today.
I think I did that in record time, but thank you very much for the opportunity today, and thank you again.
Great. Thank you, Gary. Appreciate that. Next up, I think we have Richard.
That's correct.
Okay, great. I'm introducing the right guy. Some of you may have met Richard. Richard is our SVP of field engineering. That's basically everything that sort of touches from sort of a customer perspective in terms of pre-sales, post-sale, and customer success, all support as well as professional services. Richard's been here for many, many years and is a great intersection of where the technology actually meets real life with the customers. Richard's going to help summarize some of what we heard earlier today. With that, Richard, thank you.
Thank you, Michael. Good afternoon, everybody. It's great to see all of you here, and I'm glad you have an opportunity to come to MongoDB World. Just one brief note. I have been with MongoDB a very long time, since January of 2010, and actually, I and my team were the folks from the MongoDB side that helped Gary get his initial project going back in 2012, 2013 timeframe at MetLife, and I'm really glad to see that he's still part of the MongoDB community, as actually many people that are attending our big conference are today. For those people who have joined the keynote earlier or listened to the live stream, you probably saw a ton of announcements about MongoDB product capabilities.
Those descriptions, those announcements, those demos were definitely designed for a developer-focused audience, and part of what I'm here to do today is to help clarify that and sort of how that all fits into what we're doing from a business point of view. The thousands of people in the room just now seem to be very excited about it from a technology perspective, and I want to talk to you about what that technology does and why that matters to our customers and for our business. Michael was a little concerned earlier. I got you covered. We do in fact have a safe harbor. As they say, as Yogi Berra once said, "Predictions are hard, especially about the future." Please understand that everything we say about what's coming is best effort and you make your own judgment as to how to interpret it.
To reiterate the mission that MongoDB has set for ourselves, it's to free the genius within everyone by making data stunningly easy to work with. Now, we've been aspiring to do this all these years at MongoDB. First building the core database product, which has tons of downloads and users and customers and so forth. This year, we made some announcements to really talk about how we can expand the capabilities of that core database product and go on into some other products that continue to make data even easier to work with for our users and customers. Ultimately, in the big picture, what we've been building over all these years is something we call the intelligent data platform. To say that something's an intelligent data platform ultimately means three things for our purposes.
It means that our platform, inclusive of all of our products and features and capabilities and services, are intended to give you the best way to work with data, which we'll talk about as we go, the ability to intelligently place that data or home that data wherever you need to do so, and the freedom to run your software and our software anywhere that you would want to do so. Let's touch on these things in a little bit more detail in turn. First of all, MongoDB is what we call a document database. The core idea, as Gary mentioned, and as some of you have encountered before, is that MongoDB's fundamental understanding of what your data is flexible, and you can change it easily over time.
This gives developers a lot of advantage because it's a lot easier to both get started and to continuously iterate on what an application needs to do with that flexible data model. It also gives developers an ability to produce their applications faster because it's a simpler data model than splitting up data into tables and rows across a traditional database schema. Finally, the data model that we have is much more versatile than what you get with any other database in the sense that it can store different kinds of data, it can interpret that data differently, whether it's geospatial data or textual data or monetary data, audio, video. These kinds of things are very easy to incorporate into MongoDB.
These capabilities, this business of having a flexible data model, gives developers a way of working with data that most of them will say allows them to go two times, three times, four times faster with MongoDB in terms of delivering applications. Also, when they run their applications, those applications also tend to run a lot faster. The net effect of all of this is that developers come to MongoDB primarily because MongoDB makes it easier for them to work with data, whatever kind of data they have, wherever that data is being handled, in the cloud, on-prem, on their laptops, et cetera. Next, MongoDB is at heart a distributed database, meaning that we make sure that there are multiple copies of the data and put those copies in different places under your control.
The capabilities that we have here provide for high levels of availability so that a business never needs to go down. High levels of scalability so that as business requirements change, especially expand, applications can take advantage of a database that has more and more capacity to handle more workload seamlessly without the application even noticing that the database is being changed. The ability to isolate different workloads to different parts of MongoDB's sort of deployment so that you can have a single application, some parts of which might be operational, transaction processing, people putting things in their shopping carts and checking them out, which run on some parts of a database. Other parts of the application that are mostly analytical, tallying up receipts, computing end-of-day or end-of-month type trend operations, which run on other parts of the same database.
This is a technically interesting capability because most people historically have had to use different products to solve for those different kinds of problems between the operational and the analytic workloads. We can do it in the same MongoDB cluster, but guaranteeing that this part of the workload goes over here in the cluster, that part of the workload goes over there to a different copy of the data in the cluster for ease of replication, management, securing that data, for our users. Finally, MongoDB's clustering model directly supports the notion of data locality, where users can specify that they want some data to live just in North America, some data to be homed only in Germany, some data to be homed, perhaps, in Singapore. This can be used for different reasons.
For some customers, this is so that they can keep their data close to their users for user experience reasons, so that the data is nearby and those applications can therefore be fast. For other users, it's a compliance issue. Data about certain users can't be homed outside of the country or state or province or region where that customer lives. Both of these things are straightforward applications of these distributed systems capabilities that we have. Finally, MongoDB, our technology platform, is built in a modern fashion in order to be able to run anywhere that people need to run software. This includes the core database server, which runs the same whether you're running it on this MacBook in front of me or on commodity-grade server hardware, if you have that sort of hardware around, IBM mainframes, cloud environments, anywhere you want to run MongoDB.
We also now, especially with the recent acquisition and integration of Realm, have a fantastic mobile database that can give you the same high-quality experience of working with data even on mobile devices such as iPhones, Androids, tablets, and that sort of thing. Our ability to run MongoDB the same way everywhere allows us to leverage a multi-cloud strategy and to allow our customers to leverage a multi-cloud strategy. Atlas runs identically on AWS, GCP, and Azure. For all of our customers and users, they pick a cloud, similar to what Gary was just saying. They pick the cloud and they can decide where to run MongoDB, but it's the same experience everywhere. It's the same skill set everywhere. It's the same security capabilities everywhere.
Anything that does less than that is an opportunity for customers to make mistakes and to have problems and to have operational overhead needing to do different things in different clouds. MongoDB gives that same seamless experience wherever people run. This ultimately tends to excite our customers because it means that they're not going to be locked in to any particular way of running their software, whether that's in their own data center, in some particular cloud, or anywhere else. They have the ability to move their workloads, even on the fly, dynamically, without the customers even noticing, from an on-premises deployment into a cloud deployment, for example.
These are the key things that we're always working on and always trying to further expand as we add new products, as we add new capabilities to continue to flesh out this intelligent data platform. Let's talk about some of today's key announcements. There were a ton of things that Eliot talked about on the main stage this morning, and I want to focus on a few of these, but fundamentally, we can think of them in three different buckets. One, there are some capabilities that we could say further enhance the core server. That's the core MongoDB database that all of our customers have been using for all these years. I'll talk about one of those key new capabilities in a moment.
We've added some more capabilities that are primarily of interest for operational purposes, so the running of the database software and the applications on top of that database software, and some new capabilities to address, you could say, new data challenges. First of all, let's talk a little bit about transactions. Now, we can say about MongoDB that all ways that you run that core server support full ACID transactions. What's an ACID transaction? Well, this is a term of jargon in the database industry and among database developers. These are four attributes that, since the mid-'80s, have been generally accepted to be good things to have in a database. They're not regulatory things. They're not compliance things. They're desirable attributes.
If a database has these qualities, transactions that satisfy some particular acronym, then most developers will feel like, "Okay, I can probably use that database for any kind of application." If a database doesn't have all four of those attributes, you can perhaps still use it, but you might need to be a little bit clever. In MongoDB's case, we've been working toward this full ACID transactions capability for a number of years. Prior to MongoDB 4.0, we had a restricted version of transactions. You could think of them as micro-transactions. The punchline of which is that for the longest time, people could build serious, complicated applications on top of MongoDB, provided that they laid out their data in the right sorts of ways and that they leveraged our capabilities appropriately.
We have trading platforms and e-commerce platforms and inventory management systems and all kinds of transactional-type applications that use MongoDB. The developers had to simply be a little cleverer than average in order to put all the pieces together. Last year at MongoDB World, we announced multi-record ACID transactions for small deployments of MongoDB. To use the technical term, this would be a single replicating set in MongoDB. People have started to adopt that, and we have some interesting stories that are unfortunately not for public disclosure of some customers building transactional applications using our transactions capabilities in small deployments of MongoDB today. This morning, we announced full general purpose distributed ACID transactions over any size MongoDB cluster.
What this means is that no matter how you're deploying MongoDB, whether it's on a mobile device, a single server, your laptop, a small replica set, or a large cluster, all of them will support the same transactional capabilities. You can say, I would like to start a transaction, make any arbitrary number of changes to your data set, then commit the transaction at the end. This greatly simplifies the head-scratching that a developer needs to do and really just takes away the head-scratching, so to speak, in order to build complex applications that want to do operations over multiple records. Let's dive a little deeper, if you'll indulge me. Why is that important?
On a traditional relational database on the left-hand side, any kind of data is going to be broken up into multiple tables, that diagram on the left represents a bunch of different tables that have all kinds of complicated relationships with each other that are represented by those dashed lines. Generally speaking, if you're going to use a relational database, the traditional sort of legacy systems, almost anything you want to do with your data is going to touch multiple tables. As a result, traditional tabular relational databases need multi-record transactions for you to get anything done with any kind of guarantees about sort of the correctness of your program. You need to say, "Start transaction," then go update a whole bunch of different tables, then you commit your transaction. In MongoDB, typically, you don't model your data that way.
You model it closer to what's on the right-hand side, where you have multiple pieces of information all collected into one document. By doing so, you get a lot of efficiency because that document is stored in a very efficient manner. Also you get transactional capabilities because any changes you make on a single document have always, since the dawn of MongoDB time in 2007, has always been a single document-level transaction. If you leverage MongoDB's document capabilities appropriately, you don't actually need all of this general purpose ACID transaction stuff that we've been working toward, you don't have to use that capability that way. You might want to lay out your data for an e-commerce application, for example, by splitting things up into separate records for various kinds of business reasons. One possible application might be an e-commerce application. I might be a customer.
I might buy some pickled onions. In fact, if you know me, I'm likely to do that sort of thing. A transaction over such an application would entail changing two different records in two different places. One of them being a representation of my order, including some pickled onions, another one representing the inventory of pickled onions in the warehouse somewhere. In order to process such a business transaction, we need to change both of those documents, we ought to change both of them or neither of them. What the transactional capability that we've added lets you do is to make the state change from the order being in progress and the inventory being 1,000 to both the order completing and the inventory being decremented, either both of those changes happen or neither of those changes happen.
This is a very basic capability that a lot of other databases have had. As I said, we've had people building complex applications on MongoDB for years in the absence of this capability. What this really does is make it easier for customers, in some respects, to build these kinds of systems. Frankly, from a business point of view, it alleviates a certain kind of objection that one might bring that, "Well, MongoDB does everything, but it doesn't do this thing, so can I really use MongoDB for all applications, or can I use it for this application today and also with tomorrow's requirements?" The answer now is unequivocally, for any size MongoDB deployment, yes. That was probably our biggest, most exciting sort of developer-focused capability in the core database. Let's talk about some other things.
Over the years, of course, our business has been growing increasingly deeply involved in our customers' most important applications. Any kind of important application is going to have a number of different kinds of security concerns, both for just because that's the modern world that we live in, also because many of our customers exist in regulated environments or environments where they have compliance and details that they have to agree with. We've been working on a number of different capabilities, some of which we've talked about today at the keynote and some of which have been other announcements that have come recently, generally in the area of security requests from our customers. These can be thought of in terms of 3 categories, encryption, access control rules, and compliance certifications.
On the access control side, I think the simplest thing and the most interesting thing that we've done that we can talk about there are some capabilities that we've added into our Stitch platform over the last year, which give very fine-grained rules for users of modern applications on what kind of data visibility they can have in their database. The core database has had powerful access control rules for quite a number of years. The database-level access control rules are typically used by back-end developers and are somewhat different from the business rules that are used by sort of ordinary application users around what data they can see. There are multiple layers of access control capabilities in MongoDB, which are highly powerful and are part of any real-world deployment of MongoDB, at least of anybody who's following recommended best practices.
This is an area where we've got the security capabilities that all real applications need, and it does require a little bit of customization for a particular business's needs in order to get that stuff right. It's a capability that is clearly very important to all of our customers and something that we continue to enhance. Let's talk a little bit about encryption. One of the cool things that we've added, announced today, is client-side field-level encryption. What does that all mean? Well, MongoDB has, for a number of years, supported the capability that it can encrypt all of your data that it manages. Of course, you can buy hardware that can encrypt data sort of in the hardware. If somebody steals your encrypted hard drive, well, they're not going to be able to use it.
If somebody steals your standard hard drive, but MongoDB has been encrypting your database, they're not going to be able to use that either. There's another level of security that our customers have asked for, which is the ability for their applications to do the encrypting inside the application itself so that the database never sees the sort of plain text, unencrypted data that the application is trafficking with. An application might, for example, be my user profile on some website or in some business, and my user profile might store a lot of information about me, my name, my social security number perhaps, my date of birth, and other sort of information, some of which should not ever be stored unencrypted by a database. The field-level encryption capability, client-side field-level encryption capability that we've just added makes it very easy for an application.
In fact, it makes it invisible for the application developer to declare certain fields should be stored in the database encrypted. That encryption happens inside the application itself, and the application only ever sends the encoded, encrypted, secured data for those pieces of information. The other information about me, whatever it is that I'm doing with that business, my order history, maybe some other preferences, reviews on previous product, et cetera, does not need to be encrypted. That stuff is stored just verbatim inside the database. The key thing to understand about all of this is that this encryption is happening inside the application, not inside the database.
The way that that applies importantly for us in the form of Atlas is that in Atlas, where we're operating the database, we never see, nor can we see, the unencrypted data for those fields that are being sent over to us. Even if Atlas were somehow compromised, when users are using this capability, only their application can actually decode that data. Our staff, our employees cannot actually see the unencrypted personally identifying information and so forth that has been secured at the application tier. This is a capability that's also quite innovative. Hardly any other database, no database that I'm aware of, has a capability like this at all. It's really us going farther in the direction of giving high-quality security capabilities to our customers than what our competitors do.
This does also very straightforwardly help us with compliance environments such as GDPR and others, simply because one of those requirements under GDPR is the so-called right to be forgotten. One way to implement such a right to be forgotten is to have an encryption key for each user, and then whatever that user does in your business in that system, it can be forgotten simply by throwing away that user's encryption key. It's an innovative way to implement that right to be forgotten kind of capability that becomes very, very simple with this MongoDB database capability. Now, we also continue to invest in compliance environments generally, in compliance with different sorts of regulatory environments generally.
Atlas today, and over the last couple of years, has been certified for compliance with a number of different standards, including SOC 2, HIPAA, GDPR, DISA STIG, and ISO 27001 is the most recent. We're working toward PCI, which will allow us to get into further space involving credit card transactions. All of which is to say that Atlas, our operation of MongoDB in the three major public cloud providers, will satisfy any of our customers, increasingly more any of our customers' requirements for their particular industries and in their particular jurisdictions. As I said, at MongoDB, we want to make data stunningly easy to work with. One aspect of that is that not just in our operational database, which has been the hallmark of our business all these years, but wherever people have their data.
Increasingly, people are storing their data in different sorts of places beyond what would be traditionally considered an operational or back-end database, such as the core MongoDB database server. For example, as you know, we acquired the Realm company about six or so weeks ago. This is a mobile database company founded back in 2011. It's an open-source database that's an alternative to some other databases that can frequently be found on mobile devices, such as SQLite or Core Data. It's very easy to use, and in fact, the developers of Realm said that they were quite inspired by how easy MongoDB was to use for traditional back-end database purposes, and they wanted to bring that ease of use for data to mobile developers.
The interesting thing about Realm, for our purposes, is that because it's already a very widely adopted mobile database, integrating Realm into what we already have in the form of Atlas on the back end and eventually in other environments as well by integrating their real-time synchronization capabilities, means that people who want the best way of working with data for mobile devices, which is often today, for many developers, the Realm APIs, or who want MongoDB ways of working with data using our query language, our query APIs, and so forth, can do them both on their mobile device with the guarantee that the data that's stored on that mobile device, my information about me on my copy of the application, your information about you and your copy of the application on your phone, will get synchronized back up into the cloud.
Initially, for us, this will be Atlas. People can work with their data however they want to on the mobile device or on the back end with all of the same capabilities in both places. This is a really exciting area for us because this means that people who've been developing applications that have both a back-end component and a mobile component have historically had to use somewhat different ways of working with the data in the different places. Customers have asked us, "Couldn't you just make it seamless for us to use the same interfaces, the same programming, maybe even the same code in both locations?" That's directionally the kind of thing that we're thinking about. Of course, we also announced this capability in Atlas, which is full-text search.
As Eliot mentioned, for those who listened in on the keynote, one of the things that's been the case until now is that if you have large volumes of natural language data in something like MongoDB, and you want to be able to do natural language-aware searching, you typically needed to sort of copy that data into some other system that ultimately did that natural language processing because that wasn't something that was core to MongoDB. By natural language processing, I just mean things like recognizing that the word apple and the word apples are related to each other and so on and so forth, so that you can do fuzzy matching and singular, plural, and all those sort of sneaky things that natural languages do.
With Atlas full-text search, what we've done is introduced into our Atlas product the capability of building what looks, to the user, to be just another query capability into MongoDB to do that natural language processing inside their data in Atlas. They don't have to manage anything additional. They don't have to copy the data into any place other than MongoDB. When they put their data into MongoDB and they declare that they want this kind of text search capability over it, they have it. It's just built into the query language. This will make it even easier for people who are already doing that sort of thing to put a search box on their application to do it directly in MongoDB. Lastly, for today's announcements, we have the Atlas Data Lake.
Tons and tons of our users have been telling us for a while that they have lots of data that's stored in MongoDB, and that's highly valuable to them to keep that data operational, available, accessible at a moment's notice. They even have more data that is valuable for them to keep around, or maybe they have to keep it around for regulatory reasons. It's not super valuable for it to be online all the time and accessible in that fast way all the time. They want to be able to do things with it. They want to be able to query it. They want to be able to analyze it, and so forth.
With the Atlas Data Lake, we can take those customers who have large volumes of data in something like S3 in the cloud, an easy way to store large volumes of data, and allow people to interact with it directly as if it were MongoDB. Any existing MongoDB application that people might write for their sort of highly valuable, maybe it's recent data, they can point to that same application via the Data Lake interface to query and aggregate and do whatever it is that they're doing over data that's stored in a simpler system like an S3.
What this will allow people to do over time is things like keep their recent data in an operational database, archive the less recent data into an Amazon S3-type system, to be able to really do all the kinds of things that they want to do with their data, no matter where that data's stored, whether it's in an online operational database or a sort of more passive object store like an Amazon S3. As I said, these are some of the capabilities and features and products that we announced this morning, all of which are aimed at making it easier for developers and easier for people to work with data wherever that data sits, mobile device, operational database, Amazon S3, et cetera. All of which helps to further flesh out what our intelligent data platform can do for people. Thank you.
Great. Thank you, Richard. I think Sahir is coming up next. Sahir runs our cloud business. I'll turn it over to you, Sahir.
Cool.
Thank you, Michael. Good afternoon, everyone. My name is Sahir Azam. As Michael mentioned, I run the cloud business and product strategy for MongoDB. I joined the company about three years ago, which was obviously a pretty pivotal point in our evolution as we expanded the platform to really start expanding to cloud services as a significant part of our revenue and not just enterprise software.
Obviously you know these numbers. This is the fun slide. Atlas is now over 35% of our revenue, and obviously the fastest-growing part of our business. The interesting thing about this is certainly not just the growth, is the fact that we're definitely just getting started. I was listening to a podcast earlier this week from an interview with Andy Jassy from AWS, and he threw out stats that only 3% of overall corporate enterprise workloads are even in the public cloud today. As much as we hear about the $billions and the tremendous growth of a lot of cloud platforms, we think we're definitely very much in the early innings. I want to give you a little bit of context around this. We've been at building this platform for many years.
Although we've launched Atlas 3 years ago to the market, really started expanding our go-to-market strategy around it, the reality is the technology and IP was in development far before that. It all started back in 2011 when we released our first cloud product. At that point, it was called Mongo Monitoring Service, very creative name. What it did is helped customers manage their MongoDB environment by quickly spinning up a cloud service, getting metrics and data about the performance of that environment. We expanded that and added capabilities like cloud backup, especially for smaller customers who couldn't afford to buy their own storage hardware or run it in their own data center. They just wanted to send us the data, secure it in the cloud. The third piece we added a couple of years later was automation.
We had now seen quite a bit of adoption in MongoDB worldwide, especially in the enterprise. Customers were asking for easy ways to upgrade their database safely to rolling patches and updates, whether it be security or new functionality that they wanted to push out. Really what we were embarking on was a dual-track strategy. On one hand, we wanted to ship these technologies both as cloud and as software to help our enterprise customers manage their MongoDB environment. That was track 1, that obviously has helped our first phase of monetization and is largely the value that we ship as proprietary software. The other was to start building the IP and capability and technology to ultimately build Atlas.
Behind the scenes of Atlas, a lot of the core monitoring capabilities, backup capabilities, automation that I talked about, powers our delivery to the thousands of customers that run on the platform. At this point, if you look at sort of the size of the team supporting it, we've got over 125 engineers just on the Atlas layer alone, that doesn't count capabilities that were built outside the Atlas team by our core engineering team, things like Data Lake, that are now very much a cloud-first strategy for development. I want to walk through a little bit more on the go-to-market side, how Atlas has transformed our business. There's a few key areas. One is really around how Atlas has helped us monetize a bigger part of our ecosystem, bigger part of our community.
The second is really around how we've become more strategic with our partners, whether that be systems integrators like Accenture or Infosys or our cloud partners in AWS, Azure and GCP. The other side of it is how MongoDB as a company has changed as well. We've now been able to leverage data to get much better engaged with our customers at a much more accurate and sophisticated level across every function of the company that touches the customer. That hits not only the customer experience, but also the product experience. We can build more products faster, as you're seeing in the number of announcements we've made in the last two years, now that we're embarking on a cloud-first delivery model.
To take a step back at a very basic level, there's a few phases that a development team might go through when they're building an application. They're designing the application, maybe prototyping on a laptop or a free tier of an environment. They then go into the actual development of the code based on either an agile framework and user stories or a broader spec in a waterfall process. They definitely want to go through some form of rigorous testing, functionality, check for bugs, performance, whatever it might be, integration testing. Then, of course, the application goes into production. No question, Mongo is used across this entire life cycle. If you look at the global adoption of our free version of MongoDB Community Server, it's used all over the place for every phase of this life cycle.
If you look at us as a business, the majority of our revenue comes from a product called Enterprise Advanced. Historically, the value it provides is really aimed at mission-critical production workloads at the end of that life cycle. That's really when customers start to care about performance monitoring, backing up production data, automating upgrades and patches for the security, integrating into their enterprise security authentication tools and the like. That's largely where the value of our monetized proprietary solutions sit. With Atlas, this equation changes. We can now monetize the entire life cycle.
Whether it's a developer prototyping on our free tier, get that first few lines of code written, whether they're using our really lightweight, cheap instances for development that start at $9 a month, or they scale all the way into production with a Global Cluster that spans multiple regions, sits across hundreds of potential servers, we're capturing value from that customer experience all the way through. Although we've always been used as a database across this entire life cycle, we're frankly now monetizing that entire life cycle. It also allows us to engage much more closely to the development teams and the business itself. The business and the development teams have always been a key constituent of ours, but not necessarily a buyer of our technology. The buying behavior was really more with operations, who's tasked with managing the production environment.
We're really engaged with all the different users of Mongo across the life cycle. Obviously, that's showing in our results. If you look at the number of paying customers that we have, in terms of volume of customers, it's grown exponentially as a function of Atlas. That has come through the broadening of reach that we have through a multi-channel go-to-market strategy, which is what I'll go through next. If we take a step back, three years ago, our go-to-market strategy was much more focused than it is today, and it's much less broad. We were largely deriving our revenue from enterprise direct sales in the field, selling to the Global 2000 on a value prop of upselling Community Edition free users of MongoDB into commercial users of Enterprise Advanced on the back of some of the value that I talked about earlier.
Certainly, this is still an important way for us to drive revenue today, this was largely the only way we sold in the past. The main buyer, as I hinted on earlier, was really the operations teams. You have the development teams who would build the apps, they would traditionally hand it over to an operations team to monitor it, to back it up, and those teams needed tools. That's largely who uses our Operations Manager technology or our Cloud Manager technology, the sister product in the cloud. Therefore, our marketing organization was largely focused on lead generation. It would take community users, try to identify the accounts and people who are using that, turn those into leads that would then funnel up to sales to help go drive the value and close an opportunity. At the time, we also had an inside sales team.
We call this our corporate sales channel, it was relatively small as a team. Obviously, this segment of the market is very large in terms of tens of thousands, if not hundreds of thousands of accounts that we can call on. The sales motion at the time was largely like trying to find a needle in a haystack because the product market fit for Enterprise Advanced was largely built for Global 2000 companies. It's called Enterprise Advanced. Finding a small company that has the resources, skill sets, and requirements to use that enterprise software was relatively challenging. Therefore, we even created smaller packages like legacy products like MongoDB Professional, all trying to kind of crack the code on how we can get better product market fit in that segment. Frankly, it wasn't growing as fast or as successful economically as our enterprise channel.
Then the further down the market we went with the SMB, we really had no coverage. We had some very trickle to nothing of self-service revenue to really drive that reach because it's not a people-oriented sale down at that level. What do we have today? With the advent of Atlas, we really diversified our channel strategy quite a bit. Our enterprise channel is obviously still selling a lot of Enterprise Advanced, but also increasingly so, especially in North America, Western Europe, selling large amounts of Atlas. What's interesting is the message around Atlas is less about risk reduction operations and is more about driving innovation. It brings us closer to the business buyer. It gets us to the line of business executives and the developers that are actually conceptualizing these amazing new products. To be able to do that, our marketing organization's also shifted.
Instead of just qualifying community upsell leads, the marketing organization for the enterprise is really focused on a more advanced account-based marketing strategy, where they're trying to drive field marketing events, developer adoption for the next new app within a large enterprise to drive that next upsell and expansion within the account. We've really driven a transformational change in the inside sales channel. We've pivoted over the last couple of years this to largely be an Atlas first or Atlas-led sales team, that has had a tremendous effect in allowing us to scale this business. We have grown the team by over three times in the last three years. We're basically constrained just purely on how fast we can hire and on-ramp people onto this team. The velocity of how fast they close deals has increased.
The number of new logos they're actually closing is much, much higher than in an enterprise software context. I think the most exciting part is this is the team that's really on the front end of leveraging data about customer usage to help drive customer engagement. They are looking at data and getting dashboards and alerts about what's happening in the actual customer environment, which allows them to provide more value to the customer. Down at the bottom of the pyramid, so to speak, we also have new sales teams that are not focused on hard selling, closing larger transactions, but are purely focused on nurturing and driving success within some of our highest potential credit card customers. We call this our MRR or our cloud sales team.
They are focused on helping customers understand how to use the product correctly, and they're measured on both expansion and the retention of those meaningful customers. The last piece, and certainly not the least, is this brand new self-service channel. This is purely developers coming in, DevOps teams coming in, swiping their credit card, and getting going on a build and arrears type model using our cloud services. This is entirely new for us. It's actually been a rapidly growing channel of growth for us because these are customers that we were never monetizing before. Right now, we have north of 10,000 customers that are attracting to Atlas, coming in through that funnel. We've got 1.5 million-plus free tier users, and the goal here is to scale this channel so it's not only an independent channel, but it increasingly provides upsell opportunities to our sales teams.
Whether it be at the bottom of the triangle with small customers all the way through large enterprise, we're already starting to see that behavior. What's interesting is we've largely succeeded in the kind of bottoms-up self-service model because of the strong product market fit and just the brand power and reach of MongoDB. We are by no means B2C style, e-commerce style growth marketing geniuses. We're definitely building up that skill set within the organization. There's been heavy investments in reorganization of teams to really drive B2C style growth marketing model, which is all about looking at the funnel, inspecting it every step of the way in real time, testing and experimenting every piece of that customer journey to try to drive those conversions up. It's a new discipline for us to really get great at that last piece.
As a quick example, this is actually an email thread that was a couple of weeks ago with one of our inside sales teams. They have a targeted account. This is a customer that is already using Atlas, but on a credit card. They don't have a support contract, they're not a very high spender, but we think they could be a much larger customer because they're growing really fast. This account manager had sent four emails, that's the upper left, just trying to check in and get engaged and see if there's anything we could do to help to grow that account, close them on a committed contract. He got no response. Just junk folder, ignored the emails, whatever it might be.
During this life cycle, the rep noticed on their dashboard that there was actually an abnormal spike in usage and spend in their Atlas environment and said, "Okay, well, something must be going on here." He sent a much more targeted email saying, "Hey, I noticed cluster XYZ. You just spun it up. It's driven your usage up by X%. Let me know if I can get you technical resources to help. It seems like you might be spinning up a new application or doing some new testing." They responded within 10 minutes. That turns into now a new upsell opportunity for a new application that the customer was organically trying on their own, but we can accelerate and make sure they're successful through our sales team.
It's just a small example of how sort of data's changing the customer interaction model throughout the life cycle. This is just one example, but I think we're relatively early on this journey. We're building a lot of technology and infrastructure to route these product signals and customer signals from everything from support to customer success to all the different layers of our sales organization. Now, I want to shift gears and talk a little bit about partnerships. Obviously, for those of you who are watching the keynote, we really do spend a lot of time thinking about and working with our partners. What's interesting with Atlas and partners is it's really changed the motion that we attack the market with these big players.
For a little bit of context, the first wave of cloud migration was largely what we would call or what you hear in the market, lift and shift migrations, right. There was a CIO that says, "Okay, we got to get out of this data center as fast as possible and get into AWS or Azure or GCP, whatever it might be, and we need to just move this stuff out of our own infrastructure." What ends up happening is the first phase of cloud migrations are largely taking your legacy application stack and your legacy people and processes, the specialized teams, shifting that over so that Amazon becomes your hosting provider, and then obviously you remove some cost on the facilities and data center space.
What those companies that jumped head first in the lift and shift strategy found is they moved to the cloud, they checked the box, but now they're paying more and they're not delivering anything any faster because they still have the bouncing manual process of a ticket from team to team managing the environment. They haven't broken down any walls and processes, and they haven't necessarily optimized their application. They're still running it in a very traditional model like they would on-prem, so they're over-provisioned. Instead of over-provisioning, meaning you've got some empty hardware sitting around that you're capitalizing over three years, now you've actually got a metered bill running all the time. This actually could be much more expensive. Thankfully, the industry's gotten a lot smarter.
The cloud partners, the SIs, all of us have really said, really, if you want to move to the cloud, the right way to do it is to really think about your architecture in the right way in a cloud-native architecture. To really extract value, you need to start moving to a model where you're consuming cloud services, not just using the cloud as a data center, the raw infrastructure. We've changed our whole partner go-to-market strategy to tie up with AWS, Azure, and GCP, combined with strategic cloud migration practices that Accenture, Infosys, TCS, they all have. We are in the center of this secular cloud transformation movement that's happening, that's led by these partners.
What's interesting, especially for the SIs, is if they're recommending a platform, a database platform for their end customer, MongoDB is an interesting choice because it gives customers choice and neutrality. We're the only major database provider, as Dev mentioned in the keynote, in 64 regions across three clouds. As Accenture goes in or Infosys goes in and says, "Listen, I'm going to help you refactor this app," they look even more strategic when they recommend a platform that protects that customer for any single platform lock-in. It's a powerful story. Shifting out of go to market and monetization for a second into core product, the data we collect in a cloud model completely changes the way we build product. Gary had a great example of how there's a single code base that runs all of Unqork's environment, no matter what customer's on it.
That's the way we run Atlas as well. That's allowed us to have not only data about usage so we can help our field organizations, we also have data on usage so our product managers can make better product decisions. We can A/B test new features and see which UI works better. If we're working on the growth team, we can try different flows on the onboarding experience to see what converts better. We've really leveraged data and visibility into how the customers are using this in a much more strategic way across that entire life cycle. We actually ship code in Atlas every three weeks, so we're constantly adding new customer value.
If you kind of back that out, you look at the 300-plus engineers we have at MongoDB, much more of our time now is spent focusing on customer-facing value add, new feature development, which is why you see our pace of innovation and capabilities accelerating than in a historical enterprise software model where we have to worry about testing 15 different operating systems of four different versions and validating that everything works properly. It's just so much easier to manage one single code base in the cloud across tens of thousands of customers. You've really seen that. If you looked at Richard's presentation just now or Eliot's keynote this morning, what you're seeing this year is really a culmination of a cloud-first development strategy.
If you look at things like Data Lake or full-text search or what we've started with Stitch, the Realm acquisition, these are all components in an overall platform strategy that we would not be able to execute this quickly if we weren't able to deliver it in a cloud model, iterate on better product mix, so market fit faster. In summary, this has really been interesting for us because I think when we first started the Atlas journey and I came on board, and we were talking about how we were going to get this thing to the market, I don't know that everyone necessarily realized how much it would transform every function of the company. We are basically now, at this point, a cloud-first company in every segment of the organization. Thank you.
Sorry? Oh, great. Thank you, Sahir. I think next up, we've got a section on the partner team. I think we're going to have Dev, I think. Yep, here he comes. Accenture. All right. Test out my emcee skills, that's fine. Yeah, over here is fine. Thank you for coming. Are you mic'd up? Are you Okay. Oh, well, you're standing right here. All right, well, Sanjeev, I'll give you mine. Here's Dev, excellent. Here's the other one.
Thank you.
Okay.
All right.
Now the partner section, Dev and Sanjeev from Accenture, take it away.
Okay, thanks for making the time. Hopefully the session's worth it. I wanted to introduce Sanjeev Vohra from Accenture. Maybe first and foremost, maybe just give a quick primer on your background at Accenture.
Sure. First of all, thanks for inviting. It's a pleasure to be always with MongoDB. We have been doing a lot of things together in the field, so good to always be here and to participate in these events. My role, I have a couple of roles. One is my primary role, which is I'm a CTO for our technology business, Accenture Technology. In that role, I do three things. I spend a lot of time to ensure that our talent is relevant and is ready for the future because we are a services organization, so are hugely people-powered company. We have a lot of people in our company, and we just want to make sure that they are relevant for the future because they're helping clients to move to the next generation or be the next high-performing next companies of the future.
They need to be relevant for that, right? I ensure that we are making right investments into that talent development and ensuring they stay relevant in the future. The second is I look at very specifically on a couple of things. One is a special offering that we have called Workforce of the Future as to how talent is getting ready for our clients and how do we make sure that they can take that journey for themselves. The second is data. I spend most of the time on data. It's a passionate topic for me, and I love data. The last but not the least, I work on very special V&A strategy for our firm. Those are three things I'm doing. I'm a global lead for data business as well.
V&A?
Yeah.
Oh, could you.
Oh.
Yeah.
Acquisitions and ventures.
Oh, okay, M&A. Got it.
Yeah.
Got it. Talk to us about the data business. You mentioned that you're re-energizing the data business within Accenture. What does that really mean? Maybe in layman terms.
Yeah
you could explain to this audience
Yeah, I think
what is Accenture's focus on this topic?
Absolutely. I think all of us have been listening about the data being the new oil and the new currency over the last two years. The attention towards data has really increased over the last 18 months or two years. It has become a C-suite topic, which was not the case earlier. The way I explain is that we all are aware of data and been working in data for the last many decades. Guess what? All the businesses were kind of dealing with data earlier. I think now they want to lead with data. That's the difference and the shift that we see over the last few years.
We see, Dev, is that there are largely when we talk to C-level now and then they're getting more knowledgeable about this topic, and they want to really see how can we untap the value for the data that we possess, plus the data we can acquire from the market or something else. We can create new, frankly. They are talking about more challenges that we see with them. The first one is that most of the companies have a very well-defined business strategy at the C-suite, and they have a very well-defined IT strategy because technology powers, IT powers the business in every organization. Data strategy is kind of hidden in many places. It's not explicit, right? They are now we're talking about data strategy should be the topic of like they should really invest in data strategy. That's one challenge they have.
They do not have a very well-defined data strategy in terms of what they can do with data, and by the way, how do they get there. How is really not defined in many companies. We found what, but we did not see how much, right? The second piece is around the speed and access data for the business. I think we see huge issues there in terms of the architectures they have right now are kind of dated, and they really need to power that architecture with new technologies to ensure that the data flows at the speed which business needs. Right? Third point we are seeing, which is probably to me the biggest issue and going to be in the next few years to solve, is quality and trust on data. Business do not trust data, and that's why you will see the complaint.
You see symptoms, you don't see the pain which people are going through. The symptoms are like we have built a lake, but nobody's using the lake. That's a kind of a symptom. The issue is that they're not using lake because they believe that data is not trustworthy inside the lake, and the insights are not as good as they want it to be. That's the third problem, quality. The fourth one, which I think is quite profound, that companies have invested in COEs over the last seven, eight years.
COEs mean centers of excellence.
Center of excellence. Thank you. Analytics center of excellence, the data center of excellence, whatever it is. They have invested in technologies, all new technologies called machine learning, everything else. That's not going to make them data-driven company, unless they really change the culture of the place. The businesses or the people who are actually using or consuming data, they need to understand the data itself and see and generate insights. The whole concept about data democratization or making people use data more efficiently is something which is arising right now. Those are the four challenges which we see in the market, and the idea is to solve those challenges and make them more efficient.
You obviously work with lots of vendors. You're a big organization. We've had a successful partnership now for a number of years. In fact, Accenture's the partner of the year for us for the last two years in a row, our relationship is growing. Maybe you could talk a little bit about how Accenture views MongoDB and the problems you use to try and solve your customers using MongoDB.
That's a good point. By the way, we are a customer of MongoDB as well, we are using it for various things. There are multiple use cases we have with MongoDB, our teams are quite happy with MongoDB, our internal teams who are using it, we as a client, let's say. One of the cases that I want to really pick up, which is quite profound, is that we have a particular platform called myWizard, and that platform is used for all the client delivery that we do, all the solutions that we develop for our clients. We have 3,000 products on that platform. It's a very scalable platform for us. That's how we deliver work to our clients, like the software development and solution development and deployment. Within that, we have a lot of artificial intelligence built in.
We have a lot of AI patterns in there. We have probably more than 60 patterns there, they run on MongoDB. Right? The reason why, because I asked them question, "Why MongoDB?" They said, "Well, this actually helps a lot. This actually helps our AI run more efficiently." That was an excellent story, beyond that, I think we are doing great work with MongoDB. We have more than 2,000 people right now who are trained, we have a much bigger plan in the future around this, especially our architects. We are seeing a huge traction in the market around how people would like to use MongoDB.
Got it. A lot of the people in the room, obviously, are playing the trend of the move to the cloud. It's probably the biggest platform shift we've seen in maybe a generation in terms of how computing is changing. Could you speak to how Accenture is helping companies think about this move to the cloud and where MongoDB actually fits in?
I think we do. As I said earlier, I think there's a whole discussion about re-architecting or re-platforming. When it comes to data, I think the clients have a different level of maturity. We have clients in probably 3 stages of maturity. The clients who have a lot of investment done in the old technology or legacy, let's call it legacy, they want to go in a phased manner to the cloud, right? They still have a hybrid architecture, so they have a lot of stuff on-prem, they have a lot of stuff or they want to move on cloud gradually. The second is the clients who actually have taken a decision of moving fast. They call in our second bucket called modernizing the platform.
The third ones are the ones who are actually building totally brand-new capabilities and architectures, so they want to go native on cloud. We see all those three trends coming, arising. I think what we see very specifically on MongoDB, if you ask me, I was having a session with our master architects who are top of the spear, the guys who do initial define the strategy and architecture for the clients for the future. I said, "How MongoDB is different than any other database?" I think the way I understood in terms of use cases and what we're doing for our clients right now is, I think three things. One is, I think they are finding MongoDB as, just in terms of the database itself, they're finding it more easier for real-time analytics and analytics on the edge. Right?
The second thing is they're finding MongoDB very flexible for needs where data model has to be more dynamic. Like, for example, customer 360. If a customer changes fast or the customer attribute changes fast, then MongoDB is a pretty good place to go after. The third thing is when they are trying to see the integration with Hadoop and with cloud. They are finding MongoDB much more positioned for cloud adoption. Those three things came out very clearly.
Got it. When you think about the move to the cloud, I think it's maybe the first phase, the second phase, or it's first category, second category. We saw in the early days a lot of people doing lift and shift. What customers are now realizing is just taking my existing workload on-prem and moving to cloud may give me some small incremental benefits, maybe save me a little bit of cost, but doesn't really allow me to leverage the cloud infrastructure, the hyperscale environment, the flexibility and nimbleness that the cloud gives me. How do you help customers think through lift and shift versus a re-platform?
I think, as I said, I think that also depend on maturity and investment the client has and their aspiration. What we do is we usually lead with strategy first. As I said earlier, the strategy is not only defining the value of the data that they want to untap, but also the roadmap. Because I think the place where most of the people are now stuck is how do I get there? Because they know the value, they just don't want to disrupt their current business, and they want to know exactly the plan. Like, what is the plan? How much time it's going to take, how much investment it's going to take to re-platform this. The readiness to re-platform is actually much better than a year back.
When you're getting the C-level support now from the business, then I think it's becoming slightly more easier now to have that conversation. What we do is we do a kind of the first phase, which takes eight weeks to 16 weeks, depending on the maturity of the client. It's our architecture work initially, and we call it three Ds of architecture. The first one is discover. Like, what do you actually have right now? Assess what you have. You define it. You define the end state saying this is the exact target you want to get to, right? You describe it in terms of roadmap, saying that, okay, these are the things you should be doing in the first three months, first 90 days, first year, first, second year in terms of work, and how do you get there.
We have multiple examples like that, right? One example that I really like was about a joint client of ours in Europe. These guys are into energy, they're energy and utility company. These guys have more than 64 million customers. They were locked because of their legacy systems, and they wanted to get ready for the future. We proposed the architecture, which has MongoDB and what we got out of the returns after that, it's already implemented. We are now scaling it out. What the client actually got out of the entire new solution was, first of all, faster time to development now. They actually had much faster development time for their IT teams. They were able to ingest data much faster for all incremental data that they wanted to.
The third thing was that they were able to cut down the overall efficiency to the business. The business IT relationship has really improved because of the new solution and new architecture.
Data privacy and data regulation has become a hot topic these days with customers. Could you comment on what you see across your customer landscape and what trends are emerging?
In my role, personally, I'm not advisor to the client on data privacy. What I do in my role is because data privacy is a data problem. What we're doing is we're using technology to help clients discover and manage the regulators and ensure that being transparent to their customers and ensure that they can protect their data, right? With that regard, what we have done is we are using extreme amount of machine power for discovering and fingerprinting and creating visualizations for the data protection officers or whomsoever is the right person. Like, for example, in Europe, there's a GDPR regulation, and they have a very defined role called a data protection officer, DPO. How do you actually enable a DPO to be more effective and efficient in their role? That's what we're doing.
A use case in there is basically that our approach is slightly different than the conventional approach. The conventional approach is to look at the law. In GDPR, there are 90 plus articles. Look at the law. In CCPA, there are regulation in California. You look at the law, and then you look at how does the law impact your processes, and then application, and then go to data. Very sequential processes the way you look at it. What we started doing was we said, look at this differently, look at reverse way. If you're able to discover data and figure out the patterns of data, can you use graphic technologies like graph technologies to visualize it differently? That's what we are doing.
What could be done in eight months for a client, we could do it in eight weeks just by power of machines.
One of the questions we get a lot from investors is, you're going after a massive market, but how available is the market for a company like MongoDB? Given you've been at Accenture for a while, you've seen the adoption of new technologies, maybe not as good as MongoDB, but at least with other companies you work with. In all seriousness, how would you kind of think about and help customers think through the adoption of a technology like MongoDB? Obviously there's a lot of legacy applications, infrastructure people place that they're not just going to rip and replace. Can you walk people through a little bit of how a large enterprise might think about their existing workloads and how they might re-platform it over time?
I think it does require a lot of education upfront, and that's why the initial period of 8-12 weeks, 8-16 weeks is so important and critical for us, especially when you're using a new technology. Now, the question which we should be asking is, are people ready to consume more information? The answer is yes. What I mean by that is that in many instances in the past, most of the companies did invest into digital technologies in the last 8, 10 years, right? Digital was the way the money actually went, right, from our C-suite. Many companies have realized that they're not getting as much return out of digital investments because they're not taking care of data first.
We have multiple examples there where clients have themselves said that data should be in the forefront of digital transformation, not a reaction to a digital transformation. I think that shift has already happened. What we are seeing is that they are ready to invest time to understand new technology and emerging technologies. MongoDB for us falls into that category. We have a partner ecosystem, obviously, we have multiple partners, big and small, everybody. We have the partners who are our top partners, right, who are big players, as you all know including [the Max]. Then we have the next generation partners, which we call emerging partners. I think that's where the more innovative companies and MongoDB falls there.
I think right now, obviously, a lot of work we do is to just educate clients in terms of when we position a new architecture, how is MongoDB important for them and their business, and why they should be investing.
One of the other things, we've done a lot of business together. We've done business in North America, in Europe, and in Asia Pacific. One of the themes emerging over the last few years is the rise of the developer. Obviously, there's other public companies like Atlassian and Twilio and even private companies like Stripe who have done very well serving the developer community. You obviously do work with a lot of very large enterprises around the world. Could you comment on how decisions are now made around technology selection? Because, from most people's point of view, it used to be the old world top-down decision has completely been disrupted.
Maybe you can just speak from a reality point of view, since you work with all these customers, how they think about these decisions and how much influence the developer community has in an organization versus the CXOs.
I think in terms of putting the business place for the case of the future, I think it's very important to get a top-down, top buy-in in the company, because once you have a top buy-in, then you move the funding ask from being discretionary to non-discretionary. Right. That's very important. If the funding ask is discretionary, it's a small pocket of money. It's also something which can have a flex because of depending on the performance of the company. When it's not discretionary, you know that you can't run your company without that particular pot of money. Right. As soon as we get into the architectural level discussion, I think that's where I think it starts hitting the right people in the team, in the companies, where people have enough knowledge about technology.
To your point, I think we are seeing very mature people in our mature clients who actually get into conversation around why this technology, why not this technology. It goes through a few weeks of exercise in terms of just explaining and understanding why we are putting it as up. In many companies, there are very young talent now, actually. I can tell you about one company, very recently, where we were working, and they had a new CDO who joined from a. I can't name the company, but it's a very high-tech media company, right? They are very proud of what they have been doing in terms of doing DevOps and releasing a code every day right into production. When this guy joins in, their systems were working on 6 months of release cycle.
They were trying to think about three months of release cycle. This guy came in and said, "No, I want a one-day daily release cycle." To have that disruptive mindset, you have those young people and young generation, I'd say digital native technology leaders, who are able to challenge that. To your point, yes, developer community is very important. They actually participate in the process of selection as well. We are seeing that trend.
Great. When you talk to senior-level executives, what's top of mind for them, irrespective of MongoDB or even data? If your teams bring you in to talk to a senior-level executive, invariably, where does the conversation go today?
I think, in my view, there are three things which I see which are burning up as a conversation. The first one is, as I said earlier, I think the discussion at the C-level about data and the power of data. The discussion that we are landing up right now is, if data is a subject at C-suite, do you have an identified person at the C-level who's accountable for data? Right. That conversation started happening.
How many people answer yes to that question?
Very few. Right. We normally find C minus two, right, in many companies. By the way, this is a bubbling up topic right now. It's a very good discussion right now. Is there somebody in C-level who actually owns data? Again, the person cannot own the data because the business will say, "I own the data for my section." There's somebody who's an orchestrator, who's a facilitator of this whole discussion about data governance, the quality of data, those topics, and how do you measure the strength of data, the power of data. That discussion is happening. That's number 1. The second is a very big discussion about platforming and re-platforming. Everybody now wants to have a data platform because they know the value of data.
That's a big discussion happening, and that requires investment, and that requires a roadmap in terms of how much time it will take for me to become an intelligent enterprise in the future. The third thing is about talent. Talent is not only about the people, like you were saying, and the people who are more knowledgeable or more experts in the company, but also the business user, whether they can consume data like the way you would and decide. I think there are three sets of users in there. The management users on the top or operation leaders. The second is the business users, and the third one is the people who are in the core function and experts, deep experts, who have a full-time job of converting new capabilities or building new capabilities.
Terrific. I think we're out of time, thank you very much for that insight. That was super helpful.
Thank you.
Thank you.
Thank you. I hope it's useful.
Thank you.
Thank you.
All right, we're just going to take a five, literally only five-minute break, 1:45 P.M. back here. Let everyone use the restroom as needed and get the customer panel and everyone mic'd up, and then we will start up in five minutes. Thank you.
Actual dialogue going on. Maybe a little excitement in the afternoon.
That's good.
You can also spread these out a little bit.
Yeah.
Hello.
Okay.
We're going to get started. Brian, if you could help escort people back in from the outside. Try and keep us on time here. Yeah, exactly. There we go. Fantastic. Maybe we can turn this off.
Sure.
Do we need this? Can I turn that off?
can turn that off.
Okay. I know the door's open. Okay, I'll wait till I get the all clear signal. Thank you for being so prompt in coming back. Are we good, Bertie? Okay, door closed. Brian, thumbs up. Thank you. We'll have a few stragglers coming back, thank you all for doing that. We wanted to try and take advantage of the fact that we have a bunch of customers here presenting at MongoDB World, to share some of their stories, talk a little bit what they're doing. I will attempt to moderate this vocal and opinionated group, we'll talk a little bit about what they're up to and everything else. With that, before we get started, though, I'll just let everyone take a turn and introduce themselves.
A little bit about your background, your company, how you're using MongoDB, we'll just have a free-form conversation. Manish, why don't you take it away first? Thank you all for being here.
Hi, everyone. Good afternoon. My name is Manish. I work for RBC, that is Royal Bank of Canada, I'm from Toronto. Yeah. Thank you.
Congratulations.
Home of the champions. I had to get it in, otherwise my kids won't forgive me. In RBC, my role is I'm the director of digital engineering or digital software engineering. What we do is we build applications for our wealth division. It'd be mobile application, web application. Yesterday, I had an opportunity to present our digital transformation journey, what I discovered was that a lot of my partners from other companies, I think they are going through almost similar journeys. It was very interesting to get their feedback. Thank you, Mike, thank you MongoDB for that and inviting me here. Thank you.
Hi, my name is Prem Timsina. I am from Mount Sinai Health System. As you know, Mount Sinai is one of the largest health system in New York City. My role is lead data science engineer. We develop operational machine learning software for the hospital. Currently, we have deployed multiple machine learning software, multiple machine learning use cases across the four or five hospital in New York City. The role of MongoDB is we have created the Data Lake using the MongoDB for our machine learning platform.
I am Kieran Clewlow. I am all the way from Sydney. I think I have come the furthest out of everyone on the panel.
Yes. Panel award for that. Yes.
Yeah, thank you. Yeah, I am the Director of Data Engineering at a company called IAG, which is Insurance Australia Group. We have about 23 brands in that. We are the largest general insurer in Australia and New Zealand. Data engineering, as it says on the tin, is basically all the acquiring of data into Data Lakes and real-time acquisition and streaming, all those sort of good things. We have been here with my compadre, Simon Aubrey. We have been here to talk about single view of everything, which was an approach that we took using MongoDB and Kafka and Kubernetes to acquire information and resolve it we get a coherent view of our customers' assets and who they are, we can make their world a safer place.
Great. Thank you. Gary?
Yes, my name's Gary Russo. I work at TD Ameritrade. I call myself a NoSQL architect and developer. I've been at TD Ameritrade for about three years. I've been following this space intensely for the past 11 years, probably. I used to work for one of Mongo's competitors. I remember my boss at the time left and joined Mongo, became CEO for a short time, a guy named Max Schireson. My purpose for joining TD Ameritrade, before TD Ameritrade, I was working as a freelance consultant. I was consulting at Broadridge Financial and working at HarperCollins. I was doing work for publishers and financial companies. I do see NoSQL, Mongo in particular, as a force for good. It makes organizations more efficient, more successful. My boss becomes more successful. My team members become more successful. There's a higher success rate with Mongo and these NoSQL solutions.
Great. Maybe if we could talk a little bit about some of the challenges you were facing and what you turned to in terms of new technologies. Obviously, ultimately, at least in some of these cases, it's MongoDB. What were the challenges you were up against? What were you trying to solve? What things did you consider, and how did that process unfold? You just take turns or just all chime in here.
Okay. As almost everybody who is running any company today cannot survive without digital solutions. We, on the Veltas side, started our journey about three years ago. We had a team of three or four people. Now, today, we have a team of 40 people, and we are building mobile web applications for our users. There are multiple challenges. I think the gentleman earlier from Accenture talked about challenge with data. The challenge with talent, how do you get the talent you need? You're competing not only with your TD and other partners of ours, but also small startups. Talent is one. You're talking about challenge. Challenge is talent. Creating a culture within a big corporation, which is similar to startup, you need to change a lot of minds.
For example, yesterday's talk, one of the examples I gave was I was interviewing a developer, and you can see I put on a jacket because it was investor conference. This guy shows up with a half-sleeve shirt, arm full of tattoos, and very impressive young man. I asked him, "Why do you want to join RBC?" I thought he would answer like, "Oh, I want to help RBC become even better than number one." What he said was interesting. He said, "I want to work downtown." The reason I said, "Why do you want to work downtown?" He said, "Downtown, I can catch better Pokémon." I don't know whether you guys remember the Pokémon game.
Yeah.
That's the kind of talent we are hiring. When you are hiring talent like this, I should just call them kids. They're fantastic. Don't get me wrong. They bring so much energy, enthusiasm, and the hunger to do something, to achieve something, to build something. They are not competing. We think about TD or others. They are thinking about competing with Google and Facebook, and we have to calm them down. This is big company here. That means that we have to empower them with the tools that they want, not That gentleman talked about top-down or bottom-up. The key thing is, for me, is to create a builder-centric organization, a team where builders are valued, because sometimes in big companies, you can be drowning in regulation and rules and things like that.
How do we open up and create a safe space where these kind of developers can build? MongoDB is one of the tools that could be centered on.
The focus of our main team is to build the operational machine learning software. We are building the machine learning platform for The Mount Sinai Hospital. Around the data storage and the database, we identified the two main challenges. One is the single view. When we input the data before the machine learning model, we need to combine all the historical and real-time information of the data and create a unified view of the passing information. Only we can input into the machine learning software. We found the MongoDB has a good mechanism to create a single view and storage of the single view. Another good thing was we are getting the data from the eight hospital in New York City, and each hospital has dozens of database.
Is the data, some are the textual data, some are imaging data, and some are structural data. We do not have control of the schema from all those dozens of databases from those eight hospitals. We are also looking for the database who has a very flexible schema. Those two things were main decision-maker for us to choose the MongoDB.
Single view of a customer is a very common, one of the early sort of use cases of MongoDB. What are some of the challenges? Why is this a use case if you're trying to build that out? Why is that so hard in other databases?
I don't want to pinpoint on any specific database because I don't want to injure anything. While we are doing the POC for the machine learning platform, we did review of the major SQL databases and major NoSQL databases also. We finally thought that, okay, MongoDB is optimum for our use case or for creating a single view.
Kieran, you guys did some single view work as well, didn't you?
Yeah, that's right. That's what we've been presenting today.
Yeah. Why don't you talk a little bit about some of the challenges and just for a less technical audience, it doesn't sound that hard, right? Creating a single view of the customer. That ought to be easy. Why is that not a thing that you can just do?
Yeah. If you think about the commercial context and history of IAG. IAG is a very large organization, and it's quite, I wouldn't say dominant, but successful in the market. Like many insurance companies, they tend to typically grow by acquisition. You go and buy little ones. Every time you do one of those acquisitions, you get another data environment and another view on each of the subset of customers and what their interests are, what their assets are, that they're being protected, and what properties they might be living in. It was historically very easy for us, say, for NRMA, which is our largest brand, we could say how many customers on any given day we have and how many customers we might be gaining, hopefully.
If I wanted to look at that from the entire picture of IAG, that's a very different challenge. It could take days to work out and resolve all the different datasets that are involved. As our commercial context has changed, and every industry's got this, where things are speeding up and it's no longer sufficient to run an overnight ETL and bake a cake and then eat it in the morning of data. Now it has to be like a real-time pipeline, right? Like a river of information constantly changing, so that we can serve our customers much more effectively. That's essentially what was driving it. We didn't just use MongoDB for that, we used really a triad of technologies that allowed us to address that challenge, which is Kubernetes, Kafka, and Mongo working together.
It's very important just to point that out. That really worked for our context. Yeah, that's kind of the driver.
Roughly how long did that take? Was that the first thing you tried or were there other things you tried? How did you try and solve that problem internally for that sort of visibility and intelligence?
Yeah, the single view of, I think the first time I saw a reference to when I started at IAG two years ago, I did some background research and that project's been kicking around for a decade, I would say.
Internally?
Internally. There's been many attempts at it with varying levels of success. Once we cracked that nut architecturally of getting the right kind of platform singing and working together, the velocity really accelerated and we started to really see some very impressive delivery streams. We got a lot of plaudits from the executive team, so that was good.
Great. I think when we talked beforehand, you were saying originally MongoDB was not the first thing you tried. Eventually, as you canvassed the landscape, that was the one that greased the skids and made it all possible.
Yeah. There are many obviously out there, but it was really more of that document store approach. I think traditionally we were using relational database systems in order to do the serving layer of the data. The problem with that was it was just a little bit too inflexible, and it meant that the UI developers had to dig into the detail of the very complicated data structures that were involved. With a document store, we could take information that was very rich, say from NRMA, which might have 150 attributes about an individual customer, and match that with another data element that might have six. We can just manage that in a much more sophisticated and easy way with a document database than we could with a traditional relational database.
Gary, you want to talk a little bit about the challenges that you all face at TD Ameritrade and what technologies you considered and how you've gone about that landscape?
Sure. At TD Ameritrade, when I joined, my sales pitch has been I specialize in breaking down the silos. We have, like most shops, hundreds of databases. It's really difficult to join across all those databases. I've been preaching this for years now. The ideal way, we're in this post-relational database era now, there's no doubt about it. I don't mean to offend any of the relational folks. I remember Dwight Merriman and I used to attend these Mongo World meetups years ago. He used to talk about how 15% of our data will always be relational, 85% will be non-relational. I think it's going to be more like 95% non-relational, 5% relational.
The challenge at TD Ameritrade was that it's buried in rows and columns, buried in rows and columns in these cryptic databases with cryptic field names, and it makes things really difficult. Productivity is terrible. You can have a high project failure rate because you can't really aggregate what you want to scoop another database and try to merge. Anyway, the ideal approach is a JSON document data store. Denormalize it. We built this thing. I first joined, I made a commitment that I'll design this thing, and we could have consistent sub-second search and query capability against terabyte-sized databases, guaranteed. We've proven that. We've built this new system. It's been running for the past 36 weeks, and it's been running pretty nicely. Yeah, my message is, don't shred your data into rows and columns anymore.
Of course, maybe 5% of your data is always going to be relational. Let's slowly start to move that into a non-relational solution. Be more productive. Embrace search. The announcement this morning was fantastic, with Lucene search coming into Mongo. Database engine and the search engine really should be the same thing. There's no need to have bolt-on search. All the extra infrastructure, all the extra cost, all the extra support needed to do that. When you centralize it into one, I call it one MongoDB data hub, you're going to see a tremendous return on investment.
Great. We talk a lot about innovation, and obviously a lot of you spend time thinking about that. Can you just put into context, what's the role of the database in that when you think about overall innovating applications? What are the differences among the databases, and how much of an impact can that have?
Good question. Yesterday, we were chatting about MongoDB and how you guys recently went public. In my career, I worked for a database company called Sybase. They used to rule Wall Street once upon a time. Somebody said that it is a coincidence that Sybase went public 26 years ago, and MongoDB is the first database company going public after 26 years. What that tells me is the pace of innovation on the database side hasn't happened as much as we would like. I'm sure people have increased features and et cetera, but in terms of disruptive change, it hasn't happened. The document data model brings that disruptive change. Again, going back to the theme of developer or builder-centric organization, and the other gentleman also spoke really well on that, is how do we empower our teams to do two things?
Time to market, which is speed of development, the other thing for digital transformation, most important thing, is the user or the client. What is the client experience? If your stuff is slow, client doesn't want to use it. three seconds seems too slow now. I don't know whether you have kids, but if anything takes two seconds, three seconds, and they're like, "Oh, it's so slow, Dad." Right. The same thing happens to the client because on mobile application, our clients are measuring us against not our competitors, but Google and Instagram. In any company like ours, right, we have so many systems and applications which have evolved over time. They're so separate. Some applications cannot serve your data fast enough. For us, the innovation was that we have the whole alphabet through of technologies that we have implemented.
You name, Bertie said Kafka, you got Angular, we have Node.js, we got everything. What do we do about data? Data being the key part of the innovation, as I said, it hasn't. We thought document-centric data models does two things. One is that developers are designing the data model. If I'm saying the right thing, few years ago, you wanted to add a field in a column, you had to get a ticket. Somebody will check your data model to make sure it's true or whatever. It will take weeks before you could do anything. Give you one example. As we learn more about Mongo, we are expanding the use cases. We started out as a, you said about OneView. We have a OneView for client or our advisors across so many applications. They don't need to go through so many applications.
They just come to the mobile app on a golf course. They can see what client is doing. To do that, we bring the data from various places and aggregate into Mongo, that we serve. We are expanding the use case. One of the use case is to take one of our application off of the SQL Server. What was amazing was that we designed microservices and Mongo data model at the same time. Amount of time we saved, for the time to market, is amazing. I think the whole concept of this document data model. By the way, today's keynote speech was amazing. You mentioned about search. We use Elasticsearch, would be great if you had one place where we could do both. I think innovation is happening, and Mongo is doing it at the data level.
I'm very glad. Thank you.
For us, the real helpful was document and NoSQL storage. For example, when you get the raw data, you don't have control of what data you get and what column you get. If you are storing in the SQL database, you need to transform and select only the specific column and store it over there. With the NoSQL, you can store all the raw data, and what you need, you use now, but in the future, you may need to use other data. You can just pull from the raw data. Another important was the single view. For example, now we don't need to join in the real time seven or 20 or 30 tables together to create a complete picture of the patients or clients.
In our team or in our MongoDB database, we always have a current single view of the patients all the time. Those two were the really important. For us, another one was the change stream also. Most of our, for example, use case works out of the change stream. When you get the raw data, we directly store into the MongoDB. From the MongoDB, through the change stream, we get the database update, then it goes to the Kafka, from the Kafka, we have tons of the ETL and machine learning engines running.
Prem, can you talk a little bit, because we use terms like single view of a customer or people talk about artificial intelligence and machine learning and these sort of buzzwords. Can you talk a little bit about the actual applications, right? You're a hospital system, and you're using this to actually impact people's lives and health outcomes. Can you talk about that a little bit?
Yeah. I can talk about the one use case, which is going to be in a clinical trial from today. If a nurses or doctor input any patient information to the electronic health record, suppose blood pressure, they input into the electronic health record, and through this pipeline is coming to our data science platform, we predict what is the chance that patients will go to the ICU or operating room in the next six hours. We generate the probability scores and top procedures, if the probability score is very high, we send the alert into the iPhone application. The plan is, our clinicians or the nurses do some kind of the intervention, and we prevent the patients from going to the ICU or the operating room. That is one real-time use case.
Another use case, which was very successful for our team and for the hospital, was malnutrition predictive engines. It is quite different than the common malnutrition, what we understand. It is in-patient malnutrition. Patients may get the malnutrition because their body cannot digest the food, and so the interventions will not work. Every day we predict what is the chance that patient is generating the malnutrition. We create a probability score and write it to the electronic health record. When the registered dietitian start their shift, they do the descending order based on the probability scores and start to look at the patients who have the highest probability. We started with The Mount Sinai Hospital. It is deployed into the other three hospitals. Currently it is running in the four hospitals and it was very huge success for us.
[Basant], thank you for sharing that. We obviously like to pride ourselves on our mission-critical applications and everything else, but then when you hear about real life things affecting human lives in that way, it's really remarkable. Kieran, do you want to talk a little about innovation and the bottlenecks or enablers that are created in the database layer?
Yeah. I think all of what was just said, because I think it's exactly relevant to what we do as well. Just the speed to market, excuse me. Speed wins. I used to work at TripAdvisor, and Stephen Kaufer, that's his motto, so I've lifted it from him. It's really important for us to move quickly because the business is accelerating. The time it takes to decompose a really complicated data model and put it into our relational data structure, and also the inflexibility of that to an extent of how do you make changes to that as the business changes and the developers' desire for what they want to design changes. It was just too slow for us. Particularly in this space, which is about customers, which is very important to us, we really need to move quicker. This allows us to do that.
That's essentially the driver for us.
Gary, anything you want to add on that front?
For me, it's also about agility. Application developers have been using agile development techniques for across decades. Finally, we could do this with database, right, using this document data store. We could be agile with our database development and develop that. We need a strong developer culture, like what you said there, Kieran. At Ameritrade, we do have that. We have our camps. We always have healthy debates about what database to use, it's always a healthy discussion, a democratic process. I always try to come to the table with some hard evidence to show where the value is, how we can be more productive.
One of the things that we try and do in these settings is take some of the more technical stuff and help investors who might not be as technical understand it. When we talk about the difficulty, what's so complicated about a relational database, or why does it create that overhead of that tax you're describing that sort of impedes the speed and impedes the innovation? If you can try and put some of that real-life technical complexity in plain English, maybe that'll help folks a little bit. Anyone? Yeah, sure.
I'll have a crack at it. Essentially, what you're trying to do in a relational database is take all the information, say, about a customer. A customer might have name, address, postcode and all those kind of good things and telephone numbers. It also might have, well, I need to know that Kieran is married to Katie, and Katie lives at the same address, so they're probably related. You build up these very complicated data structures that say, okay, this is the name, the customer's name, and then there's an address table, and that needs to be linked. Then you need to have a partner table to say, okay, there's a join between Kieran and Katie. As it grows, it becomes more and more complicated, and those relationships become harder and harder to model. To your point, Gary, it's inherently anti-agile.
It's a very waterfall process because you need to go away, and typically, a database administrator or architect will go and design this, and then they'll implement it. It doesn't lend itself to modern developer practices where you want to just very quickly iterate over that design as you come up with it and then put it into production. Yeah, that's essentially the driver.
Hopefully that helps a little bit. I don't know if anyone wants to add anything.
These days, I think most of the people are technology-savvy. If I go down to the physical example of what's relational versus what's document-centric is, think about you were asked to store some documents. You pick up folders, and you put customer, like somebody said about, say, invoices. All the customer data in one folder, every customer has a little form, and then you put all their invoices in another folder, and then you have all the stuff on that invoices, all the stuff they bought in another folder. That's relational. Then you want to find the invoice for Mike. First you go to Mike's. You find, oh, Mike is number 22. You go to the invoice folder and find that invoice number 22. That's relational. What document-centric is
You take Mike's record, you take his invoice, and you take all the items on that invoice, put a pin on it, and put in the same folder. When you find Mike, you find the items and the invoice all in one shot. Right? Now, there are some challenges with documents compared to relationals, like reporting and such. What has happened is, companies like MongoDB have taken that document-centric, which is much easier to understand and manage. There are some use cases, some things you want to do, they have solved with back-end technology. Instead of saying, "Okay, I can't solve reporting, therefore I'm separating everything," now we can keep it all together. Because most of the time on a website when you go and you are looking up invoice, by and large, you're going to go, you sign on.
You need to know the customer, then you're going to click on the invoice that is right there. It's all together ready to go, and I think that's the difference.
Great. I think we would be remiss if we didn't talk at least a little bit about the cloud. Obviously, some of you are public companies, and it's hard to share different information and everything, but any insight you can give about where is your organization in terms of public cloud adoption, how does public cloud factor into your thinking? Anything you can share or trends that you're seeing around that that would be helpful for folks just to sort of understand from a macro perspective. Who wants to go first? Gary?
Sure. I think I can talk about TD Ameritrade. We're definitely looking at cloud, but it's not going to be overnight. I think we're doing it on a case-by-case basis. There's some project going on. There was a Data Lake project they were looking at using Azure to host it. My application I've been working on for institutional investors, it requires a lot of high disk IO. We have a weekend, we have these start-of-day batch jobs and these end-of-week batch jobs. It requires 300,000 documents per second. I need to ingest documents at 300,000 documents per second. I can't do that with any cloud solution that I know of yet. I think the fastest to do something like that, I need to use disks that can do 150,000 IOPS. I think Azure offers that, but it's very expensive. It's really cost prohibitive right now.
I think it's much cheaper for us to stay on-prem. I think we'll be the institutional products that I work on are probably on-prem for the next 10 years, honestly. Slowly, we're going to be moving towards the cloud. I'd love to use Atlas at some point, but eventually.
I was just telling Dev that I think the Atlas product that you guys have created is a game changer for you because, for any big company like RBC, there's multiple clouds, public clouds, that you don't want to put all your eggs in one basket. You also usually have on-prem, right? The great thing about MongoDB is that you could have it on-prem as well as any cloud. In that space, especially in the document database space, that's probably only game in town that does that, as far as I know. I think from cloud perspective, you guys have some good offerings.
For us, because of the HIPAA, getting the IT security approval is kind of very slow. We are going through the IT security, and maybe probably next year or in next two year, we'll be starting to use the cloud. We are interested to use the cloud. It just be like getting through the IT security takes a lot of time.
Yeah. We're regulated in Australia by APRA, which is the financial services regulator in Australia. Really, the challenge for us has really been more of an internal one at IAG. APRA is pretty fine with what you can do, as long as you can do it safely and convince them that you can. I think there's a mindset change that has to happen about cloud adoption, I think, internally in an organization. We've gone a long way down that road now. I think in the digital space, they're a little bit ahead of us in data, but we're very much looking towards, in the short term, really, moving things into the cloud. We already have with our single view of a customer workload is already in Amazon.
That was the first time that we got that certification from APRA to put customer data or PII data, as we call it, into the cloud. That was a real win for us, and we're looking to move much more quickly now on that road.
Terrific. Well, thank you for that. The clock down below me says we're out of time, this was great. Gary, Kieran, Manish, Prem, thank you all for coming and for sharing your thoughts. I really appreciate it. We'll get Eliot and Dev up here, and we'll do the executive Q&A. Hey.
Try it again.
All right. Home stretch. This is really the open format portion of the program, where we've got Dev and Eliot, we can take questions, and we'll dive right into it. Itay. We'll get you a microphone.
Thanks, thanks for hosting us for a very interesting day. I wanted to dig into the search
It was interesting how you're cutting Elastic out of this equation. I guess, related to this, what other adjacent capabilities that you see that are being performed by third-party elements that are required in deploying a database like yours, do you think in the future you can bring in into the MongoDB architecture? How do I think about the limits of what you want to do versus what you never want to do?
Yeah. We don't have a list that we're just going to like, "Here's the three markets we're going to do next." I think the way we think about it is, what are the areas where developers are struggling the most, where the philosophy behind MongoDB, namely the document model and distributed systems, can really help. That's sort of the mindset. Text search is a great example where people are using MongoDB, and they're sort of struggling right now. It's an area we can sort of address the problem. Charts is another example. If you had asked me five or six years ago if we would build Charts, I would've been like, "Maybe." If someone else came along and made a really great visualization tool for MongoDB, we probably wouldn't have built Charts.
It's very important for our users that they have a great visualization tool, so we went ahead and built Charts. Same with text search. Data Lake's a little different, where it's an adjacent market very much based around the same philosophy, right? People want to use documents. They have a lot of data, they want a different kind of query language that's very easy to use to look at that data. That's sort of the lens we look at, is how do we make developers' lives easier using sort of our query language, taking advantage of documents and distributed systems. That's how we sort of decide from there.
Just to piggyback on that, as you think about the future friction points that you want to kind of bring in in order to eliminate and create smoother adoption, better experience, do you envision all of these things just coming in as part of the platform, or do you see an opportunity in the future to price separately elements, create tiers such that you can better monetize some of these efforts?
Data Lake, for example, already is like that. Data Lake is priced. You can buy it as part of Atlas, but it's not part of Atlas. You buy Atlas credits, but it's charged separately. It's all pay-per-usage. If you're using Atlas today and you're paying for three clusters and you start using Data Lake, you will just get a separate slice of the bill that is the Data Lake price. Sanjit, I think is next.
Thank you. Sanjit Singh, Morgan Stanley. Thank you for hosting us. This was a really informative session. If I think back to last year's Analyst Day, the message to me was, Atlas is coming, in terms of relative to feature parity with Enterprise Advanced. The message last year that we're getting there. This year it feels like we're there, and Atlas is sort of pole position in terms of features. I guess the question is a little bit related to Itay's questions in terms of monetization. As Atlas becomes the sort of face of the company, how do you think about when you move into areas like search, and whether you monetize that directly and versus something like Azure Data Lake, where you are pricing versus.
Can you just walk us through how you're thinking about the monetization of Atlas going forward and what that could mean in terms of Atlas revenue per customer?
Text search is an interesting one. Even though we're not charging to use text search, everyone who uses text search is going to need to use more Atlas resources. You've got bigger disks, you use more RAM and more CPU. Anyone who uses text search is automatically going to get a higher Atlas bill. Adding a extra cost on top of that didn't seem to make a lot of sense. In addition, one of the big reasons why we think we're so excited about it is that it's about bringing people who are not using Atlas today into Atlas. Sort of driving adoption of Atlas even faster. Data Lake's different, right? Data Lake's a totally different product going after a different market, where monetizing it directly makes a lot more sense. You've got things like Stitch and Realm, which are somewhere in the middle.
They're both really good at driving adoption. Triggers and Atlas you do pay for, it's not priced in a way that's going to drive a massive amount of revenue directly, it's about, hey, I'm not using Atlas today. What are the most compelling things we can do to get people who are running MongoDB themselves to migrate to Atlas?
That was very helpful. I may have a question on the partnership strategy. It seems that IBM has been very successful. Accenture's been ramping. As we think about the next couple of years, what do you guys have to do to take that to the next level in terms of your overall partnership strategy, including potentially doing something with Azure, Google just started this year. Is it about product roadmap, or do you guys going to have to sort of enable the channel, enable the partners with training and to get them ramped? What are the key ingredients to get them to scale?
I'll say, if you look at the Gartner MQ quadrant for people who do Oracle services, the top 2 SIs are Accenture and Infosys, and our relationship started with Accenture and Infosys. They're seeing firsthand how the market is changing, and they're the ones seeing how as application requirements change, the move to the cloud, people are trying to get off these legacy architectures. They're very motivated to build practices. Moreover, they're also building practices around what they call cloud migration factories. They're basically helping customers think through what is their on-ramp to the cloud and what applications or workloads are best suited for cloud today versus tomorrow or in the future. We play a big role in all those endeavors. We have a partner team who goes out and actually pursues these relationships because these are all large organizations.
They know about MongoDB, trying to drive some momentum and critical mass does take some effort on our part. You'll probably see us expand those relationships. We've done deals with TCS and Wipro, Capgemini has really accelerated in Europe for us.
You're going to see us partner with people who either have some geographic expertise or maybe some vertical expertise, who do some work with boutiques around the financial services industry. The other thing that they do for us is reach. Right? Remember, even though we're growing really quickly, we're going after a massive market, and we just can't hire people fast enough. Being able to get quick access to decision-makers, quickly understand who's who in the organization food chain, and also give customers the confidence to bet maybe bigger on MongoDB because they have a trusted advisor recommending that they use MongoDB, all helps to create that virtuous cycle.
Just the only other thing on the partner side that I've tried to remind folks of is while they're incredibly helpful extending reach or getting us higher in an organization, they're not acting entirely independent or on autopilot. It's not like it's all just sort of incremental deals that just fall in the salespeople's laps. While it's additive to sales productivity, it requires a salesperson from our side to be involved and help alongside with the partner, just so people sort of don't get overly carried away with sort of the impact of that.
Thank you. It's Brent Bracelin with KeyBanc. Two questions, if I could. One technology and one go to market. On the technology side, I'd love to get your view around this distributed asset transaction support. We heard last year, obviously, ACID 4.0 was a big addition. My question on the technology side, how much pent-up demand for larger customers is there? How important is that kind of feature set? One follow-up on go to market.
It's pretty important. The reality with transactions is that a lot of customers want them for a very small percentage of what they need to do. The bigger factor really is they don't even think they need them today. The bigger question bigger enterprises have is, "What if I need them two years from now?" Not having them was sort of a risk they didn't want to take. Okay, you've convinced me I don't need transactions today. This workload, this application, you're right, I don't need transactions. What if, for some reason, two years from now, I do? Not having them is a big risk. I think a lot of it's just the confidence that no matter what happens in their application, no matter what requirements come down the road, they're still fine.
As opposed to, it's not going to be 1,000 customers who are going to be like, "Okay, now I can use MongoDB." It's much more the, "Okay, now I'm much more comfortable betting even bigger and more mission-critical apps on MongoDB because it's safe.
Super helpful. Second question on go to market, you talked a little bit about kind of new triggers that you're seeing with the benefit of Atlas, particularly for kind of SMB and mid-market. My question really is just around frame the momentum and upside that you're seeing in the last year around Atlas. How much of it is driven by these new trigger points? As you kind of see an opportunity to see self-service have a bigger part of the business, mid-market really starting to flow in on kind of design, prototype, test. These are segments that you didn't see revenue triggers before. How much of that's driving the growth versus still those bigger customers going from a test environment with Atlas to production?
Yeah. Sahir talked a little bit about some of the way that the intelligence that we get from Atlas, as opposed to a self-hosted situation, is providing action plans, kind of best available action for sales folks and folks in customer service. I'd say it's pretty early on in that, I would say the success that we've had historically, and it shows up in the numbers, has really been through what we've done in the enterprise and the corporate channels. Atlas has certainly been additive to sales productivity, as we've talked about in terms of velocities, time to sale, follow-on sales, all those kinds of things. In terms of the actual mining of the behavioral patterns that indicate triggers for now would be a good time to call or reach out on topic X, I think we're still pretty early on.
Brad Reback with Stifel. Michael, as more of the Atlas business goes to contracted from one-third today to whatever it may be in the future, what impact does that have on the financial model? Thanks.
Yeah, sure. The Atlas business, a lot of times people, I think because they've been struck by the growth and we provide a lot of visibility and reporting on it, tend to think of Atlas as quite monolithic. I think it's important to understand it's really two separate channels. There's the self-service side of the channel, and then there's the sales sold side of the channel. Understanding or disaggregating the business in that way, I think, is helpful to understand some of the financial characteristics to Brad's question. Revenue on Atlas is all consumption-based, that's sort of without regard to how it's sold. Increasingly, we are seeing Atlas being sold not in annual upfront contracts with cash paid upfront.
As customers have become acclimatized based on how they interact with all the other cloud players, the way they're becoming used to consuming cloud as a service is metered usage paid for in arrears, right? Even if I sign up for an annual commitment amount, I have a $1 spend that I've committed to spend over the course of the year, unless I'm a large corporate entity where I don't really think about my cash and I'm happy to pay for it annually in advance, I tend to want to be billed for that monthly in arrears, even if I have a committed amount. You'll see that flow through in terms of, I get no change on the revenue side, but the real impact therefore will be on how much are we billing a customer, and what is really the impact on cash flow, right?
Just sort of being aware of some of those dynamics and the trends is helpful and important.
Hey, thank you. Tyler Radke from Citi. I was hoping you could talk about how the relationships with the cloud providers have evolved maybe over the last year. I think in the past
Maybe Microsoft hasn't always had the most partner-friendly kind of ecosystem, maybe there's some signs that they're changing that as you see Google being more friendly to the open source community. Just walk us through how you've seen that dynamics change and if you see a more favorable outlook going forward.
Yeah. I'd make a couple points. One is each of those cloud providers told us proactively that MongoDB was one of the most popular technologies in each of their respective cloud platforms. They actually funded the deployment of Atlas on their particular clouds. We started in AWS first, and a year later, we rolled out support for Azure and GCP. I should also say that because of the popularity of MongoDB, about three years ago, Microsoft came out with Cosmos. They actually first called it DocumentDB, but then they renamed it Cosmos. A part of Cosmos' value proposition is that they had an emulation for MongoDB.
Now, I just want to remind everyone, most people may know this, but our licensing mechanism prevents any cloud provider to just take our open source code and go plug it into their cloud and go compete with us or offer a third-party managed MongoDB service. They can only emulate our features. Because you're emulating features on a very different architecture, the feature and performance characteristics of their offering is candidly not very similar to what we do and really doesn't offer all the new features we offer today, let alone what we just announced in 4.2. Obviously, Microsoft doesn't break out its MongoDB business and Cosmos, but our sense is that it's not gotten a lot of traction. That was three years ago. I think in January of this year, Amazon introduced DocumentDB, again, for the same reason.
They saw the success of both the popularity of MongoDB and obviously the success of Atlas, and I guess they assumed that they could try and also get a piece of that market. Again, we don't really see them in many deals today. We've yet to lose to them on a head-to-head bake-off, again, because they're based on a relational architecture with a MongoDB API on the front end. They cannot deliver on all the features we have, nor the performance characteristics we have. We've actually published detailed blogs on this on our website that you're more than welcome to read if you haven't done so already. In terms of the nature of the relationship, I would say it's in the spirit of competition.
Google, on the other hand, has made a very conscious decision to partner first, their decision was that they want to do what's best for the customer, rather than basically try and use, it may come across too pejorative, a bait-and-switch approach, saying, "Hey, we want to leverage the popularity of MongoDB, but get you to use our version of MongoDB, which is only available on our cloud." They said, "We're going to be very open." They came to us. We proactively worked together. If you go to the Google website, the marketplace has MongoDB available. Later this fall, Atlas will be on the GCP console. There's work going on right now to make that happen, so when a user logs into the GCP console, they can invoke an instance of Atlas. We think that that will be quite helpful.
We're already partnering in the field, we partner in the field with all three vendors. We're working with Amazon for their accounts. We're working with Google where they have a presence, the same with Microsoft. I would say it's a spirit of competition. Obviously, the only difference is with Google, there's no real alternative.
Great. Then a follow-up from Michael. Could you just walk us through how we should be thinking about gross margins going forward? Obviously, Atlas is a much different cost basis than the EA, especially as you roll out features like this search capabilities, where it sounds like that's actually going to trigger more resources on the public cloud. Is that going to be detrimental to gross margins? Just how should that trajectory look like from here?
Yeah, sure. As we've talked about, just for those who are newer to the story, Atlas is lower gross margin principally because it includes the underlying cost of the infrastructure embedded into the service that we're providing to customers. In general, as we've been able to grow Atlas, it has not materially impacted our gross margins with the exception of once we acquired mLab, which was at a lower gross margin still. You saw that show up in Q4 and Q1. The mLab impact should dissipate by the end of this year. As we continue to expand Atlas, we're seeing organic Atlas gross margins expand. We've been very pleased with the organic gross margin expansion and progress that we've made.
If I disaggregate that into pulling the levers that we expected to pull and what kind of bang for the buck did we get on those levers, I would say we've pulled the levers that we wanted to pull in line with the plan or on time or slightly ahead of schedule. So far, we've gotten more bang for the buck than we expected. We've been really pleased with the overall gross margin performance. We'll continue to have some degradation over the next several quarters. We're a couple quarters into that sort of shallow U that I've described consistently. I don't think we expect to see margins fall off a cliff. Most of the services that we're adding within Atlas or the Atlas family, or however you want to think about it, tend to have very little infrastructure associated with them.
There's certainly some that will drive up more infrastructure costs, and we'll have some of that gross margin drag or whatever. In general, we see the portfolio in aggregate being accretive and that over time, the difference between kind of the MongoDB Enterprise Advanced package and the Atlas packages will decrease. We've learned nothing, certainly I've learned nothing since going public and as we continue to execute on our game plan and on our roadmap, that has dissuaded me from saying that we ought to be able to achieve our long-term target margins, which as we described at the time of the IPO, we're at sort of that 70%+ of the gross margin line, and I think we're tracking nicely for that.
Hey, from Barclays. Dev, in the keynote you talked about one thing that you really liked was the changes to the curriculum for the high schoolers in India. Maybe just frame it a little bit broader. Talk about the developer ecosystem or the developers out there, what kind of made Oracle big in the early years. Where are you standing in terms of that ecosystem of developers out there? The second question is more around the Data Lake. Just to try to understand it better, if I take data, like the cold data out, and just have it stored in S3, does that kind of make my Atlas deployment on the higher cost storage, kind of smaller and you have a kind of a headwind that you kind of face, but then you get back at the deployment? Just trying to understand the things there better. Thanks.
Yeah. Sorry. The first part of your question was.
Developer
developer ecosystem, sorry. I'll give you a couple data points. One is, we've seen other technologies come before MongoDB and claim to be the Oracle killer. You saw object-oriented databases and XML databases, ultimately they all failed. The reason they failed is just they didn't have developer mind share. They just didn't have the incremental value for people to go learn this new technology. They just never got the traction with the developer community. That is not the case with MongoDB. The anecdote I gave about India, I'll give you another anecdote. We have an intern program. We hire roughly about 80 people, interns around the world, here in New York and Dublin, we actually started a program in Sydney in their summer, which is our winter months. We had close to 20,000 students apply for that intern program.
The admit rate for our intern program beats any selective college or university in the world, that speaks to how popular MongoDB has become. If you go to any major university and ask them in their computer science programs, what do they cover? MongoDB is invariably a technology that's covered in those programs, especially when they start talking about database architectures. When then you see other facts, like the size of our ecosystem, you look at DB-Engines ranking, us and PostgreSQL are the 2 fastest growing databases across the landscape. You look at the activity on Stack Overflow. There's just so much data out there, obviously you have your own contacts and relationships. You can validate all this.
One of the big things, one of the real assets about MongoDB is that developers love MongoDB, our business starts and stops with the developer community, which Eliot always reminds me once in a while. That is something that we take very seriously. You'll see us making more investments and engaging more of the developer community. While we have great mind share, we think we can do far better, especially around just driving awareness of even Atlas. A lot of people know MongoDB, don't even know that we have a managed offering because not everyone attends these kind of conferences. We're putting a lot more effort and work around just broadening the awareness around all our capabilities and offerings that we have.
On the Data Lake question. I think the short answer is no. The question really is, hey, if you have Data Lake, are people going to put data in the Data Lake rather than in Atlas? I think the kinds of data people are going to use for Data Lakes are something they would never consider in Atlas because it's frankly just way too expensive, it's something they already have on S3, right? They're basically trying to move it from, maybe it's moving it from some other Data Lake thing or maybe a Hadoop thing, they're trying to figure out what to do with it. They're all right now just putting it on S3 and jumping through a lot of hoops to query it.
We're going to take something they're already storing in S3, already trying to use on S3, and just make that a lot easier.
I think the way you should think about it is online and offline data, right? Your production database is your online data, and data stored in S3 is your offline data that now you can query very easily with the same syntax and nomenclature as you do with your online data.
Thanks very much. Michael Turits from Raymond James. I think definitely two of the most interesting announcements were certainly Search and Data Lake. Does that bring you into a different realm of competition? Who do you see in each of those areas now that you might not have seen before?
I would say, I want to be very clear. We didn't come at this by saying that we want to go after Elastic's business or we see an opportunity because the Hadoop market is cratering. We're really being responsive to customer needs. If you remember our whole keynote, the theme was we give developers and customers the best way to work with data. Just the definition of data is now expanding. It's not just your production data, it's also your offline data. There's certain capabilities that we wanted in the database, which we didn't have. Now it's Full-Text Search. When I joined the company five years ago, we were talking about adding Full-Text Search, the priority at that time kept getting lower to address a lot of other things like ACID and some other features.
This is just broadening of the core platform as well as enabling developers to find it just really easy to work with data. That's the central tenet in our ethos in terms of how we think about the market.
I'll stick with the competitive line, and ask about cloud-native. You began to talk about it, Dev, before, where you're winning, but can you just be a little bit more specific about where you win and if you don't win against the cloud-native solutions, when that happens?
I would say that there's two phenomenon that we see. One is something we can't do much about, and those are deals that are happening without us being involved, right? This is a big market. A lot of people are moving workloads to the cloud, and if we're not involved-Or they don't know much about MongoDB. They're probably doing the classic lift and shift, taking maybe their Oracle workload and moving to some sort of open source relational database and running it in the cloud. The second phenomenon is a derivative of that. It's a lift and shift, and they're just so focused on cost because they just had a very painful negotiation with Oracle or another incumbent, and they're looking at expediency as the, quote unquote, decision, and basically just want to get off.
To them, in their mind, this is much easier to go to a relational database than to re-platform on MongoDB. I think we're giving customers more and more reasons. I think you heard a lot of customers on the panel. More and more reasons to think about MongoDB first. Moreover, what customers are realizing, if they just do a lift and shift, they don't really get the full benefits of a hyperscale cloud platform. That's where MongoDB really. Like, for example, we have a feature called Global Clusters. A relational database cannot do this. That feature has two benefits. One allows customers to easily address GDPR requirements where you can tag data and create rules around where certain data needs to stay in certain geographies for privacy and other regulatory requirements.
For example, in Germany, if you're capturing PII data, you have to store that information in Germany. With Global Clusters, that's a very easy thing for a developer to do. If they don't use MongoDB, they have to build that functionality into the application tier. It adds a lot more cost and complexity for that developer. That's an example where as people start thinking about the power of MongoDB and you leverage the full benefits of the cloud, we're starting to see. That's where the SIs are coming in and saying, "We can really help customers rethink and reimagine these applications and leverage the benefits of both the cloud and MongoDB.
Thanks. Aaron Husik from Ashlar. Can you touch on what you expect to be the common use cases for search at your customers, where they're using Elastic today? They can swap it out?
The simplest way to think about it is for a lot of the data people are storing in Mongo, it's transactional data for applications. Product catalogs, content management systems, CRM kind of data. For that data, most people want some sort of search. Right now, they really have to sort of take that data out of Mongo, put it somewhere else to store it in both places for search to work. It's those sort of like, any website based on MongoDB probably has a search box. That search box is probably not using MongoDB Search today. Those are the main sort of use cases. It's not going after sort of the logging space or those sorts of things. It's really about the transactional search where I've got online data, a website, something like that.
Could be internal, could be an internal app, could be an external app. That doesn't matter so much.
We probably have time for one or two more questions. Go ahead.
Hi. Karan Arkatam from East Grove. I'm just trying to get a better sense of the monetization uplift potential you could get from Atlas. If you think about the workloads today that you don't monetize, if all those workloads instead move to Atlas, how much bigger would Atlas be? Are we talking about 10 times, 50 times, 100 times?
I would say there's some debate internally, it definitely starts at 10 and goes higher. We think.
As Dev said, MongoDB is really popular.
Yeah, we like the stock, in case you couldn't tell.
Any other questions? One up in the front. Actually, just for the stream cast thing.
Hi. Nehal Chopra from Ratan. You guys talked about, Dev, you mentioned that with Search, we're going to make more money because we're automatic. How much more is it? Can you help us with that a little bit?
It's a little hard to estimate, but I think the simplest way to think about it is if for any given cluster, if you turn Search on for all the documents, it's roughly going to increase that cluster's needs by about 2x. If you're spending $1,000 a month and you want to Search all the data in that cluster, it's probably going to cost you $2,000 a month. It really comes down to what % of people want Search and on what % of their data.
What is it?
I think too early to tell, given we just launched it.
Any final questions? One last one. Itay. We'll have to talk quickly.
You're the most wanted database, but you're not the most loved database according to the same survey. What is it from your discussions with your developers that they still don't love about MongoDB?
I would say that's a distinction, I think, without a difference. I think people, where there's movement of workloads, I think it's pretty clear, like, when you look at the modern databases available today, I don't think by any objective measure anyone can argue that we are not the most popular modern database in the world. I think we feel really good about our ecosystem.
If you just walk around the show floor and talk to customers, it's almost a movement upstairs in terms of people's whose passion and enthusiasm for MongoDB, that creates a nice viral effect because as you heard from some of the customers in the last panel, as they start using us for certain workloads, Every customer I talk to says their developer says, "No, I want to work on Mongo." That speaks to also why there's so much developer enthusiasm in the next generation of developers coming out of school because they're used to working on more modern technologies, modern programming languages, modern frameworks, microservices architecture. The last thing they want to do is go back to an old relational database and have to decompose that data into data sitting in different tables. I think the puck is moving in our direction.
Okay. We are out of time. Thank you all for coming. I appreciate your time and questions and attention during the program today. I'm sure we'll see you back out on the road. Thank you.