Another new thing is faceted navigation. If you've ever shopped on Amazon or any e-commerce site and you could narrow your search results by size or color or price, that's faceted navigation. Lots of people who build apps on MongoDB want faceted navigation and today they do that by adding Elasticsearch or some other search technology like Solr. And that means more servers, more things to manage and more complexity. And there's always some delay between the search index and the actual database, so we think that faceted navigation should just be in the database. You should be able to do great searches in the database directly without standing up a whole other cluster of machines.
Then the most interesting thing to me was what we call zone sharding. Sharding is a capability that all NoSQL databases have, which is the idea that you can scale out horizontally. But the way that pretty much everyone does it is they randomly assign the data to different servers. The truth is there are a lot of cases where you want to control exactly which servers the data is on for a few different reasons. One example is data sovereignty. If you're running a global deployment, there are some countries that require that the data not leave the data centers of that country.
Another example is what some companies call "multi-temperature storage." So you have really high performance storage for your "hot" data that you're accessing frequently and then lower cost storage for different access patterns. With zone sharding you can assign data to different physical data centers, to different types of storage and a third use case is if you want to ensure a great experience with low latency writes and reads for users depending on where they live. So your New York users can read and write their data really fast and your California users can read and write their data really fast. You understand where those users are and if one goes on vacation, you can assign them to the other group.
So this concept of zone sharding lets people take MongoDB for global deployments, for multi-temperature storage, for data sovereignty requirements and address those out of the database, which is really exciting and which is really charting new territory in terms of how people are running global databases. No other NoSQL product is going to give you that kind of functionality.
What can you say about future directions for MongoDB?
Well, I think Atlas is very exciting and clearly we're going to keep building out where you can take advantage of Atlas. I'm not announcing anything, but to me intuitively, if you look at running an app there's a lot of moving parts. What we've tried to do with Atlas is take a bunch of those moving parts and simplify them into a service that you just pay for by the hour. There are still layers of the stack that we could build into that service. And those exist from other technologies; they exist from each of the cloud providers that have their own pieces of the stack that we could potentially integrate with. So I think there's more opportunity for us to expand where you can take advantage of Atlas, but to also integrate with other pieces of the stack more efficiently.
I think another thing that we can do in the bigger picture is automatically fix things before they go off the rails. We have an enormous amount of data about how people use MongoDB based on five years of monitoring history and thousands and thousands of deployments and mining that to come up with predictive models to suggest what are the indicators that something is about to go wrong. We can tell a user that they might want to fix this problem or click a button and we'll fix it for you, or we'll just automatically fix it for them. I think about that as a prescriptive management capability that would also be charting new territory for databases that no one is really doing right now. They may give you better tools to fix things, but going that next step to pre-emptively notify you that something could go wrong? I think is really interesting new territory.