Nutanix, Inc. (NTNX) Earnings Call Transcript & Summary

Good day, and thank you for standing by. Welcome to the Nutanix Era Database-as-a-Service Tech Talk. [Operator Instructions] Please be advised that today's conference call is being recorded. [Operator Instructions] I would now like to hand the conference over to your speaker today, Mr. Rich Valera, Nutanix' Vice President of Investor Relations. Please go ahead, sir.

Thank you, Deshondra. This call is also being broadcast live over the web and can be accessed from the Investor Relations section of Nutanix website. I'm joined today by Tobias Ternstrom, Nutanix' Vice President and General Manager, Workload Automation. Tobias has held positions at multiple leading technology companies, most recently, Tobias ran product management for Amazon RDS and Aurora. Prior to joining AWS, Tobias led product for GCP's database service portfolio. And before that, he held multiple positions at Microsoft across Azure and SQL Server. Tobias is originally from Sweden, where he founded and worked in start-ups, until moving to the U.S. in 2008. Thank you for joining us, Tobias. During today's call, we may make forward-looking statements, including projections about our database-as-a-service addressable market and our product road map. These forward-looking statements are subject to risks and uncertainties, some of which are beyond our control, which could cause actual results to differ materially and adversely from those anticipated by these statements. For a detailed description of these risks and uncertainties, please refer to our SEC filings, including our annual report on Form 10-K for the fiscal year ended July 31, 2021, and our quarterly report filed on Form 10-Q for the fiscal quarter ended October 31, 2021. These forward-looking statements are based on our current expectations, and we undertake no obligation to revise these statements after this call. As a result, you should not rely on them as representing our views in the future. As a reminder, no financial information or projections regarding Nutanix' performance will be discussed or implied on today's call. We thank you for your cooperation in advance. Finally, a supplemental slide deck can be found on the Events section of our Investor Relations website. And with that, I'll turn it over to Tobias.

Awesome. Thank you, Rich. Great to meet everyone. So let's jump into -- to hear a little bit about what we're doing with databases and database-as-a-service here at Nutanix. And we're going to cover the opportunity of database-as-a-service, databases with Nutanix Era, a couple of customer case studies and get into a little bit of our road map, as Rich mentioned, then move into a Q&A session. So starting off with our database-as-a-service opportunity. I'd like to cover a couple of database trends to make sure that we are on the same page of what's going on in the market. First of all, it might sound obvious, but most applications use a database. And in fact, and when we talk about most it's really very, very rare that a database isn't used by an app. But in fact, many apps use multiple databases. Further, increasingly, microservices architectures are used. And if you're going down the microservices path, you want each microservice to be an isolated and be able to be deployed on its own without affecting other microservices, which leads you to also want to use a database per microservice. Further, application frameworks tend to determine the database engine that's being used when you build it up. So back in the day, if you go back a decade or 2, you typically as with organization picks the database engine first, might be building on top of Oracle, SQL Server, DB2, something like this. And then when an app was being built, we said, okay, this is the database we're betting on. So design your database build wrap on top of this engine. But these days, that's not the case. Instead, you typically build an app on top of an existing framework, and that framework is built either supporting multiple databases. But typically, there is one database in mind that the primary database for the framework. So this framework will pull in the database engine being used. So for example, if you're building on WordPress, a common simple example, WordPress is built on MySQL, so that will pull in the MySQL database engine. So all of these together leads to the fact that organizations just keep running more and more databases, often in the thousands to tens of thousands in a single organization. Now when it comes to the type of database you're building, if you're building a new application today, by far, most apps are built on top of an open source database. So something like PostgreSQL, MongoDB or MySQL. However, the majority of existing applications out there, especially that large enterprise companies are running on, they run on proprietary databases like Oracle database and SQL Server. Further, there are different types of databases often categorized at the highest level to relational and nonrelational. And both of these segments are growing. Relational is still the biggest, and I would say we expect relational to continue being in the clear majority. So this needs -- this leads to organizations using multiple database engines. And because of this fact that there are more and more databases being used, database administrator, DBA time is becoming more and more precious. So database administrators want to be able to efficiently manage all of these databases and database engines being used, and also be able to spend their time on the most critical systems for an enterprise. At the same time, developers, they don't want to have to wait when they need to build an app or build a new microservice. They want to be able to provision the database they need, the database engine they need and start developing. And this leads to an increased adoption of database-as-a-service, which basically means that you can provision databases and manage them en masse without having to go into how to manage each specific database. So the advance of automation around managing databases. Now when we talk about database-as-a-service, there is a landscape out there is various types of database-as-a-service. And we think you can classify these into 4 categories. So first category, which is I think what most people know about is cloud vendor DBaaS. Meaning a cloud vendor like AWS, Azure, GCP, Ali Cloud, and so on, that provide database-as-a-service solution. And generally, they support multiple database engines but also typically only on their own cloud. Now another category is kind of the opposite, which there is a database vendor that provides database-as-a-service. Now some of the database vendors are also cloud vendors. But when a database vendor provides a database-as-a-service experience, they generally do this across multiple clouds but they only support their database engines. So generally a single database engine. Now the third category is multi-cloud DBaaS, which is basically a vendor that says, okay, can we support multiple database engines across multiple clouds, so you get the same experience across these cloud vendors and across database engines. And then finally, we have the hybrid multi-cloud DBaaS category, which is basically taking multi-cloud and saying, well, we may not only need to run this in the public cloud, you may also need to run the database on-premises or at a colocation or a managed service provider. So you combine multiple public clouds, on-prem colocation and multiple databases. And this is also the category that provides customers the most flexibility and the most choice when it comes to both environment and database engine. And this is where we are focusing with Nutanix Era, at Nutanix to make sure that customers can run the database in the environment that makes sense for that particular workload as well as the database engine that's right for that workload. So what that are our customers asking us for? Well it's to reduce the risk, effort and cost of operating large fleets of databases, so hundreds of thousands to tens of thousands of databases; meet business requirements across security, high availability, disaster recovery, performance and scale; and to run both proprietary and open source as well as both relational and nonrelational databases. And they want to enable their developers to use databases without having to bother the database administrators while also retaining full control on their database service. So let's spend a little bit of time on this control business. So there is a little bit of a conflict generally out there today between control and automation. So what do I mean by control? Well, on a database server, can I pick the operating system being used or the operating system version, or the database version, the past level of the database? Can I install my own auditing or monitoring agents that I use for maybe for regulatory reasons? Can I install my own expenditures that I built to make the database do certain things that they didn't out of the box? And do I have full admin privileges on that machine? So if you look at this as 2 axes there, the level of control on the x-axis and level of automation on the y-axis. If you take a traditional 3-tier deployment or using virtual machines and some storage back, you get a lot of control because it's your VMs, you can install exactly what you need on the machine, but you don't get the automation. You have to manage the database yourself. You have to manage provisioning, configuring disaster recovery, high availability, all of these things. If you choose a traditional DBaaS environment, well, then you get automation. You click a button, hey, give me a highly available database and the database is provisioned for you and you can start using it. So it's automated, but you don't get the level of control. You can't take, for example, operating system or install a certain auditing agent on that server. And this is where we're differentiating with Nutanix Era, where customers get both worlds. They get to have the cake and eat it too, if you will, so they can install. They have the control they need. They can run their software that they need in order to fulfill their business requirements, but they also get the full DBaaS automation so that they can help their -- both their database administrators and their developers be more efficient. So what is Era? So Era is our hybrid multi-cloud database-as-a-service. So basically, it provides a single [ pane of glass ] if you will, within an API, a [ GUI ] console and command-line-interface where you can manage your databases. You can provision, scale, patch and so on, and it's all automated. Today, Era supports Microsoft SQL Server, Oracle Database, MySQL, PostgreSQL and MongoDB. And you can run -- and this runs on the Nutanix cloud platform, which supports the databases in Era on-premises, in public cloud as well as in colocation and managed service providers. So a little bit more about what is Era. Well, again, it's automated management of thousands of databases on hybrid multicloud. It meets the security high availability, disaster recovery, performance and scale and cost requirements that customers have. It enables developers to self-service their database needs, and it enables database administrators to focus on the organization's most critical databases. So if you pick an organization that has something like 10,000 databases, they're all important, varying importance in terms of criticality. But typically, a handful of databases, say, between 1 and 5, are absolutely mission-critical to their business. And this is where you want the DBA team to spend the absolute majority of their time to make sure that those systems run. And you want the rest of the databases or the rest of the, 9,995 to be as automated as possible. And again, to let developers just provision the databases when they need to. What's different about Era? Well, we support the most popular database engines, again, across open source and proprietary in a cross-relational and nonrelational. So you don't have to pick only a certain database. The databases that we support that I mentioned are actually the top 5 most popular databases in the world today. Manage both new and already deployed databases. So this is a pretty big deal. Typically, when you adopt the DBaaS platform, in order to move into the DBaaS platform to realize the automation, if you will, you need to somehow migrate in, which means you need to set up a new server in the DBaaS platform and then export your data and import it into the DBaaS platform, configure the server the right way and somehow fail over your workload. However, with Era, Era can manage existing already deployed databases that run on the Nutanix infrastructure. So if you have your databases running, then you can basically tell her, hey, start managing this database for me. So there is a -- overall the same amount of [ data ] to get into it. You basically just start managing what's already there. As I mentioned before, customers retain full control of the database servers. They can install extensions they need, auditing, plug-ins, and they have admin privileges on the server as needed. Nutanix also towards provides end-to-end support. So from the requirements that we have on hardware or the public cloud vendor, all the way up to the database engine. And we provide the same experience managing these databases at scale across public cloud, on-premises and colocation. So let's talk a little bit more about this, why hybrid multi-cloud. It is an interesting discussion. And it's really about cost effectively running applications or workloads. So I'll start by taking the 3 I think commonly used examples to kind of set the stage and then we'll get into a little bit more around why this is important. So I think the most common example people typically talk about, if you have a primary site in a data center and you want a disaster recovery site. So basically, it's the hypothetical, if you will, meteorite hits your data center, you can fail over to the DR side. And this is where public cloud to be a very good solution and a very cost-effective solution because I could potentially provision less resources in the public cloud until I actually need them and then fail over from my primary site, on-premises to the DR side and especially protect my data. So I replicate my data over to the public cloud in case anything happens to the primary site. Another typical example here is highly variable consumption. So if you look at this chart, we have resource consumption on the y-axis and over time on the x-axis. And you have a workload that looks something like this. So on average, it doesn't use a lot of resources. So for example, on average, maybe it needs 4 machines worth of resources. But a couple of days a year, maybe a month a year, it needs maybe hundreds of machines worth of resources. Where is it most cost efficient to run this, well typically in the public cloud because I can provision only exactly the resources that I need. And when I need tons of resources, I don't need to buy the 1,000 machines I need for the peak, instead I can just scale up. The other example would be location-dependent requirements. So kind of the opposite. And it will have the same type of 5G workload but I have requirements when it comes to typically latency or regulation. So latency would be -- I have a factory doing manufacturing. And I have an application that sits next to machines that needs to communicate with machines in as close to real time as possible. It might be they be microsecond away. And in this case, I need to run, obviously, application on that premises, so next to the machines. Regulatory, so similar, you have some requirements that says these databases, these applications need to run in very specific buildings, maybe even in specific vaults inside specific buildings. So obviously, for these 2 examples, I have a location requirements, I need to run these applications and databases on premises. Some of this is also called [ end source ]. Now what about other workloads that don't fall into these 3 categories. So we have the same type of chart here. The resource consumption on the y-axis and over time on the x-axis. And think if we're starting up a completely new company. We're starting from scratch, which would be, likely in most circumstances, I have low consumption so I'm not using a lot of resources. And where would it be most cost effective for me to run something where I don't use a lot of resources, well that's generally in the public cloud. So I start in the public cloud. And then over time, sorry -- now we have the other y-axis here on the right, cost per consumed unit. So how much does it costs for me to run this consumption per consumed unit, if you will, memory per hour and CPU per hour and so on. And generally, in the public cloud, the cost is pretty significant. So there is a good paper. I'm sure everyone here has read it, the Andreesen Horwitz on the $1 trillion paradox that goes into some pretty good explanation of this problem. Now as my workload increases, my cost per consumed unit generally remains the same. They are obviously reserved instances, discounts to be gotten. But there is some level of cost per consumed unit, that is, what I will land on. And then I can't affect it all that much other than trying to make by workload itself more efficient. And this is where I might be able to save money by moving to a colo where I -- as long as I can run in the colo with the same type of efficiency as in the public cloud, meaning I don't need a ton of people to manage the servers, so the servers need to be highly automated. The system has to be easy to use, highly automated. So then if I move into a colo, because of the fact that I can provision the machines myself, I can save and reduce the cost per consumed unit. And then potentially over time, I increase even more and need to drive down the cost per consumed unit further, and then it might be more cost-effective for me to run this workload on-premise. And I think it's worth pointing out that this is a natural evolution. I would say today, obviously, we have a bunch of data centers out there, everyone running on-premises, and that's because the cloud is relatively new. So everyone who had data centers or workloads before the public cloud, obviously, have data centers. And now there's a lot of work for people to look at -- where is it most cost efficient to run. But I would argue the natural way, if you start from scratch, is this where you start in the public cloud and you actually move towards on-premises, depending on your consumption level versus the reverse. Now another thing that I think maybe isn't talked about enough is the fact that this is a regional thing. So we started our company in Cape Town. So in Cape Town, our workload grew into on-premises. But what if we're now launching our workload and saying we're going after customers in New York in a new site. And we're doing this, obviously, because of the experience – Cape Town is quite a ways from New York. So if we try to run it in the Cape Town data center, that might not give customers in New York a great experience. So we're starting from scratch, if you will, in New York. And obviously, there, we wouldn't start on the public cloud and maybe we start using Amazon Web Services in New York. Then potentially, we start a new site in Frankfurt for German customers, where maybe we started on AWS and then we realized that in Frankfurt, Azure provides a better or more cost-effective option for us. So we move into Azure. And then maybe we acquire an organization in Bangalore, and they already have their workload running on-premises. So through this kind of natural evolution, you end up with a mixed world where some workloads that make total sense to run in the public cloud, some in a colo and some on-premises. And digital customers are looking to have an easy solution, a flexible solution where you can actually run across heterogeneous environments, not because you just ended up there, but because there is a natural evolution. So customers are looking for the most cost-effective environment that meets business requirements for a set of applications. Some of them might, for example, be location requirements, in a region at a given consumption level. So let's shift gears a little bit, jump into a couple of case studies. First here, we have a customer of ours using Nutanix Era, RBL Bank, which basically wanted to help with management of their production Oracle and SQL server databases. And I'll play you a little bit of a video here that gives a little bit more information about this case study. [Presentation]

Let's talk about another customer of ours, a global retailer that runs data centers all across the world, that were looking to basically make their developers more efficient. So they wanted to reduce deployment time for their developers so they can self-service and reduce the time spent from the DBAs, both for them working with developers and fulfilling requirements but also helping their DBAs focus on what's most important. And they deployed Nutanix Era managing Oracle database, including Oracle Rack, SQL Server and PostgreSQL and used Nutanix Era and Nutanix cloud platform. This is specifically a database solution that they choose Nutanix Era for. Another example is a Fortune 50 financial services company. So similarly, this customer was looking for a database-as-a-service solution, but their underlying need was about very focused on database administrator efficiency. So this customer has a business objective to move off of proprietary databases to open source databases. And they want to make sure that while doing so, they can still effectively manage their existing proprietary databases as well as the new open source databases without adding a ton of complexity to their DBA teams. And so they choose Nutanix Era to manage PostgreSQL as well as the proprietary databases to deliver a modern database platform. And I should say both of these customers -- or all 3 of these customers I talked about are in production with Nutanix Era today. So what about the road map? We have 3 investment areas for Era. The first one is very obvious, if you will. It's listening to our customers and continue adding capabilities and supported database engines to Era. Another one is increased support for cloud-born workloads with native cloud support. So this is, for example, being able to use Nutanix Era in Azure and say, hey, Nutanix Era, please manage these databases. I have already deployed in the [ editor ] containers of an Azure Compute or in, for example, EC2 and EBS on AWS. And the final one is investments into the core database of an open source database, maybe PostgreSQL to make kernel investments basically to provide customers increase the performance, scale and so on, on the Nutanix platform and the cloud. In terms of the market opportunity, this is the same figures that we showed in the Investor Day in June of last year, where we're saying the database-as-a-service addressable market, specifically for Era and database-as-a-service. So in these numbers, we don't include, for example, infrastructure or the cloud cost, if you will. It's focused on the database management piece, where last year, we had that addressable market for Era at $5 billion growing to $8 billion in 2025. We think that's a pretty conservative estimate. So in conclusion, Era addresses a growing multibillion dollar opportunity for Nutanix. It's differentiated by its support for hybrid multi-cloud environments, the most popular database engines, provide customers with full control of their database servers and support both new and already deployed databases. And we're continuing our investment in Era which focuses on customer demand across database-as-a-service features, additional databases and workloads as well as cloud-native capabilities. And that's it for the presentation. So let's move into Q&A.

[Operator Instructions] Your first question comes from the line of Mehdi Hosseini of SIG.

Yes. I have a big picture question, more in terms of the structural changes. It seems to me that most, if not all the new apps developed are container-based. And in that environment, especially since the app developers may not be familiar with a hybrid cloud infrastructure, how will the container-based workload change or impact a database management and impact for Nutanix product like Era?

That's a great question. Thank you. I would say it really doesn't an impact. If you think about the slide where I walked through the database trends. So microservices architecture is growing pretty fast, and that's very much a container-driven, if you will, from an application deployment standpoint. And at the end of the day, why customers like or developers like to build on containers, it's because it's easy to deploy, easy to manage, easy to package and so on. And it's exactly the same thing with database-as-a-Service, because it's only an API call if you say, hey, give me a database. So if you think about it this way, I deploy my container, and let's say, it's the first version of the app. So I deploy my container, and at the same time, I issue a call and say, hey, give me a database for my container. Database is automatically provisioned, I get the connection string and I can connect and deploy. So they work very much hand-in-hand, container applications and database-as-a-service, including Era. And you would run this. The same thing applies across on-premises, colocation and public cloud when it comes to how you deploy apps on containers.

I have a follow-up. Can I ask the follow-up?

Yes. Sure.

Sure. And then just as an extension of that question, I imagine most of the new data created these unstructured fiber object storage. Does that require you to be working more closer with storage hardware vendors? Or does Era or does the storage have any impact or influence on adoption of Era?

It's a good question. Not really. I would say, at the end of the day, there's kind of 2 types of storage here. One is the storage that Era itself uses, which might be on AOS, for example, Nutanix AOS or on something like EBS in the cloud. And when it comes to interacting with storage, so this is data stored unstructured in, for example, S3 or on the Nutanix [ Object ] store. There, it's up to the database engine. So for example, there are extension for PostgreSQL such that you can interact with this data. And obviously, there are tools available, ETL tools and so on, so that you can move data around. Often, you use something like Kafka to push information between systems -- really something that's kind of related directly to Era.

Your next question comes from the line of Aaron Rakers of Wells Fargo.

Okay. Sorry about that. I appreciate you guys doing this presentation. I guess a couple of questions for me as well. I mean as we think about the evolution of database-as-a-service and relative to kind of how you've outlined the TAM, the addressable market opportunity, the $5 billion growing to $8 billion, I'm just curious where are we at today as far as the build-out of the product portfolio? Do you address the full $5 billion of that TAM today? If not, how do we think about the extension of that addressability of that full TAM opportunity?

Yes. That's a good question, Aaron. So the way we looked at this is basically, this is a market that we could address today.

Okay. And so there's -- I guess the follow-up question to that would be is how -- because I believe you mentioned that further support, database support, et cetera, as that builds out, how do we think about the further extension of that TAM opportunity?

Yes, it's a good question. I don't really have a good answer for you. It's something that we're looking at internally a little bit more. But the TAM, from a Nutanix perspective, is pretty substantial. So yes, we don't have a good answer. As you add more database engines or certain capabilities, how does that change the TAM. We're more focused on just making sure we help our customers and win the trust of more customers.

Yes. I appreciate that. I think one of the other questions I had is that I think last quarter, I think it was like 42% of your deals had at least one of your -- of Nutanix' emerging products. And I think that's on a trailing basis, 4-quarter average basis. How the material has -- is there any kind of penetration rates or any kind of adoption rates that you can share with us on how successful Era has been?

Yes. It's a good question. Unfortunately, this is not something that we can address on today's call, but you may be able to reach out to Investor Relations for some more information.

Your next question comes from the line of Mike Cikos of Needham & Company.

Tobias, thanks a lot for doing this call today. I definitely appreciate it. I had a question for you on the investment areas when we're thinking about Era. And the first one that you guys had brought up was this focus on listening to customers and continuing to build out additional capabilities. Can you talk to us about what customer feedback has been like thus far? And maybe help us think about the additional capabilities you're looking to continue to bolt on to the Era solution.

Yes. Yes, sure. That's a good question. Look, I would say a lot of our asks is -- so one of the, I would say, hard things to do with Nutanix Era and part of our differentiation is this support for existing environments. So generally, if a customer comes in and says, hey, we run this particular database engine on this version of our operating system on this type of storage setup, for example. And then there might be something in there that we don't support yet. And then we work with the customer to add support for these capabilities. So I would say a lot of what we're seeing is where we need to tweak something. It also might be something where the first couple of workloads that we pick up for the customers, everything fits nicely. But then they say, hey, for this other type of work that we have over here, we need support for this type of thing, right? So I would say it's mostly around those types of things when it comes to additional capabilities. And outside capabilities, it is, hey, do you have support for this database engine, right, that is not on your list of 5 today.

That's great. And then just one other one, if I could. I know that you guys had spoken about customer demands are going to vary, right? If I think about security compliance, maybe locational requirements, is there a typical requirement that you're finding more and more of your customers are focused on? Or is there a dominant prioritization there? Or does it really just run the gamut based on the variety of customers that you're feeding it to?

Yes. I think the main thing I think we hear about where it typically starts is flexibility. At the end of the day, they realize, hey, I'm going to be in this mixed world. Some of these things need to run on-premises for various reasons. Some are in new sites where we run public cloud. Some might be in areas where I don't want to invest in a colo or a data center, so I need to run public cloud. And so now I end up with this heterogeneous environment. And even if a specific public cloud I'm running in a region as a database service, now I have a specific set of APIs for that cloud, might be specific database versions that are supported. I don't have the control and it becomes more and more positive for me to maintain these different types of configurations. So going down this path where they want their DDAs and developers to be efficient, it's very, very helpful to have 1 pane of glass so that they can have 1 experience for both deploying and managing production workloads, but also for development and test that also tends to be regional with CICD pipelines and so on.

That's great. And I promise this is my last comment here, but it really sounds like that -- that initial conversation you had about offering your customers both this control and automation, that really sounds like what you're tapping into in those last couple of comments that you had. So I really appreciate the color again.

Yes, absolutely, absolutely. Thank you.

[Operator Instructions] I'm showing no further questions at this time.

Rich, do we want to call it?

Yes. I think that's it. We can wrap it up there.

Awesome. Thank you, everyone, for taking the time to listen in and for the questions. Super helpful. Thank you.

Thank you.

Thank you. This concludes today's conference call. Thank you for participating. You may now disconnect.