All right. 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. And 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, right? 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 are 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 and A as well, and we'll look forward to getting into it. So 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.
And there's probably a safe harbor thing. Oh, no. Well, let's just assume there's a safe harbor thing that shows up there. You're all familiar with it. You've seen it.
It still applies.
And so with that, I'm going
to turn it over for our first customer story for Gary Hoepperman, Founder and CEO of Uncork, to talk to us about what Uncork does and how data fits into that. Thank you for coming, Gary.
Thank you, Michael.
Okay.
So Gary Holgram, CEO and Founder for Uncork. 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 5th grade, punch card machine, my dad's business, and it was just amazing the art of the possible of what application software can do and 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. And 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. And before jumping in 2012, I actually introduced Citi to MongoDB, and it became one of their solutions there. When I entered Netlife in 2012 as their global CIO with 10,000 developers across 47 countries, actually had MongoDB onboarded before I joined in my garden during my 3 months garden, figuring it would take that long, and it did.
But the goal was to actually deliver value. And even in MetLife, I got to actually use products like Mongo to deliver real value in something called the MetLife Wall, which was featured in Fortune and Forbes and Financial Times. And then the last years in MetLife, we used MongoDB the first time in Japan to displace 1 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. So this was MetLife's Analyst Day in front of 100 or 1000 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. So 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, let me give you the briefest history I could. So there's 3 generations of software built 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 is going to be great. But guess what business, we need to do this first. We need to sit down and plan it.
We need to have the architecture drawings, the diagrams, how where do you want the window, where should the kitchen cabinets be. And then you know what, that's great, you signed off on all that, let's begin construction. And for the next 3 years, we're going to build this. Those walls, the 2 by 4s is code, basically software programming code. And then at the end of that, the business walks through and we're excited.
We're like, here, 3 years later, 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. And we go back and we say, but look what you signed up on. You gave us those requirements. You signed off on the spec. And suddenly, distrust between 2 groups emerges.
It's happening every day in every company no matter what industry you're in today. So along about 10 years ago, 15 years ago, software comes in and no software comes in. And the software package has promised 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 and you're done. And this is the application level above database.
And 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 3rd 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 and
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. And we, IT, say, look at the backlog, it's all there. Don't worry, it's coming later. And it never comes.
So, introducing to a little bit as to how the generations happen and what we actually do to get here. And what we say in Encore is there's a better way. We're calling ourselves that 4th dimension, the 4th 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.
So specifically, what is Encore? 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. So how do we do that? We look at this and we say the biggest clients you could imagine, the biggest names and these are 9 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 thing is we sit down and we basically say, look guys, 90% of what you're doing in your company today with those tens of 1,000,000,000 of dollars of technology costs is commodity.
It's actually not valuable add. So let us actually show you how to do it a different way. And 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 below all.
So 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. So for us, businesses span from everything from life insurance to annuities to groups to individual to P and C to commercial specialty to banks to capital markets, to wealth and asset. And our newest industry we announced 2 weeks ago is public sector, public enterprise and real estate specifically.
And so 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 is an interesting story. So when you think about cloud, about 7 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 is a competitive advantage is infrastructure. And unless you're actually nanoseconds away from the trading floor and actually need that as an advantage, you don't and you're confused. So cloud comes along and says we could do it better. We could take over your infrastructure, your security, trust size, and they do and they're proving it as you know inside out. SQL comes along.
SQL has been around a while. Since I've been coding, SQL has been there. And SQL says, let's think of things as entities and tables and relationships and joins. And if you want to modify a table, it's pretty painful once it's out. And when SQL comes along, it actually is trying to define models and data in a different way.
And what we see with MongoDB and NoSQL is there's a different way to do it as well. And with AtlasDB, 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, my 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. So we don't have a DBA in my entire company.
So 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 5th employee before any engineers. So 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. Because 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 Encore. Trust us. And we're 3 people. So you can imagine, what that takes in those conversations. Of course, from the 7 architects all looking at you with their arms crossed like this.
And we get through every conversation. We haven't failed a single audit. So specifically, security is top of mind. Security is something which we need. We don't know if a customer in Oncork is defining a date of birth or an effective date.
One's privacy, one's not. So we assume they're both PII. We assume they're 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 on Quark was when I kicked myself out of my office. So the one thing we tell our customers is number 1, we host you in whatever cloud provider you choose, except on prem is not an option. So 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 the 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. So we tackle the problem as single tenant top to bottom.
Your database is your database. Every single thing is yours. Internally in Encore, we built using Atlas and other tools, orchestration to one click, provision and upgrade everyone with 1 shot, which means 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. So 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 is going to move from Ohio into Brazil. It took us 5 minutes using Atlas and we moved the data. And their entire application without ever resetting or going down was moved. They then called up 1 minute later and said, move it back.
We made a mistake. We can't have it in Brazil, and we switched it back. And that's the reality of life. Now in reality, in an enterprise, that one scenario I just gave you would have been weeks weeks of planning and work and then rollback would have been painful and costly. So scalable.
We had one bank, the 7 architects sitting there looking at us like we're crazy. You're going to take over our software and our application developers and what will the 10,000 developers do back there? And they basically said their final point they were trying to get to to say no was scalability. You can't handle our volume of our customers and our transactions. So we were able to actually stand up in an environment with 10,000,000 accounts and each account with multiple products and each product multiple transactions, enormous Mongo instance overnight.
And we're able to show them 200 millisecond response time end user last mile, but 27 millisecond response time internal with a 1000000 transactions a minute, faster than any system they've ever seen, faster than any system in their bank, it's more secure. So 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, you can't find another software company that even covers in P and C Insurance, individual and commercial and specialty, just P&C Insurance.
So our platform enables us to handle every product line, every product type, every front office or back office. It's because we're using JSON infrastructure, which is the internal storage here. So what does UnQuark do? So above the 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. So that's where Encore comes in. And Encore again is using cloud, it's using MongoDB.
And specifically, it's a new way to build software. It is the 4th generation of build as we call it today. So 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. I appreciate that. Next up, I think we have Richard. That's correct.
Okay, great. I'm introducing the right guy. So some of you may have met Richard. Richard is our SVP of Field Engineering. So that's basically everything that sort of touches from sort of a customer perspective in terms of presales, post sale and customer success, also reports as well as professional services.
So Richard has been here for many, many years and is a great intersection of where the technology actually meets real life with the customers. And so 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 that helped from the MongoDB side that helped Gary get his initial project going back in 2012, twenty 13 timeframe at Netlife. 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.
So, 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. 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. So as they say, as Yogi Berra once said, predictions are hard, especially about the future. So please understand that everything we say about what's coming is best effort and you make your own judgments as to how to interpret it.
So 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, 1st building the core database product, which has tons of downloads and users and customers and so forth. And 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. And to say that something's an intelligent data platform ultimately means 3 things for our purposes.
1, 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. 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, 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 2 times, 3 times, 4 times faster with MongoDB in terms of delivering applications. And also when they run their applications, those applications also tend to run a lot faster.
So 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, etcetera. 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. And the capabilities that we have here provide for high levels of availability so that 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 and other parts of the application that are mostly analytical, tallying up receipts, computing end of day or end of month type 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. And 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 honed only in Germany, some data to be honed perhaps in Singapore. And 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. And then finally, MongoDB,
our technology platform, is built
in a modern fashion in order to
be able to run anywhere MacBook in front of me or on commodity grade server hardware. 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, Android, tablets and that sort of 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. And so 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. And 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.
And 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. So let's talk about some of today's key announcements. There were a ton of things that Elliot 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 3 different buckets. 1, 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 software 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. So first of all, let's talk a little bit about transactions. Now we can say about MongoDB that always that you run that core server support full ACID transaction. What's an ACID transaction?
Well, this is a term of jargon in the database industry and among database developers. These are 4 attributes that have 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. And in MongoDB's case, we've been working toward this full asset 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 punch line 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. And so we have trading platforms and e commerce platforms aid 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 asset transactions for small deployments of MongoDB to be to use the technical term, this would be a single replicating set in MongoDB. And 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.
And then this morning, we announced full general purpose distributed asset 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 and then commit the transaction at the end. And 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.
So 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. And 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 and then go update a whole bunch of different tables and 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. And by doing so, you get a lot of efficiency because that document is stored in a very efficient manner.
But also you get transactional capabilities because any changes you make on a single document have always since the dawn of MongoDB time in 2,007 has always been a single document level transaction. So if you leverage MongoDB's document capabilities appropriately, you don't actually need all of this general purpose asset transaction stuff that we've been working toward. But
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. So 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. And a transaction over such an application would entail changing 2 different records in 2 different places. One of them being representation of my order, including some pickled onions and another one representing the inventory of pickled onions in the warehouse somewhere. And in order to process such a business transaction, we need to change both of those documents and we ought to change both of them or neither of them. And so 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 and either both of those changes happen or neither of those changes happen.
Now this is a very basic capability that a lot of other databases have had. And 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. And 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?
And the answer now is unequivocally for any size MongoDB deployment, yes. Okay. That was probably our biggest, most exciting sort of developer focused capability in the core database. But let's talk about some other things. Over the years, of course, we have been growing increasingly our business has been growing increasingly deeply involved in our customers' most important applications.
And 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 and also because many of our customers exist in regulated environments or environments where they have compliance and details that they have to agree with. And so we've been working on a number of different capabilities, which 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. And these can be thought of in terms of 3 categories encryption, the platform over the last year, which give very fine grained rules for modern applications 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. But the database level access control rules are
typically used by back
end developers and are but 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. So there are multiple layers of access control capabilities in MongoDB, which are highly powerful and are part of sort of any real world deployment of MongoDB, at least of anybody who's following recommended best practices. And so this is an area where we've got the security capabilities that all real applications need. And it does require a little bit of right. But it's a capability that is clearly very important to all of our customers and something that we continue to enhance.
So 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. So 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. And of course, you can buy hardware that can encrypt data sort in the hardware.
So if somebody steals your encrypted hard drive, well, they're not going to be able to use it. And 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. But 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. So an application might, for example, be my user profile on some website or some 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, etcetera, does not need to be encrypted. And so that stuff is stored just verbatim inside the database.
But the key thing to understand about all of this is that encryption is happening inside the application, not inside the database. And 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. So 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 personal identifying information and so forth that has been secured at the application tier. So 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. And so 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 your use whatever that user does in your business in that system, it can be forgotten simply by throwing away that user's encryption key.
And this is a 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 27,001 is the most recent. We're working toward PCI, which will then 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 3 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. Now as I said, at MongoDB, we want to make data stunningly easy to work with.
And 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. And so for example, as you know, we acquired the Realm company about 6 or so weeks ago. This 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.
But 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 back end database purposes and they wanted to bring that ease of use for data to mobile developers. So 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 the form of Atlas on the back end and eventually in other environments as well by using 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 and 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. And then 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. And customers have asked, 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? And that's directionally kind of thing that we're thinking about. And then, of course, we also announced this capability in Atlas, which is full text search. And as Elliot mentioned, for those who listened in on the keynote, one of the things that's been the case up till 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. So by
the 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 be 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 in built into the query language. And so 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. And so 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. But then they even have more data that is valuable for them to keep around or maybe they have to keep it around for regulatory reasons.
But it's not super valuable for it to be online all the time and accessible in that fast way all the time. But 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. And so with the Atlas Data Lake, we can take those customers who have large volumes of data in something like S3 in the cloud, so an easy way to store large volumes of data and allow people to interact with it directly as if it were MongoDB.
So any existing MongoDB application that people might write for their sort of highly valuable, maybe as 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. And 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 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 is stored, whether it's in an online operational database or a sort of more passive object store like an S3. And so as I said, these are some of the capabilities and features and products 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, S3, etcetera, 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 Zahir is coming up next. Zahir runs our cloud business. And I'll turn it over to you, Zahir.
Cool.
Thank you, Michael.
Good afternoon, everyone. My name is Sahira Azam. As Michael mentioned, I run
the cloud business and product strategy for MongoDB. I joined the company about 3 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. So obviously you know these numbers, this is a 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 or even in the public cloud today. So as much as we hear about the 1,000,000,000 of dollars and the tremendous growth of a lot of cloud platforms, we think we're definitely very much in the early innings. But I want to give you a little bit of context around this. We've been at building this platform for many years. So 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.
So 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. And what it did is helped customers manage their Mongo environment by quickly spinning up a cloud service, getting metrics and data about the performance of that environment. We then 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 want to send us the data and secure it in the cloud.
The 3rd piece we added a couple of years later was automation. We have now seen quite a bit of adoption in Mongo worldwide, especially in the enterprise. Customers were asking for easy ways to upgrade their database safely to rolling patches and updates whether be security or new functionality that they wanted to push out. And really what we were embarking on was a dual track strategy. On one hand, we wanted to shift these technologies both as cloud and as software to help our enterprise customers manage their MongoDB environments.
That was track 1. And that obviously has helped our first phase of monetization, 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. So behind the scenes of Atlas, a lot of the core monitoring capabilities, backup capabilities, automation that I talked about, powers our delivery to the 1,000 customers that run on the platform. And 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.
And that doesn't count capabilities that were built outside the Atlas
team by our core engineering
team, things like So I want to walk So 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. And then 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. And that hits not only the customer experience, but also the product experience. We can build more products faster as you're seeing with the number of announcements we've made in the last 2 years now that we're embarking on a cloud first delivery model. So to take a step back, at a very, 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 definitely want to go definitely want to go through some form of rigorous testing functionality, check for bugs, performance, whatever it might be, integration testing. And then of course the application goes into production. Now, no question, Mongo is used across this entire lifecycle. 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.
But if you look at us as
a business, the majority of our revenue comes from a product called Enterprise Advanced. And historically, the value it provides is really aimed at mission critical production workloads at the end of that lifecycle. 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. And that's largely where the value of our monetized proprietary solutions fit. But with Atlas, this equation changes.
We can now monetize the entire lifecycle. So 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 development that start $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. So although we've always been used as a database across this entire lifecycle, we're frankly now monetizing that entire lifecycle. 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. Now we're really engaged with all the different users of Mongo across the lifecycle. And 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. And 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.
So if we take a step back, 3 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 2,000 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. And certainly this is still an important way for us to drive revenue today, but this was largely the only way we sold in the past. The main buyer, as I hinted on earlier, was really the operations team. So 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. And that's largely who uses our operations manager technology or our cloud manager technology, the sister product in the cloud. And therefore, our marketing organization was largely focused on lead generation, right? 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.
And 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. But the sales motion at the time was largely like trying to find a needle in the haystack because the product market fit for Enterprise Advanced was largely built for Global 2,000 companies. It's called enterprise bands. So finding a small company that has the resources, skill sets and requirements to use that enterprise software was relatively challenging. And 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.
But frankly, it wasn't growing as fast or as successful economically as our enterprise channel. And then the further down the market we went with SMB, we really had like no coverage. I mean, we had some very trickle to nothing of self-service revenue to really drive that reach. It's not a people oriented sale down at that level. So what do we have today?
With the add down of Atlas, we really diversified our done of Atlas, we really diversified our channel strategy quite a bit. Our enterprise channel is obviously still selling a lot of enterprise advance, but also selling large amounts of Atlas. And what's interesting is the message around Atlas is less about risk reduction operations and is more about driving innovation. So it brings us closer to the business buyer. It gets us to that of business executives and the developers that are actually conceptualizing these amazing new products.
And to be able to do that, our marketing organizations also shifted. So 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. And that has had a tremendous effect in allowing us to scale this business.
We have grown the team by over 3 times in the last 3 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. And 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.
So 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 cloud sales team. So 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. But 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, slicing their credit card and getting going on a build in arrears type model using our cloud services. This is entirely new for us. And it's actually been a rapidly growing channel of growth for us because these are customers that we were never monetizing before. And right now we have north of 10,000 customers that are attracting to Atlas coming into that funnel. We've got 1,500,000 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 up sell opportunities to our sales teams, whether it be at the bottom of the triangle and small customers all the way through a large enterprise. And we're already starting to see that behavior. But 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. So we're definitely building up that skill set the 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.
So it's a new discipline for us to really get great at that last piece. And 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. So 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. And this account manager had sent 4 emails that's in 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, and he got no response. So just junk folder, ignore the emails, whatever it might be. But 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. So we sent a much more targeted e mail saying, hey, I noticed cluster XYZ, you just spun it up, it's driven your usage up by X percentage, 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. And 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. So it's just a small example of how sort of data is 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. And what's interesting with Atlas and partners is it's really changed the motion that we attack the market with these big players. And 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 migration,
right?
Everyone 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. So what ends up happening is the first phase of cloud migrations are largely taking your legacy application stack and your legacy people and processes that specialize 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. But what those companies that jumped head first in the lift and shift strategies 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 in a very traditional model like they would on prem. So they're over provisioned. And instead of over provisioning, meaning you've got some empty hardware sitting around that you're capitalizing over 3 years. Now you've actually got a metered bill running all the time. So it actually could be much more expensive.
Thankfully, the industry has gotten a lot smarter. The cloud partners, the SIs, all of us have 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 cloud native architecture. And 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. So 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. And we are in the center of this secular cloud transformation movement that's happening that's led by these partners.
And what's interesting, especially for the SIs, is 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 Dave mentioned, in the keynote in 64 regions across 3 clouds. So 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.
That's a powerful story. Shifting out of kind 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 Encore's environment no matter what customer is on it. That's the way we run Atlas as well. And that's allowed us to have not only data route 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 AB test new features and see which UI works better. We're working on the growth team. We can try different flows on the onboarding experience to see what converts better. So 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. And we have to ship code in Atlas every 3 weeks.
So we're constantly adding new customer value. And 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 like 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 4 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. And you've really seen that. If you looked at Richard's presentation just now or Elliot's keynote this morning, what you're seeing this year is really a culmination of a cloud first development strategy.
So 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 of market fit faster. So 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, but we are basically now at this point a cloud first company in every segment of the organization. Thank you.
Okay. Oh, great. Thank you, Tahira. I think next up, we've got Dave, I think. Yes, here he comes.
And Accenture. Right. Tested on my MC skills, that's fine. Yes, over here is fine. Thank you for coming.
Are you mic'd up or you Yes. All right. Well, Sanjeev, I'll give you mine. Here's Dave. Excellent.
And here's the other one. Okay. Now the partner section, Dave and Sanjeev from Accenture. Take it away.
Thanks for making the time. Hopefully, the session has been
answered. I wanted to introduce Sachibura from Accenture. And maybe first and foremost, maybe just give
a quick
primer on your background as well.
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 be part of it in these events. So my role, I have a couple of roles and one is my primary role, which is I'm a CTO for our technology business, X Ninja Technology.
And in that role, I do 3 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 our 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. And they need to be relevant for that, right? So that's so I ensure that we are making right investments into that talent development and ensuring them they stay relevant in the future.
The second is I look at very specifically on couple of things. One is a special offering that we have called as 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 and the second is data. So I spend a lot of like most of the time on data. It's a passionate topic for me and I love data. And the last but not the least, I work on very special V and A strategy for our firm.
So those three things I'm doing, I'm a global lead for data business as well.
V and A? Yes.
Could you Acquisitions
and Ventures. Okay. I got it.
So talk
to us about the data business. You mentioned that you're reenergizing data business with Accenture. What does that really mean? And maybe in layman terms, you can explain to this audience.
Yes. I think What is Accenture's focus on this? Absolutely. I think we have been I think all of us have been listening about the data being the new oil and the new currency, right, over the last 2 years. And the attention towards data has really increased over the last 18 months or 2 years.
It has become a suite topic, which was not the case earlier. And the way I explain is that we all were we all are aware of data and been working in data for last many, many decades. But guess what, all the businesses were kind of dealing with data earlier, but I think now they want to lead with data. And that's the difference in the shift that we see over the last few years. And what we see, Dave, 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 or we can create new frankly.
And they are talking about 4 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. But data strategy is kind of hidden in many places. It's not explicit, right? So 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. So 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 a 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 get to ensure that the data flows at the speed which business needs, right? 3rd point we are seeing, which is probably to me the biggest issue in the it's 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, but you don't see the pain, really pain which people are going through.
The symptoms are like we have built a lake, but nobody is 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. So that's a third problem, quality. And the 4th one, which I think is quite profound that companies have invested in COEs over the last 7, 8 years.
CEOs means standards of excellence. Standards of excellence. Thank you. Analytics Center of Excellence, the Data Center of Excellence, whatever that is. And then they have invested in technologies, all new technologies called machine learning, everything else.
But that's not going to make them data driven company unless they really change the culture of the place. So the businesses are the people who are actually using or consuming data, they need to understand the data itself and see and generate insights. So the whole concept about data democratization or making people use data more efficiently is something which is arising right now. So those are 4 challenges which we see in the market and the idea is to kind of solve those challenges and make them more efficient.
So 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 is the partner of the year for us for the last 2 years in a row. So 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. We are a customer of MongoDB as well. So we are using it for various things. There are multiple use cases we have with MongoDB and our teams are quite happy with MongoDB, like our internal teams who are using it, like we as a client, let's say. And one of the case that I want to really pick up, which is quite profound is that we have a particular platform called as MyVizard.
And that platform is used for all the client delivery that we do, all the solution that we develop for our clients. So 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, right, and solution development and deployment. Within that, we have a lot of artificial intelligence built in.
We have a lot of patterns, AI patterns in there. So we have probably more than 60 patterns there, and they run on MongoDB, right? And the reason why because I asked them question, why MongoDB? And they said, well, this actually helps a lot. This actually helps our AR run more efficiently.
So that was an excellent story. But beyond that, I think we are doing a great work with MongoDB. We have more than 2,000 people right now who are trained, and we have a much bigger plan in the future around this, especially our architects. And we are seeing a huge traction in the market around how people would like to use MongoDB. Got it.
So a lot of
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?
So I think we do as I said earlier, I think there's a whole discussion about re architecting or re platforming. And when it comes to data, I think the clients have a different level of maturity. So we have clients in probably 3 levels of 3 stages of maturity. The clients who are have a lot of investment done in the old technology legacy, let's call it legacy. They want to go in a phased manner to the cloud, right?
And they still have hybrid architecture. So they have a lot of stuff on prem, they have a lot of stuff on or they want to move on cloud gradually. The second is the clients who are actually have taken a decision of moving fast. So they call in our 2nd bucket call modernizing the platform. And 3rd ones are the ones who are actually building totally brand new capabilities and architectures.
So they want to go native on cloud. So we see all those 3 trends coming arising. And I think what we see very specifically on MongoDB, if you ask me what are the and I was having a session with our master architects who are top of the spear, right, the guys who do an initial defined strategy and architecture for the clients the future. And I said how MongoDB is different than any other database. And I think the way I understood in terms of use cases and what we're doing for our clients right now is I think 3 things.
One is I think they are finding MongoDB as just in terms of their database itself, they're finding it more easier for real time analytics and analytics on edge, right? The second thing is they're finding it MongoDB very flexible for needs where data model has to be more dynamic. Like, for example, Customer 360. But if a customer changes fast or the customer attribute changes fast, then MongoDB is a pretty good place to go after. And the third thing is when they are trying to see the integration with Hadoop's and with cloud.
So they are finding MongoDB much more positioned for cloud adoption. So those three things came out very clearly.
Got it. When you think about like help the move to the cloud, I think it's maybe the first phase, the second phase or the first category, second category. We saw in the early days a lot of people doing lift and shift. And 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. So how do you help customers think through lift and shift versus a replatform?
I think as I said, I think that also depends on maturity investment the client has in their aspiration. But what we do is we usually go with we'd leave with strategy first. And as I said earlier, the strategy is not only defining the value of the data that they want to untap, but also the road map. 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 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 replatform this.
So the readiness to replatform is actually much better than a year back. And then 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 as we do is we do kind of for the first phase, which takes 8 weeks to 16 weeks depending on the majority of the client, but it's our architecture work initially. And we call it 3 Ds of architecture. The first one is discover, like what do you actually have right now as this is what you have.
Then you define it. You define the end state saying this is the exactly target you want to get to, right? And then you describe it in terms of road map saying that, okay, these are the things you should be doing in the 1st 3 months, 1st 90 days, 1st year, 1st 2nd year and so on and so forth and how do you get there. Now we have multiple examples like that, right? But one thing which one example that I really like was about client of ours, like a joint client of ours in Europe.
And these guys are into energy. They're energy and utility company. And then these guys have more than 64,000,000 customers. They were locked because of their legacy systems. And they wanted to get ready for the future.
And then we proposed architecture, which has MongoDB. And what we got out the returns after that, it's already implemented. We are now scaling it out. And what we what the client actually got out of the entire new solution was to was, the first of all, faster time to development now. So they actually had much faster development time for their IT teams.
They got they were able to ingest data much faster for all incremental data that they wanted to. And the third thing was that they were able to cut down the overall efficiency to the business. So the business at the dealership has really improved because of the new solution and new architectures.
So 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?
So in my role, personally, I'm not an adviser to the client on data privacy. But 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 manage and ensure that the customers being transparent to their customers and ensure that they can protect their data, right? So in that with that regard, what we have done is we have we are using extreme amount of machine power for discovering and fingerprinting and creating visualizations for the data protection officers or whom server is the right person. Like for example, in Europe, there's a GDPR regulation and they have a very defined role called as data protection officer, TPO.
So how do you actually enable a TPO to be more effective and efficient in their role? So that's what we're doing. A use case in there is basically that and our approach is slightly different than the conventional approach. The conventional approach is to look at the law. So in GDPR, there's 90 plus articles.
So look at the law. In CCPA, there are regulation in California. So 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. So very sequential processes, the way you look at it. What we started doing was we said look at different ways, look at reverse way.
So if you're able to discover data figure out the patterns of data, can you use graph technology like graph technologies to visualize it differently? And that's what we are doing. So we're trying to what could be done in 8 months for a client, we could do it in an 8 weeks just by power of machines.
So, 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? When you see 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 there's other companies you work with. How do you how would you in all seriousness, how would you kind of think about and help customers think through like the adoption of a technology like MongoDB? And obviously, there's a lot of legacy applications, infrastructure, people play that business, they're not just going to rip and replace. So can you walk people through a little bit of like how a large enterprise might think about their existing workloads and how they might re platform it over time?
So I think it does require a lot of education upfront. And that's why the initial period of 8 to 12 weeks, 8 to 16 weeks is so important 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, so 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. So 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. And I think that shift has already happened. So what we are seeing is that they are ready to invest time to understand new technology, emerging technologies.
MongoDB for us falls into that category. So we have a partner ecosystem, obviously and 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. And then we have the next generation partners, which we call emerging partners. I think that's where we the more innovative companies and MongoDB falls as it's there.
So I think right now, obviously, a lot of work we do is to just educate clients in terms of when we position new architecture, how is MongoDB important for them in their business and why they should be investing?
So one
of the things we've done a lot of business together, we've done business in North America and Europe and in Asia Pacific. One of the themes emerging over the last few years is the rise of developer. And obviously, there's other public companies like Atlassian and Twilio and even public 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 the decision 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. But 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 we are seeing I think that 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 the company because once you have a top buy in, then you move the funding ask from being discretionary to non discretionary, right? And that's very important. Like if the funding ask is discretionary, it's a small pocket of money. It's also something which can be which can have a flex because of depending on the performance of the company. But when it's not discretionary, you can actually you know that you can't run your company without that particular pot of money, right?
But 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 and the companies where people have enough knowledge about technology. So to your point, I think we are seeing very mature people and our mature clients who actually get into conversation around why this technology, why not this technology. And it goes through a few weeks of exercise in terms of just explaining and understanding why we are picking those up. In many companies, there are very young talent now actually. So I can tell you about one company, very recently where we were working and they had a new CTO who joined from a I can't name the company, but it's a very high-tech media company, right?
And they are very proud of what they have been doing in terms of doing DevOps and releasing a code every day right into production. Now when this guy joins and their systems were working on 6 months of release cycle. They were trying to think about 3 months of release cycle. This guy came in and said, no, I want a one day daily release cycle. Now to have that disruptive mindset, I mean, you have those young people and young generation, I think digital native technology leaders were able to challenge that.
So to your point, yes, developer community is very important. They actually participate in the process of selection as well. So we are seeing that trend.
Great. Are there when you talk to senior level executives, what's top of mind for them like in terms of irrespective of MongoDB or even data like when you go if your teams bring you in to talk to senior level executives, invariably, where does the conversation go today?
I think in my view, there are 3 things which I see which are burning up in the conversation. The first one is, as I said earlier, I think the discussion at the C level about data and the power of data. Now 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. So the person who is
And how many people answer yes to that question?
Very few, right. So we normally find C-two, right, in many companies. And by the way, this is bubbling up topic right now. So it's a very good discussion right now. And something is there somebody in C level who actually owns data?
Again, the person cannot own the data because their business will say, I own the data for my section. But there's somebody who's 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, power of data, that discussion is happening. That's number 1. The second is very, very big discussion about platforming and replatforming. Everybody now wants to have a data plat platform because they know the value of data and 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 of the future.
And the third thing is about talent. And 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 envisage. So there I think there are 3 sets of users in there. The management users in the top or operational leaders, 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 of building their business.
Terrific. Well, I think we're out of time. So thank you very much for that insight. That was It was super helpful. Thank you.
Thank you.
I hope it's useful. Thanks, Linda.
Thank you very much.
All right. We're just going to take a 5 literally only 5 minute break, 1:45 back here and let everyone, as restroom as needed and get the customer panel and everyone mic'd up, and then we will start up in 5 minutes. Thank you.
Hello, hello, hello. Okay.
We're going to get started. Brian, if you could help us score people back in from the outside, try and keep us on time here.
Yes, just yes.
Yes, exactly. There we go.
Fantastic. And maybe we can turn this off.
Do we need this?
Can I turn that off? I can turn that off.
Okay.
Are we I know the door is open. Okay. I will wait till I get the all clear signal. Thank you for being so prompt and coming back. Are we good?
Okay. Door closed, Brian. Thumbs up. Thank you. Okay.
We'll have a few stragglers coming back, but thank you all for doing that. So we wanted to try and take advantage of the fact that we have a bunch customers here presenting at MongoDB World to share some of their stories, talk a little bit what they're doing. So I will attempt to moderate this vocal and opinionated group and we'll talk a little bit about what they're up to and everything else. So 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 and then we'll just have a free form conversation. Manish, why don't you take away first?
And thank you all for being here.
Hi, everyone. Good afternoon. My name is Manish. I work for RBC, that is Royal Bank of Canada, and I'm from Toronto. Yes, yes, thank you.
Thank you. Congratulations. Home of the Champions, and I had to get it in, otherwise my kids won't forgive me. So that's and in RBC, my role is I'm the Director of Digital Engineering or Digital Software Engineering. And what we do is we build applications for our wealth division.
So it'd be mobile application, web application. And yesterday, I had an opportunity to present our digital transformation journey. And what I discovered was that a lot of my kind of partners from other companies, I think they are going through almost similar journey. So it was very interesting to get their feedback. So thank you, Mike, and thank you, Mongo, for that and inviting me here.
Thank you.
Hi. My name is Prem Timsina. I'm from Mount Sinai Health System. And as you know, Mount Sinai is one of the largest health system in New York City, and my role is a lead data science engineer. We develop operational machine learning software for the hospital, and currently, we have deployed multiple machine learning software or multiple machine learning use cases across the 4 or 5 hospital in New York City.
And the role of MongoDB is we're using the Mongo we have created the data lake using the MongoDB for our machine learning platform.
I'm Kieran Cloullo. I'm all
the way from Sydney, so
I think I've come furthest with everyone on the panel. Yes. And an award for that. And yes, I'm the Director of Data Engineering at a company called IAG, which is Insurance Australia Group. We have about 23 brands in that and we're the largest general insurer in Australia and New Zealand.
So data engineering, as it says on the the tin, is basically all the acquiring of data into data lakes and real time acquisition and streaming, all those sort of good things. And we've been here to with my compadre, Simon Aubrey, we've been here to talk about single view of everything, which was an approach that we talked using MongoDB and Kafka and Kubernetes to acquire information and resolve it. So we get a coherent view of our customers' assets and who they are, so we can make their world a safer place.
Great. Thank you. Gary? Yes.
My name is Gary Russo. I work at TD Ameritrade. I've been I call myself a NoSQL architect and developer. I've been at TD Ameritrade for about 3 years. I've been following this space intensely for the past 11 years probably.
I used to work for 1 of Mongo's competitors. I remember my boss time left and joined Mongo, became CEO for a short time, a guy named Max Sharrison. Anyway, my purpose for joining Team Ameritrade before Team 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.
But 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 SQL solutions.
Great. So maybe if
we could talk a little bit about some of the challenges you were facing and what you turn to in terms of new technologies, obviously, ultimately, at least in some of these
cases, it's MongoDB. But like 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? Please take turns or just I'll chime in here.
Okay. So as almost everybody who is wanting any company today cannot survive without digital solutions. So we, on the wealth side, started our journey about 3 years ago. And we had 3 team of 3 or 4 people. Now today, we have a team of 40 people, and we are building mobile web applications for our users.
So there are multiple challenges. I think the gentleman earlier from Accenture talked about challenge with data. So 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. So talent is 1 you're talking about challenge, challenge is talent.
And we want creating a culture within a big corporation, which is similar to start up. 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. And this guy shows up with half sleeve shirt, armful of tattoos and very impressive young man. And so I asked him why do you want to join RBC?
And I thought he would answer like, oh, I want to help RBC become the even better than number 1. But what he said was interesting. He said, I want to work downtown. And the reason I so I said, why do you want to work downtown? And he said, downtown, I can catch better Pokemon.
I don't know whether you guys remember the Poke Mon game. So that's the kind of talent we are hiring. And when you are hiring talent like this, I should just call them kids, and they are fantastic, don't get me wrong. I mean, they bring so much energy, enthusiasm and the hunger to do something, to achieve something, to build something. And they are not competing we think about TD or others.
They are thinking about competing with Google and Facebook and we have to kind of calm them down. This is big company here. But that means that we have to empower them with the tools that they want, not that gentleman talked about top down or bottom up. So 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. So how do we open up and create a safe space where these kind of developers can build.
And MongoDB is like one of the tools that we centered on.
The focus of our main team is to build the operational machine learning software. So we are building the machine learning platform for the Mount Sinai And around the data storage and the database, we identified the 2 main challenges. One is the single view. When we input the data before the machine learning model, we need to combine all passing information, then only we can input into the machine learning software. So we found the MongoDB has a good mechanism to create a single view and storage of the single view.
And another good thing was we are getting the data from the 8th hospital in the New York City and each hospital has dozens of database. And is the data from our
the textual data, some are imaging
data and some are structured data. So we do not have control of schema from all those dozens of databases from those 8 hospitals. So we are also looking for the database who has a very flexible schema. So those two things were main decision maker for choosing for us to choose the MongoDB.
And 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? Like why is that such use case? If you're trying to build that out, why is that so hard in other databases?
So I don't want to pinpoint on any specific database because I don't want to uninterest anything. But while we are doing the POC for the machine learning platform, we did review of the major SQL databases and major No SQL databases also. And we finally thought that, okay, MongoDB is optimum for our use case for creating a single view.
And Karen, you guys did some single view work as well, didn't you? Yes, that's right.
That's what we've been presenting. Yes.
So why don't you talk
a little bit about some of the challenges and just for a less technical audience, like 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? Yes.
If you think about the commercial context and history of IAG, IAG is a very large organization and it's quite, I would say, dominant but successful in the market. And like many insurance companies, they tend to typically grow by acquisition. So you go and buy little ones. And 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 being protected and what properties they might be living in. So it was historically very easy for us, say, for NRMA, which is our largest brand.
We could say how many customers on a given day we have and how many customers we might be gaining, hopefully. And but if I wanted to look at that from the entire picture of IAG, that's a very different challenge and that would be often it could take days to work out and resolve all the different the data sets that are involved. And then as that commercial context has changed and the vast every industry has got this where things are speeding up and it's no longer sufficient to run an overnight ETL and bake a cake 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 and so that we can serve our customers much more effectively. So that's essentially what was driving it.
And one of the 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 MoCo working together. That's very important just to point that out. And that really worked for our context. So
that's kind of the driver.
Roughly how long did that take? And was that the first thing you tried? Or were there other things you tried? Or like how did you try and solve that problem internally for that sort of visibility and intelligence?
Yes. I mean the single view of I think the first time I saw reference to when I started at IG2 years ago, I did some background research and that project has been kicking around for a decade internally. There's been many attempts at it with varying levels of success. And once we kind of crack 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've got a lot of importance from the executive team, so it was good.
Great. And I think when we talked beforehand, you were saying originally MongoDB is not the first thing you tried, but eventually as you kind of canvas the landscape, that was the one that kind of greased the skids and made it all possible?
Yes, yes.
I mean, there are many obviously out there, but it was really more of that serving layer of the data. And 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 what the very complicated data structures that were involved. But with the documents, so we could take information that's very rich, say, from NRMA, which might have 150 attributes about an individual customer and match that with another data element that might have 6. And we didn't have to 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 sort of the challenges that you all face at TD Ameritrade and sort of what technology is considered and how you've sort of gone about that landscape?
Sure. Yes. TD Ameritrade, we're So when I joined, my sales pitch has been I specialize in breaking down the silos. So we have, like most shops, hundreds of databases. And it's really difficult to join across all these databases.
So I've been preaching this for years now. The ideal way and within this post relational database area now, there's no doubt about it. I don't mean to offend any of the relational folks. I remember Dwight Merriman used to attend these Mongo World meetups years ago and he used to talk about how 15% of our data will always be relational, 85% will be non relation. I think it's going to be more like 95% non relational, 5% relation.
But yes, challenge at TD Ameritrade was that it was it's buried in rows and columns, buried in rows and columns in these cryptic databases with cryptic field names and makes things really difficult. Productivity is terrible. You can have high project failure rate because you can't really aggregate what you want to pick up another database and try to merge. Anyway, the ideal approach is a JSON document data store. Do you normalize it?
And so we built this thing. I first joined, I made a commitment to help design this thing. We could have consistent sub second search and query capability against terabyte sized databases guaranteed. And 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. But yes, my message is don't shred your data in frozen comps anymore. Of course, maybe 5% of your data is always going to be relational. Let's slowly start to move that into embrace search, I mean, 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 to 1, I call it, 1 Mongo Data Hub, you're going to see tremendous return on investment.
Great. So we talk a lot about innovation and obviously a lot of you spend time thinking about that. Can you just put into context like what's the role of the database in that when you think about overall innovating applications and sort of 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 went recently went public. And I in my career, I worked for a database company called Sybase, and they used to rule the Wall Street once upon a time. And somebody said that it is coincidence that Sybase went public 26 years ago and MongoDB is the 1st 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 mean, I'm sure people have increased features and etcetera, but in terms of disruptive change, hasn't happened. And the document data model brings that disruptive change. And 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 2 things, time to market, which is speed of development and the other thing for digital transformation, most important thing is the user or the client. What is the client experience? And if your stuff is slow, client doesn't want to use it.
3 seconds seems too slow now. I don't know whether you have kids, but if anything takes 2 seconds, 3 seconds and they're like, oh, it's so slow, dad, right? And the same thing happens to the client because on mobile application, our clients are measuring us against not our competitors, but Google and Instagram. So in a lot of in any company like ours, right, we have so many systems and applications which have evolved over time. They're so disparate, then some applications cannot serve your data fast enough.
So for us, the innovation was that we have the whole alphabet slew of technologies that we have implemented. You name Bertie said Kafka, you got Angular, we have Node. Js, we got everything. Now what do we do about data? Data being the key part of innovation and as I said, there hasn't.
So we thought document centric data models does 2 things. 1 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 have 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. Now, I'll give you one example, we are as we learn more about Mongo, we are expanding the use cases. So we started out as a you said about OneView.
So we have a OneView for client or our advisors across so many applications. So they don't need to go to 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 and that we serve.
Now we are expanding the use case. So one of the use case is to take one of our application off of the SQL Server. But what was amazing was that we designed microservices and Mongo data model at the same time. And amount of time we save, so for the time to market, is amazing. So I think the whole concept of this document data model, and by the way, today's keynote speech was amazing.
You mentioned about search, we use Elasticsearch and it would be great if you had one place where we could do both. So I think innovation is happening and Mongo is doing it at the data level. So I'm very glad. Thank you.
For us, the real helpful was no documented, no SQL storage. For example, when you get the raw data, you don't have control of what data you get and what column you get. And if you are storing in the SQL database, you need to transform and select only the specific column and store it over there. But in 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 all the data. So you can just pull from the raw data.
And another important was the single view. For example, now we don't need to join in the real time 7 or 20 or 30 table together to create a complete picture of the patients or clients. So in our team or in our MongoDB database, we always have a current single view of the patents all the time. So those 2 will be really important. And for us, another one was the change stream also.
So most of our, for example, use case works out of the changes stream. So when you get the raw data, we directly store into the MongoDB And from the MongoDB, we get through the changes stream, we get the database update, then it goes to the Kafka and from the Kafka, we have tons of the ETL and the machine learning engines running.
And Prem, can you talk a little bit because we use terms like single view of a customer or people talk about artificial intelligence, machine learning and these sort of buzzwords. But 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. So can you talk about that a little bit?
Yes. So I can talk about the one use case, which is going to be in a clinical trial from today. So, is nurses or doctor input any passing information to the electronic health record, above the blood pressure. They input into the electronic health record and through the streaming pipeline, it come into our data science platform. And we predict that what is the chance that patients will go to the ICU or operating room in the next 6 hours.
And we make up we generate the probability scores and top 10 figures. And if the probability score is very high, we send the alert into the iPhone applications. And the plan is clinicians or the nurses do some kind of the intervention and we've driven the patients from going to the ICU or the operating room. So that is one real time use case. And another use case, which was very successful for our team and for the hospital was malnutrition predictive engines.
So it is quite different than the common malnutrition what we understand. So it is inpatient malnutrition. So patients make generic get the malnutrition because their body cannot digest the food and so the interventions will not work. So every day, we predict that what is the chance that patients is generating the malnutrition. And we create a probability scores and write it to the electronic health record and when the registered ITCN start their shift, they do the descending order based on the probability scores and start to look at the look the patients, they have the highest probability.
And we started with the Mount Sinai Hospital. Now it is deployed into the other three hospitals. So currently, it is running in the four hospitals and it was very used process for us.
Waseem, 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 realized things affecting human lives in that way, it's really remarkable. Kieran, do you want to talk a little about innovation and sort of the bottlenecks or enablers that are created in the database layer?
Yes. I think I'd echo quite a lot of what was just said because I think it's exactly relevant to what we do as well. Just the speed to market of getting speed wins, kind of I used to wear TripAdvisor and Stephen calls for that, so I've lifted it from him. It's really important for us to move quickly because the business is accelerating. And 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. So and particularly in this space, which is about customers, which is very important to us, really need to move quicker. So this allows us to do that. That's essentially the driver for us.
And Gary anything you want to add on the front?
Yes, I would say it's about agility. So we've been application developed, we've been using agile development techniques for across decades. Finally, we could do this with database, right, using this dot net data store. We could be agile with our database development agnostic. And develop that we need a strong developer culture, I like what you said there.
At TD Ameritrade, we do have that we have our camps. We always have healthy debates about what database to use. So it's always a healthy discussion. Democratic process, I always try to come to the table with some hard evidence to show that we evaluate how we can be
more productive. And 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. So when we talk about the difficulty, what's so complicated about a relational database or why is it is it create that sort of overhead of that taxi you're describing that sort of impede the speed and impede the innovation? If you can try and sort of put some of that real life technical complexity in plain English, maybe that will help folks a little bit. So anyone, yes, sure. I'll have a crack
at it. So essentially, yes, what you're trying to do in a relational database is take all the information, tell you 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. And so 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 and then you need to have a partner table to say, okay, there's a join between Kieran and Katy. And this starts to as it grows become more and more complicated and those relationships become harder and harder to model.
And to your point, Gary, it's inherently anti agile. It's a very wonderful 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. So you can't 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. So again, that's essentially the drive.
Hopefully that helps a little bit. I don't know if anyone wants to add anything.
I mean, if you these days, I think most of the people are technology savvy. But if I go down to the physical example of what's relational versus what's document centric is think about a you were asked to store some documents. So you pick up folders and you put customers like somebody said about, say, invoices, customers 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 their invoices, all the stuff they have bought in another folder, that's relational. And then you want to find the invoice for Mike, first you go to Mike, 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.
So 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 relational side reporting and such. But what has happened is companies like Mongo have taken the document centric, which is much easier to understand and manage, but there are some use cases, some things you want to do, they have solved with back end technology. So instead of saying, okay, I can't solve reporting, therefore, I'm separating everything. Now you 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. So you need to know the customer, the you, then you're going to click on the invoice that is right there. So 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. And obviously, some of you are public companies and it's hard to share different information, everything. But like 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 sort of 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?
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 projects going on.
There was a data lake project. They were looking at using Azure to host it. My application, I've been working on it for institutional investors. It requires a lot of high disk IO. So we have a weekend, we have the 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 I 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.
And so it's really cost prohibitive right now. I think it's much cheaper for us to stay on prem. I think we'll be on the institutional products that I work on are probably on prem for the next 10 years honestly. But slowly, we're going to be moving towards the cloud. I'd love to use Alice at some point, but eventually.
I was just telling Dave that I think the Atlas product that you guys have created, it's 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 1 basket. You also usually have on prem, right? So the great thing about Mongo 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. So 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. But we are going through the IT security and maybe probably next year or in next 2 year, we'll be starting to use the cloud, but we are interested to use the cloud. So it will just be like getting through the IT security takes a lot of time.
Yes. We're regulated in Australia by APRA, which is the financial services regulator in Australia. And But really the challenge for us has really been more of an internal one at IAG. APRA is pretty fine with what you can do, something you can do it safely and convince them that you can. But I think just there's a mindset change that has to happen about cloud adoption, I think internally in an organization and 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. And we already have with our single view of the customer, workload is already in Amazon. And that was the first time that we got that certification mapper to put customer data or PII data, as we call it, into the cloud. And so 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, but this is great. Gary, Karen, Manish, Prem, thank you all for coming and for sharing
your thoughts. I really appreciate it.
And then we'll get Elliot and Dave up here, and we'll do the executive Q and A. So, Homestretch, so this is really the open format portion of the program, where we've got Dave and Elliot, and we can take questions and we'll dive right into it. So Itay. We'll get you a microphone.
Thanks, and thanks for hosting us for a very interesting day. I wanted to dig in into the search angle that you've added into your technology today and 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 3rd 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?
So
I think the we don't have
a list that we're just going to like, here's the 3 markets we're going to do next. But 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. Tech search is a great example where people are using MongoDB and they're sort of struggling right now. So it's an area we can sort of address the problem.
Charts is another example. If you would ask me 5 or 6 years ago, we would build charts, I would have been like maybe, but if someone else came along and made a really great visualization tool for MongoDB, we probably wouldn't have built charts. But it's very important for our users that they have a great visualization tool. So we went ahead and build charts, same with TechSearch. Data Lake is 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 and they want a different kind of query language that's very easy to use to look at that data. And so that's sort of the lens we look at is how do we make developers a lot easier using sort of our query language, taking advantage of documents and distributed systems. And 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 kind of price separately elements, create tiers such that you can better monetize some of these efforts?
Yes. So data lake, for example, already is like that. Data lake is priced. You can buy it as part of Atlas, but it's not a part of Atlas. You buy Atlas credits, but it's charged separately, but it's all paper usage.
So if you're using Atlas today and you're paying for like 3 clusters, you start using data lake, you will just get a separate slice of the bill that is the data lake price.
Sanjeet, I
think, is that?
You. Siajit Singh, Morgan Stanley. Thank you for hosting us. It 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, is that we were the message last year that we're getting there. And then 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 Ittai's question in terms of monetization. So how do you think about 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 include that as a whether you monetize that directly and versus something like Azure Data Lake where you are, our price diversity. 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?
So, Tech Search is an
interesting one. So, even though we're not charging to use Tech Search, everyone who uses Tech Search is going to need to use more Atlas resources. You've got bigger disks, you use more RAM and more CPU. So anyone who uses Tech Search is automatically going to get a higher Atlas bill. So adding an extra cost on top of that didn't seem to make a lot of sense.
In addition, one of the big features, 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 are sort of driving adoption of Atlas even faster. Data Lake is different, right? Data Lake is totally different product going out to a different market where monetizing it directly makes a lot more sense. And then you've got things like Stitch and Realm, which are somewhere in the middle, right? They're both really good at driving adoption, right?
So triggers. Triggers and Atlas, you do pay for, but it's not priced in a way that's going to drive a massive amount of revenue directly, but 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 Mongo themselves to migrate to Atlas.
That's very helpful. And maybe I have a question on the partnership strategies. It seems that IBM has been very successful, Accenture has been ramping. As we think about the next couple of years, what do you guys have to do to like 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 are you guys going to have to sort of enable the channel, enable the partners with training and take to get them ramped? Like what are the key ingredients to get them to scale?
Yes. I'll say is, 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. So they're seeing firsthand how the market is changing. 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. So they're 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. And we play a big role in all those endeavors. Now we have a partner team who goes out and actually pursues these relationships because these are all large organizations. They know about MongoDB, but 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 and Capgemini has really accelerated, in Europe for us. So you're going to see us partner with people who either have some geographic expertise or maybe some vertical expertise. We do some work with boutiques around the financial services industry. And then the other thing that they do for us is reach, right?
So remember, even though we're growing really quickly, we're going after a massive market and we just can't hire people fast enough. And so 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 a bigger on MongoDB because they have a trusted advisor recommending that they use MongoDB all helps to create that virtuous cycle.
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 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. So while it's additive to sales productivity, it's not it requires a sales person 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. 1, 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, asset 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? And then one follow-up on go to market.
So it's pretty important. The reality with transactions is that a lot of customers want them for a very, very small percentage of what they need to do. And the bigger factor really is they don't even think they need them today. The bigger question bigger enterprises has is what if I need them 2 years from now. And it's a not having them was sort of a risk they didn't want to take.
Okay, you convinced me
I don't need transactions today, this workload, this application, you're right, I don't need transactions. But what if for some reason 2 years from now I do, not having them is a big risk. So 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 a 1,000 customers, you're going to be okay, now I can use Mongo. It's much more the okay, now I'm much more comfortable betting even bigger and more mission critical apps on Mongo because it's safe.
Super helpful. And then 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?
Yes. So, 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, best available action for sales folks and folks in customer service. I'd say it's pretty early on in that. And so I would say the success that we've had 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. But 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 onethree today to whatever it may be in the future, what impact does that have on the financial model? Thanks. Yes, sure. So the Atlas business, and a lot of times people, I think, because they've been struck by the growth and we provide a lot of visibility in reporting on it, tend to think of Atlas as quite monolithic.
And I think it's important to understand it's really 2 separate channels. There's the self-service side of the channel and then there's the sales sold side of the channel. And 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, so that's sort of without regard to kind of how it's sold. But increasingly, we are seeing Atlas being sold not in annual upfront contracts with cash paid upfront, But as customers have become acclimatized based on how they interact with all the other cloud players, the way they're used to or becoming used to consuming cloud as a service is metered usage paid for in arrears, right?
So even if I sign up for an annual commitment amount, right, I have a dollar 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. And so you'll see that flow through in terms of, again, 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.
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 and maybe there's some signs that they're changing that as you see Google being more friendly to the open source community. But just kind of walk us through how you've seen that dynamics change
and if it's you see a
more favorable outlook going forward?
I'll make a couple of points. One is each of those cloud providers told us proactively that MongoDB was one of the most popular technologies in each of the respective cloud platforms. And they actually funded the deployment of Atlas on their particular cloud. 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 3 years ago, Microsoft came out with Cosmos.
They actually first called it DocumentDB, but then they renamed it Cosmos. And 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 into the cloud and go compete with us or offer a 3rd party managed MongoDB service. So they can only emulate our features and because you're emulating features on a very different architecture, the feature 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. So 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 3 years ago. I think in January of this year, Amazon introduced DocumentDB against the same reason. They saw the success of both the popularity of MongoDB and obviously the success of Atlas. And I guess they assume that they could try and also get a piece of that market. And again, we don't really see them in many deals today.
We've yet to lose them on a head to head bake off, again, because they're based on a relational architecture with MongoDB API on the front end. So they cannot deliver on all the features we have nor the performance characteristics we have. And 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. So in terms of nature of relationship, I would say it's a spirit of competition. Now Google on the other hand has made a very conscious decision to partner first and their decision was that they want to do what's best for customer And rather than basically try and use for 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 in our cloud.
They said we're going to be very open. And they came to us, we proactively work together. Now 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. So we think that that will be quite helpful. We're already partnering in the field. But we partner the field with all 3 vendors. We're working with Amazon for their accounts.
We're working with Google where they have a presence and the same with Microsoft. So I would say it's a spirit of competition. Obviously, the only difference is with Google, there's no real alternative.
Great. And then a follow-up for 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. And 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?
Yes, sure. So as we've talked about, just for those who are newer to the story, so 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. And as we continue to expand Atlas, we're seeing organic Atlas gross margins expand.
So we've been very pleased with the organic gross margin expansion and progress that we've made. If I kind of 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 pulled the levers that we wanted to pull sort of in line with plan or on time or slightly ahead of schedule. And so far we've got kind of more bang for the buck than we expected. So 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. But in general, we see the kind of the portfolio in aggregate being accretive and that over time, the difference between kind of the enterprise advanced package and the Atlas packages will decrease.
And we've learned nothing. Certainly, I've learned nothing since going public and as we continue to execute on our game plan and 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 sort of that 70 plus percent of the gross margin line. And I think we're tracking nicely for that. Raimo Lenschow from Barclays.
Dave, in the keynote, you talked about like one thing that we delight was the changes to the curriculum for the high schoolers in India. Maybe just frame it a little bit broader. Like 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? And then I have more second question is more around the data lake.
If I take just to try to understand it better, if I take data like the cold data out and just kind of have it stored in S3, does that kind of make my Atlas deployment on the higher cost storage kind of smaller and you have like a kind of a headwind that you kind of face, but then you get back at the deployment? Just trying to understand the things that better. Thanks.
Yes. So, sorry, the first part of your question was, developer ecosystem, sorry. So, I'll give you a couple of data points. One is we've seen other technologies come before MongoDB and claim to be the Oracle killer. So object oriented databases and XML databases.
And ultimately, they all failed. And the reason they failed is just didn't have developer mindshare. They just didn't have the incremental value for people to go learn this new technology. So they just never got the traction with the developer community. That is not the case with MongoDB.
So when you the anecdote I gave about India, I'll give you another anecdote. We had an intern program we have an intern program. We hire roughly about 80 people interns around the world, here in New York and Dublin, and we actually started a program in Sydney in their summer, which is our winter months, and we had close to 20,000 students apply for that intern program. That's better. The admit rate for our intern program beats any selective college or university in the world.
And that speaks to how popular MongoDB has become. So 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, but especially when they start talking about database architectures. And so when then you see other facts like the size of our ecosystem, you look at DB Engines ranking, us and Postgres are the 2 fastest growing databases across the landscape. You look at like the activity in Stack Overflow, you look at there's so much data out there and obviously you have your own contacts, relationships, you can validate all this. But one of the big things, one of the real assets about MongoDB is that developers love MongoDB.
And our business starts and stops with the developer community, which Elliot always reminds me once in a while. And so that is something that we take very, very seriously. You'll see us making more investments and engaging more of the developer community. While we have great mindshare, we think we can do far better, especially around just driving awareness of even Atlas. A lot of people know MongoDB, but don't even know that we have a managed offering because not everyone attends these kind of conferences.
And so 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, so I think the short answer is no. So the question really is, hey, if you have data lake, are people going to put data in the data lake rather than in Alice? And I think the kinds of data people are going to use for data lake are something they would never consider in Alice because it's frankly just way too expensive. And 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 Hadoop thing and they're trying to figure what to do with it.
And they're all right now just putting on an S3 and jumping to a lot of hoops to query it.
And so we're going
to take something that 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 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 to do with your online data.
Thanks very much. Michael Turits from Avon James. I think definitely 2 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?
Yes, 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. And again, 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. And there's certain capabilities that we wanted in the databases we didn't have and now it's full text search. When I joined the company 5 years ago, we're talking about adding full text search, but it just kept the priority at that time kept getting lower to address a lot of other things like asset and some other features. So this is just broadening up the core platform as well as enabling developers to get find it just really, really easy to work with data. That's the central tenant in our ethos in terms of how we think about the market.
And then I'll stick with
the competitive line and ask about cloud native. You began to talk about it, Dave, 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?
Yes. I would say that there's 2 phenomenon that we see. 1 is something we can't do much about. Those are deals that are happening without being involved, right? So 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 their 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 third of that is 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 decision and basically just want to get off and to them in their mind, this is much easier to go to relational database than to replatform 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 as they if they just do a lift and shift, they don't really get the full benefits of a hyperscale cloud platform. And so that's where MongoDB really like for example, we have a feature called Global Clusters. A relational database cannot do this. That feature has 2 benefits. 1, 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.
Like 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 and it adds a lot more cost and complexity for that developer. So that's an example where as people start thinking about the power of MongoDB and leverage the full benefits
of the
cloud, we're starting to see and 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 Husek from Ashlar. Could you touch on what you expect to be the common use cases for search, your customers, whether using Elastic today and they can swap it out?
So the simplest way to think about it is for a
lot of the people a
lot of the data people are storing in Mongo, right, is transactional data for applications, right? So product catalogs, content management systems, CRM kind of data. And for that data, most people want some sort of search. And right now, they really have to sort of take that data out of Mongo, put it somewhere else, sort in both places for search to work. So it's still sort of like any website based on MongoDB probably has a search box.
And that search box is probably not using MongoDB search today. And 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 we've got online data, a website, something like that. It could be internal, it could be an internal app, it could be an external app.
That doesn't matter so much.
We probably have time for 1 or 2 more questions.
Hi, Karanur Kataram from East Grove. I'm 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 10x, 50x, 100x?
I would say there's some debate internally, but it definitely starts at 10 and goes higher.
As Dave said, bangerine is really popular.
Yes, we like the stock, in case you can tell.
Any other questions? One up in the front. Actually, just for the streamcast thing.
Neha Chopra from Ratan. I think you guys talked about I think, Alex, 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?
So 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. So 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. So really comes down to how many percent what percentage of people want search and on what percentage of their data?
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 are the most wanted database, but you are not the most loved database according to the same survey. So what is it from your discussions with your developers that they still don't love about MongoDB?
Yes. I would say that's a distinction, I think, without a difference. Like so I think people where there's moving their 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. And so I think we feel really good about our ecosystem.
If you just walk around the show floor and talk to customers, I mean, it's almost a movement upstairs in terms of people whose passion and enthusiasm for MongoDB. And that creates a nice spiral effect because as you heard from some of the customers in the last panel, as they start using us for certain workloads, the work involved, I mean, every customer I talk to says their developer says, no, no, I want to work on Mongo. And that speaks to also why there's so much developer enthusiasm in the next generation developers coming out of school because they're used to working on more modern technologies, modern programming languages, modern frameworks, microservices architecture. And 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. So I think the puck is moving too in our direction.
Okay. We are out of time. Thank you all for coming. I appreciate your time and attention during the program today. And I'm sure we'll see you back out on the road.
Thank you.