Good day, and thank you for standing by. Welcome to the Nutanix Era Database as a Service tech talk. At this time, all participants are in a listen-only mode. After the speaker's presentation, there will be a question-and-answer session. To ask a question during the session, you would need to press star- one on your telephone. Please be advised that today's conference call is being recorded. If you require any further assistance, please press star zero. 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's website. I'm joined today by Tobias Ternström, Nutanix's 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. 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 roadmap. 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 31st, 2021, and our quarterly report filed on Form 10-Q for the fiscal quarter ended October 31st, 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's 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. With that, I'll turn it over to Tobias. Awesome. Thank you, Rich. Great to meet everyone. Let's jump into and hear a little bit about what we're doing with databases and Database as a Service here at Nutanix. We're going to cover the opportunity of Database as a Service, databases with Nutanix Era, couple of customer case studies, and get into a little bit of our roadmap, as Rich mentioned, then move into our Q&A session. Starting off with our Database as a Service opportunity, I'd like to cover a couple of database trends to make sure that we're on the same page on what's going on in the market. Yeah. First of all, it might sound obvious, but most applications use a database. In fact, when we talk about most, it's really, you know, very rare that a database isn't used by an app. 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 isolated and be able to be deployed on its own without affecting other microservices, which leads you to often want to use a database per microservice. Further, application frameworks tend to determine the database engine that's being used when you build an app. Back in the day, if you go back a decade or two, you typically, as an organization, pick the database engine first. Might be building on top of Oracle, SQL Server, DB2, something like this. When an app was being built, you said, "Okay, this is the database we're betting on, so design your database, build your app on top of this engine." 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's the primary database for the framework. This framework will pull in the database engine being used. For example, if you're building on WordPress as common simple example, WordPress is built on MySQL, so that would pull in the MySQL database engine. All of these together lead 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 non-relational, 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. This leads to organizations using multiple database engines. Because of this fact that there are more and more databases being used, database administrator and DBA time is becoming more and more precious. 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. 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. There are a bunch of automation around managing databases. Now, when we talk about Database as a Service, there is a landscape out there. There's various types of Database as a Service, and we think you can classify these into four categories. First category, which is I think what most people know about, is cloud vendor DBaaS, meaning a cloud vendor like AWS, Azure, GCP, Alibaba Cloud, and so on, that provide the Database as a Service solution. 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 a 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?" 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 a public cloud, we may also need to run the database on-premises or at a co-location or a managed service provider." You combine multiple public clouds, on-prem co-location, and multiple databases. This is also the category that provides customers the most flexibility and the most choice when it comes to both environment and database engines. 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. What are our customers asking us for? Well, it's to reduce the risk, effort, and cost of operating large fleets of databases, hundreds to thousands to tens of thousands of databases. Meet business requirements across security, high availability, disaster recovery, performance, and scale. To run both proprietary and open source, as well as both relational and non-relational databases. They want to enable their developers to use databases without having to bother the database administrators, while also retaining full control of their database service. Let's spend a little bit of time on this control business. There is a little bit of a conflict generally out there today between control and automation. What do I mean by control? Well, it's on a database server, can I pick the operating system being used or the operating system version or the database version, the patch 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 extensions that I built to make the database do certain things that didn't do out of the box? And do I have full admin privileges on the machine? If you look at this as two axes here, the level of control on the X-axis and level of automation on the Y-axis. If you take a traditional three-tier deployment or using virtual machines and some storage stacks, you get a lot of control because it's your VM, 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 and say, "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 pick, for example, operating system or install a certain auditing agent on that server. 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. They have the control they need. They can run the 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. What is Era? Era is our hybrid multi-cloud Database as a Service. Basically, it provides a single pane of glass, if you will, with an API, a GUI console, and a 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. This runs on the Nutanix Cloud Platform, which supports the databases in Era on-premises, in public cloud, as well as in co-location and managed service providers. A little bit more about what is Era. Well, again, it's automated management of thousands of databases on hybrid multi-cloud. 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. If you pick an organization that has something like 10,000 databases, you know, they're all important, varying importance in terms of criticality, but typically a handful of databases, say between one and five, are absolutely mission-critical to their business. 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, the rest of the way to your 99.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 and across relational and non-relational. So you don't have to pick only a certain databases. The databases that we support that I mentioned are actually the top five most popular databases in the world today. We manage both new and already deployed databases. So this is a pretty big deal. Typically, when you adopt a 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 can manage existing, already deployed databases that run on Nutanix infrastructure. If you have your databases running, then you can basically tell Era, "Hey, start managing this database for me." There isn't at all the same amount of friction 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 plugins, and they have admin privileges on the server as needed. Nutanix also provides end-to-end support. From the requirements that we have on hardware or the public cloud vendor, all the way up to the database engine. We provide the same experience managing these databases at scale across public cloud, on-premises, and colocation. Let's talk a little bit more about this, why hybrid multi-cloud? Because it's an interesting discussion. It's really about cost-effectively running applications or workloads. I'll start by taking three, I think, commonly used examples to kind of set the stage, and then we get into a little bit more around why this is important. I think the most common example people typically talk about is if you have a primary site in a data center and you want a disaster recovery site. Basically, if the, you know, hypothetical, if you will, meteorite hits your data center, you can fail over to the DR site. This is where public cloud can be a very good solution and 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 site. Especially, it protects 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. If you look at this chart, we have resource consumption on the Y-axis and over time on the X-axis. You have a workload that looks something like this. On average, it doesn't use a lot of resources. For example, on average, maybe it needs, I don't know, four machines worth of resources. 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. 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. It's kind of the opposite. I may very well have the same type of spiky workload, but I have requirements when it comes to typically latency or regulation. 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 maybe microseconds away. In this case, I need to run, obviously, the application on the premises, so next to the machines. Regulatory, so similar, you're having some requirement that says, you know, these databases, these applications need to run in very specific buildings, maybe even in specific vaults inside specific buildings. Obviously, for these two examples, I have location requirements. I need to run these applications and databases on-premises. Some of this is often called the edge loads. Now, what about other workloads that don't fall into these three categories? We have the same type of chart here. Resource consumption on the Y-axis and over time on the X-axis. Think that we're starting a completely new company. We're starting from scratch, which, you know, would mean likely in most circumstances, I have low consumption, so I'm not using a lot of resources. 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. I start in the public cloud. Sorry. Now we have this other Y-axis here on the right, cost per consumed unit. How much does it cost for me to run this consumption per consumed unit, so if you will, you know, memory per hour and CPU per hour and so on. Generally in the public cloud, the cost is pretty significant. There's a good paper I'm sure everyone here has read. It's an Andreessen Horowitz on the Trillion Dollar 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. There 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. Then I can't affect it all that much other than trying to make my workload itself more efficient. This is where I might be able to save money by moving to a colo 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. The servers need to be highly automated. The system has to be easy to use, highly automated. 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. Potentially over time, I increase even more and need to drive down the cost per consumed unit further, and it might be more cost-effective for me to run this workload on-premises. 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. Everyone who had data centers or workloads before the public cloud, obviously have data centers. Now there's a lot of work for people to look at where is it most cost efficient to run. 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. We started our company in Cape Town. In Cape Town, our workload grew into on-premises. What if we're now launching our workload and saying we're going after customers in New York in a new site? We're doing this obviously because of the experience. If you know, Cape Town is quite a way 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. We're starting from scratch, if you will, in New York. Obviously there we would then start on the public cloud, and maybe we start using Amazon Web Services in New York. 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. We move into Azure. Then maybe we acquire an organization in Bangalore, and they already have their workload running on-premises. Through this kind of natural evolution, you end up with a mixed world where some workloads it makes total sense to run in the public cloud, some in a colo, and some on-premises. This is what 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. 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. 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 help with management of their production Oracle and SQL Server databases. I'll play you a little bit of a video here that gives a little bit more information about this case study. There we go. Let's talk about another customer of ours. This is a global retailer that runs data centers all across the world, that were looking to basically make their developers more efficient. 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. They deployed Nutanix Era managing Oracle Database, including Oracle RAC, SQL Server and PostgreSQL. We use Nutanix Era and the Nutanix Cloud Platform. This is specifically a database solution that they choose Nutanix Era for. Another example is a Fortune 50 financial services company. Similarly, this customer was looking for a Database as a Service solution, but their underlying need was about very focused on database administrator efficiency. This customer has a business objective to move off of proprietary databases to open source databases. 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. They choose Nutanix Era to manage PostgreSQL as well as the proprietary databases to deliver a modern database platform. I should say both of these customers or all three of these customers I talked about are in production with Nutanix Era. What about our roadmap? We have three investment areas for Era. The first one is, you know, 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-borne workloads with native cloud support. This is, for example, being able to use Nutanix Era in Azure and say, "Hey, Nutanix Era, please manage these databases that I have already deployed in the Amazon containers on Azure Compute or in, for example, EC2 and EBS on AWS." The final one is investments into the core database of an open source database, maybe PostgreSQL, to make kernel investments basically to provide customers increased performance, scale and so 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. 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 the DBaaS addressable market for Era at $5 billion growing to $8 billion in 2025. We think that's a pretty conservative estimate. In conclusion, Era addresses a growing multi-billion-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 supports both new and already deployed databases. 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. That's it for the presentation. Let's move into Q&A. Thank you, sir. At this time, if you would like to ask a question, simply press star then the number one on your telephone keypad. Again, that's star then the number one in order to ask a question. Your first question comes from the line of Mehdi Hosseini of SIG. Yes, thanks for taking my question, and thanks for the presentation. 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. In that environment, especially, it seems the app developers may not be familiar with a hybrid cloud infrastructure. How will the container-based workload change or impact the database management and impact for a Nutanix product like Era? That's a great question. Thank you. I would say it really doesn't impact. If you think about the slide where I walked through the database trends. Microservices architecture is growing pretty fast, and that's very much a container-driven, if you will, from an application deployment standpoint. At the end of the day, why customers like or developers like to build on containers is because it's easy to deploy, easy to manage, easy to package and so on. 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." If you think about it this way, I deploy my container, and let's say it's the first version of the app. I deploy my container, and at the same time, I issue a call and say, "Give me a database for my container." Database is automatically provisioned. I get the connection string, and I can connect and deploy. They work very much hand in hand, container applications and Database as a Service, including Era. You would run this the same thing applies, you know, 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? Yeah, sure. Sure. Then just as an extension of that question, I imagine most of the new data created is unstructured file object storage. Does that require you to be working more closer with a storage hardware vendors or does the storage have any impact or influence on adoption of Era? Yeah, it's a good question. Not really, I would say. At the end of the day, there's kind of two 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. When it comes to interacting with storage, so this is data stored unstructured in, for example, S3 or on a Nutanix object store, there it's up to the database engine. For example, there are extensions for PostgreSQL such that you can interact with this data. Obviously there are tools available, ETL tools and so on, so that you can move data around. Often use something like Kafka to push information between systems. Got it. Thank you. It's not really something that's kind of related directly to Era. Sure. Thanks much. Thank you. Your next question comes from the line of Aaron Rakers of Wells Fargo. Mr. Rakers, your line is open. Hey, guys. Can you hear me? Yep. Okay, thanks. Sorry about that. I appreciate you guys doing this presentation. I guess a couple of questions from me as well. I mean, you know, as we think about the evolution, you know, of Database as a Service and relative to kind of how you've outlined the TAM, the addressable market opportunity to $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? You know, do you address the full $5 billion of that TAM today? If not, you know, how do we think about the extension of that addressability of that full TAM opportunity? Yeah, that's a good question, Aaron. The way we looked at this is basically this is market that we could address today. Okay. There's, you know, I guess the follow-up question to that would be how, 'cause I believe you mentioned that, you know, further support, you know, database support, you know, et cetera, as that builds out, you know, how do we think about the further extension of that TAM opportunity? Yeah, that'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. At the end, we don't have a good answer of as you add more database engines or certain capabilities, how does that, you know, change the TAM? We're more focused on just making sure we help our customers and win the trust of more customers. Yeah. I appreciate that. I think one of the other questions I had is that, you know, I think last quarter, you know, I think it was like 42% of your deals had at least one of Nutanix's emerging products, and I think that's on a trailing basis, four-quarter average basis. Y ou know, is there any kind of penetration rates, any kind of, you know, adoption rates that you can share with us on how successful Era has been? Yeah, good question. Unfortunately, this is not something that we can address on this, today's call, but you may be able to reach out to Investor Relations for some more information. Okay. Fair enough. Thank you so much. Thank you. Your next question comes from the line of Mike Cikos of Needham & Company. Hi, 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 have 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 build on to the Era solution? Yeah, sure. That's a good question. Look, I would say a lot of our asks is. One of the, I would say, hard things to do with Nutanix Era and part of our differentiation is this support for existing environments. Generally, 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. Then there might be something in there that we don't support yet. We work with the customer to add support for these capabilities. I would say a lot of what we're seeing is where we need to tweak something. It also might be something where, you know, the first couple of workloads that we pick up for the customers, everything fits nicely. They say, "Hey, for this other type of workload we have over here, we need support for this type of thing." Right? I would say it's mostly around those types of things when it comes to additional capabilities. Outside capabilities, it is, "Hey, do you have support for this database engine, right? That is not on your list of five today? That's great. Thanks for that. 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 o r is there a dominant prioritization there o r does it really just run the gamut based on the variety of customers that you're feeding into? Yeah, I think the main thing we hear about where it typically starts is flexibility. Like, 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 I run public cloud. Some might be in areas where I don't want to invest in a core or a data center, so I need to run public cloud. Now I end up with this heterogeneous environment. Even if a specific public cloud I'm running in a region has a database service, now I have, it's 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 costly for me to maintain these different types of configurations." You know, going down this path where they want their DBAs and developers to be efficient, it's very, very helpful to have one pane of glass so that they can have one experience for both deploying and managing production workloads, but also for, you know, development and test, that also tends to be regional with CI/CD pipelines and so on. That's great. I promise this is my last comment here, but it really sounds like 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. I really appreciate the color again. Yep. Yeah, absolutely. Absolutely. Thank you. Thank you. Again, if you would like to ask a question, simply press star then the number one on your telephone keypad now. I'm showing no further questions at this time. Also, in this case, 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.