Confluent, Inc. (CFLT) Earnings Call Transcript & Summary

All right. Let's get started. I am Sanjit Singh, the infrastructure software analyst on the Morgan Stanley software team. We are super happy to have the management team of Confluent. We have CEO, Jay Kreps; CFO, Steffan Tomlinson. And we're going to talk about what I think is a really exciting story. They just went public last year and is putting up pretty exceptional growth. We're going to talk about the opportunity that they're going to go after. Before I do that, let me just get through some disclosures super quick. For important disclosures, please see the Morgan Stanley research disclosure website at www.morganstanley.com/researchdisclosures. If you have any questions, please reach out to your Morgan Stanley sales representative.

And with that, Jay, maybe to sort of frame out this conversation, can you give us the reason why you co-founded and created Kafka number one, and then ultimately Confluent? And what was sort of the key problem that you were solving for back when the team was at LinkedIn?

Yes. So you said the original team that built the open-source and went on to found the company came from LinkedIn. And we built a lot of in-house infrastructure there. And it was mostly -- most of that was originally around storage, different kinds of databases to store data and look it up. It was kind of really about data at rest. And what we found was one of the key problems that I think any company with a strong digital presence has to solve now is how does it all interconnect. You no longer just have these applications that exist as kind of islands unto themselves. Everything is connected, everything has to react to what's happening in the business as it occurs. You need something that plugs all that together. We thought of this as being kind of like the central nervous system in an animal that connects all the parts and allows you to coordinate in real time. And this was something that we didn't really have anything that could act in that way. And we went through a whole process of looking at older technologies and different messaging buses and ETL products and custom solutions, and they just really wasn't anything like that. And we felt that if we had that, that would be really the core of our data architecture. And so that was what motivated the original development. That became a big internal system at LinkedIn. It became something that we released as open-source and became very popular in the kind of Silicon Valley tech crowd. And then we left LinkedIn to really kind of take it out to the rest of the world and turn it into a product and a cloud offering and really trying to make that the architecture for data in every company, where it would flow in real time, where everything would kind of tap into something that would allow you to really harness everything happening in the company. And that was what kind of originally with us.

Right. And when I talk to investors on conference, they're always trying to sort of pattern match it like, what did this look like before and we say like isn't just is like middleware, right? And so you mentioned -- talked about some of the existing alternatives that were available at the time, you mentioned the messaging buses. I was wondering if you could draw the distinction about why those sets of tools were inadequate for the problems that you guys were trying to solve for?

Yes. First of all, I would say this is a problem that has become much more important in the last 20 years because it's no longer the case that the applications exist kind of as pure islands that are disconnected with maybe 1 or 2 areas of data flow. Increasingly, everything has to connect everything else, right? And companies increasingly are driving customer interactions, the actual production and delivery of goods and services through software, which is much more real time and operational and connected. And just across the different trends, whether it's kind of IoT or machine learning, all of that is motivating more data flow. And so this problem has become much more important. And at the same time, the capability of solving it well has gotten much better, like the rise of distributed systems means that you can actually have a layer that connects everything in a company, even a very large company, even across thousands of different data systems. It's actually possible to do that in a way that it really wasn't before. You can't have a single server system that connects everything in a company. It just -- it's not going to be trackable. And so that combination of being able to do it better with the problem becoming much more pressing and important to virtually every company, I think those are kind of the forces that helped propel this. So what's better in this kind of next-generation area of data in motion, there's a few things. First of all, it scales. It can scale across the company and there's companies that have literally trillions of messages or events that are flowing through this kind of central nervous system per day, right, which is actually kind of incredible. Secondly, it's much more general purpose, right? A lot of the older technologies were like, hey, how do you get data out of relational databases into a relational data warehouse? Or how do you get applications to integrate with -- of this type to integrate with one another? Or how do you get custom applications you build to communicate with other custom applications you build? If you think about it, you want all of those things to connect to each other. The SaaS layers in a company need to connect into the same data flows, the custom applications connected into which need to also connect into the other data systems and storage layers. You would have all of that has to come together. And being more general purpose is the second thing. And the third is actually being a more powerful platform. So if you think about databases and the emergence of databases in the world of data at rest, the kind of first layer you got was like a low level file system that you could store your data. Over time, you get these much more powerful ways of managing data, the rise of relational databases and so on. I think a similar thing has happened in this area where you have this idea of stream processing, being able to react to what's happening in a company as it occurs. And it just makes it much easier to use. And that matters a lot, like in financial services, there was early real-time technology for some decades, which was so harder than finicky that would require a very large effort to deploy. It wasn't practical to bring that to bear across a larger suite of problems. And by building kind of general purpose data infrastructure for it, you can make it something that gets used in every real-time application.

And so we've been talking about the evolution of the technology and the architecture. And I think a lot of people are really excited about this opportunity around real-time streaming. Is there a customer example or a use case that sort of represents a north star of what Confluent is trying to enable for customers a certain application or a use case that's really driving outsized operational results for the end customer?

Yes. Look, the usage is incredibly broad, right? It's like databases where there's 1,000 different use cases. I'll give a customer that I think is easy to understand, how they're using it. And there's a great video online for this, if you want to hear it from them instead of for me, which is Instacart. And so what does Instacart need to do, they need to suck in the feed of all the inventory across all these different retailers. And then they need to orchestrate the delivery of that across this very real-time group of people who are doing things and getting things and they have to interact with customers. And then they have to promote that usage and service in a smart way. And it's not that different from the problem in retail, and we have a lot of big retailers using that. It's not that different a lot of the customer interaction problems across even domains like insurance and banking. But I think for whatever reason, that problem is much easier to understand than a lot of the internal's big banks for a bunch of reasons. So what do they need to do? They need to take this real-time feed, they need to have an up to the moment view of what's on the shelf and then they need to intelligently route and orchestrate the collection of that. That's a problem where you can say, hey, this is very much about what's happening in the world right now and continually reacting to that. Very different from the kind of classical store and query problems that the database world was really oriented around.

Okay. And in terms of just the results, I mean, you just completed the fiscal year where revenue growth was 54%. You had 200% growth in cloud. You're just under 3,500 customers. I want to bring the conversation a little bit forward to some of the most recent results, and in fact, this is a good time to bring you to the conversation. In Q4, I think you highlighted a couple of things. 50% of new ACV bookings were Confluent Cloud. Your current RPO growth was really strong at 72%. At the same time, Confluent Cloud quarter-over-quarter, dollar growth was in line with the last quarter. And I think this earnings season is all teaching as is we need to understand the usage models better. I was wondering if you could help us with that. Can you sort of give us an insight into like customer cohort usage trends in Q4? And more broadly, how do we think about the concept of seasonality in these consumption models where growth is growing fast, but there's still some element of seasonality? Can you just sort of speak to that in Q4? And how should we think about that more broadly?

Yes. Well, first off, thank you for having us. We've had a very strong Q4. And when you look at the seasonality patterns, there are really kind of 2 different types of seasonality. There's booking seasonality, where you saw that read through for CRPO and RPO, where we saw accelerating growth rates. And that's really due to end of quarter, end of year buying patterns, typical in any enterprise. As it relates to consumption patterns, we saw 26% quarter-over-quarter growth, 211% year-over-year growth. The dollar-based sequential growth was basically flat to Q3. Part of that was due to a great Q3 sequential and part of that is due to in-quarter bookings does not translate into in-quarter consumption revenue because there is a typical lag time of a couple of quarters or so between when a customer has a cloud ACV booking and it takes a couple of quarters for them to come up the consumption curve. So there's a natural lag effect where most companies with the consumption model have that. So those are some of the dynamics at play. When you look at the number of customers that we have that are greater than $1 million in ARR, 88 customers there. We have over 700 -- call it, 34 customers that have over $100,000 in ARR. Those patterns are very strong. And then the net retention rates, specifically, of our cloud business, has been improving and it's much higher than our overall NRR for the company. And then when you look at the hybrid set of customers, where they're running both Confluent Platform and Confluent Cloud, that has the highest NRR of any cohort. And in a consumption-based model, we think that the cloud-based customers and the hybrid customers will continue to have outsized NRR growth rates. And that gives us confidence around how we are investing in the business and how we're managing growth and profitability.

Super helpful, Steffan. The other topic I wanted to touch on is, again, on like some of the trends that we've seen across the consumption models this quarter. I think Snowflake has in their most recent quarter, they made a decision to pass on some of the price performance improvements with the underlying chip platforms from AWS to their customers. I wanted to see how you think about how Confluent is different from that or maybe it's similar in terms of how do you think about passing on price performance for your end customers? And maybe first, let me just start with how is Confluent Cloud price to begin with? And what maybe some of the distinctions between consumption behaviors from your end customers for Confluent Cloud versus a data warehousing provider or a data analytical provider?

Yes. Let me take that. So it's overall a usage or consumption model, right? You would pay for the data that you would read, write, store or process in the platform. And you could come in and just consume that in a pay-as-you-go model, like you could sign up in the course of this conversation on your credit card to do it or you can lock in a commitment for could be a year, it could be more than a year that commits you to some spend over that time period. And so I think that's shared across a lot of these models, we all kind of modeled this after AWS and the cloud. So that's the overall model. We have felt -- and I think this is a very important nuance of kind of cloud pricing. It's very important to have a model that's priced based on what your outputs are, what you deliver to customers, not based on your inputs. So compute is an input. The output is what they're able to do with it, like, hey, how are we actually consuming this service. Not how much -- how many EC2 nodes we use or whatever to actually provide that. That gives us flexibility to optimize that under the covers. So in general, if we improve the efficiency of our service, you would see improved gross margins for the product, right? We would take that. Now we could choose to pass on some of that savings if we felt that was advantageous or not. But by default, that would come into us and none of our pricing levers are kind of a direct to mark up on cloud instance. And I think that is actually an important thing to get right to kind of set the right boundary with customers in terms of what they're buying.

Makes a lot of sense. So let's talk a little bit about -- we have this mainstream technology in Kafka, and we have Confluent sort of taking cost cuts to sort of at scale cloud native service. And so when we think about sort of the monetization opportunity, what does Confluent Platform and Confluent Cloud together in terms of the proprietary capabilities that you guys are building in? What does that offer customers that they can get with open-source Kafka?

Yes. So we've really focused around 3 pillars that kind of differentiate what we do. The first of these is being cloud native. And that can sound kind of like a buzzword like what do you mean if you're a cloud native and who's cloud native and not. But it's actually quite deep and substantial in terms of what that means. And you can think of this as the difference between like a Teradata and a Snowflake, like at a high level, they're kind of the same. They are these scalable things that use SQL for processing large amounts of data. But that ability to consume it in a flexible way to actually adapt it to what you need as you need it, it really, really matters. And so -- and it's actually a very technically deep problem to do that well. So this means being elastic, being scalable, being API-driven. So it can just be kind of provisioned on the fly. These things are really important to get right for any cloud products. So that's the first area of differentiation is taking this kind of modern data and motion stack and making it available in a cloud native way. The second is really offering a complete platform for data in motion. That includes the ability to process these streams in real time as they occur. It includes all the different connectors that plug into the different systems or applications a company may have without having to write code. It includes capabilities to govern this data as it flows. This is kind of a problem that can seem a little boring, but it's actually incredibly important. If you want to unlock data and share it across an organization, you have to have the capabilities to actually govern that to ensure it's secure, to ensure that you're in compliance with the different regulatory regimes. That is really becoming an essential component of the use of data, and not just like in big banks really in every type of company. Silicon Valley companies used to be very fast in the use of data, that is not the case anymore. This is a project that's happening everywhere. And it goes along naturally with the flow of data. As it moves, those governance needs comes. So that's what it means to offer a complete platform in this space. The third pillar of differentiation is being everywhere. This is really essential. This is a platform that has to be where your applications and data systems are in that region, in that cloud, in that data center. And in all the places your applications are in order to connect them. So if you have applications in AWS in the U.S. East region, we have to have Confluent Cloud there. If you have applications in Azure, we have to have Confluent Cloud there. If you have kind of older systems in your on-premise data centers, we have to have Confluent Platform there. And all of these things have to connect into 1 fabric for data in motion. So streams of data can go between them. And that's actually quite different from a lot of other databases or infrastructure components and that is fundamentally about the exchange of data. That's an incredibly important attribute for our customers. So those are the 3 pillars being cloud native, being complete and being everywhere. And then we've tried to do this in a way that we have strong protection for our IP, right? And this is, I think, kind of become the standard for these next-generation open-source companies, but everything that we offer is protected by a license. That means that somebody else can't take it and offer as a service. So our underlying service that offers the Kafka protocol is substantially differentiated from open-source Kafka and protected by a proprietary license. The connectors and stream processing capabilities, they're protected by a license, which means you can take it and offer it as a service. These are an important kind of defensive moat for us to make sure we can really have the characteristics of a software business as we get to scale and it's not easy to replicate what we've done. And because of that, we have a software stack that solves an incredibly technically difficult problem, is well protected and is strongly differentiated in a kind of emerging new category, which is, I think, what's exciting about it.

And if you think about building out that product road map to help customers operationalize is an important piece of the data infrastructure. I think, in recently months, you launched cluster linking, stream governance. What else is on the product road map that's going to create -- continue to create that separation between the Confluent Cloud capabilities and what you may get in an open-source version?

Yes. Broadly, our focus is on making this easier and easier to consume and kind of moving up the stack, and those 2 things fit together, right? And easier to consume, that's really obvious. This is a kind of paradigm shift that started in the most technical company, and it started there because you had to do a lot of work to actually operate it and plug it into all your different layers. As we make that easier and easier to consume, now you're working with really the kind of large mainstream of companies, even though many of those are just getting started. The easier we make it, the faster they can use it and put it to use in everything they do. That move up the stack is kind of growing into a lot of these use cases and making those easier and easier to do with less and less programming. And that, again, shortens that kind of consumption cycle. It gets more data flowing through this central nervous system. That's kind of our -- broadly speaking, that's our agenda. And there's a ton of opportunities when you look at the different use cases companies have, whether that's building out these real-time data pipelines, whether that's use cases in IoT or in analytics. There's a lot that can be done around that to make those things much, much easier kind of off the shelf as it were rather than having customers have to build on the platform from scratch. And I think it's a very powerful pattern for companies to build on where you can have kind of a horizontal platform that supports thousands of use cases and then build into some of these in a little bit more depth. I think, for example, Twilio did a great job of this with their kind of platform and then kind of higher-level call center use cases and other things on top.

That's something you typically like historically, some of the friction points on new innovations and sort of data infrastructure, data management. It's been the technology to believe in how do we make it consumable for the enterprise that's been a friction point. But now we have like a Confluent Cloud platform that helps operationalize that. I want to talk a little bit about the AWS partnership. And after that, we'll go to the audience and see if they have any questions for the management team. You signed a new 5-year strategic collaboration agreement with AWS, can you talk about how your 2 organizations will be working across both product technology and go-to-market with this new arrangement?

Yes. This is a really important one. externally in the investor community, I think there's a perception that the relationship with the cloud providers is primarily competitive, and there is a competitive aspect to it, like they have competing services. But I would say, broadly, it's actually very cooperative. The big problem that clouds are trying to solve is how do we get use cases into the cloud out of your data center and how do we do that faster and faster and how do we drive consumption across all our different data systems that kind of spin the meter. And we're actually a really important part of that story for them. And I think that's what motivates the kind of partnership with each of the clouds. And we did just have this announcement with AWS. That's both about our economics with them. It's about the kind of go-to-market effort, taking this out to their customers. And it's about product collaboration to make sure that these layers kind of fit together very seamlessly. It's not something wholly new. We've been working with AWS for many years, but it's definitely a significant doubling down on what we were doing on both sides, and we're super excited about it.

Are you seeing any -- and it's probably happened before, but I sort of AWS bringing into customer deals and helping drive your own pipeline.

Yes, absolutely. I mean the -- especially for the customers that are kind of just in that process of moving to the cloud and that's a really important aspect. You want the advice that they get from the data and motion experts and the advice they get from the cloud experts to be in line, and that's very helpful for us. And we sell through the AWS marketplace as we do with the other cloud providers, which kind of helps align this. That way draws down against the customers' commitments. It kind of activates their go-to-market teams to trying to help push this along. And it's a great mechanism, I think, for collaboration.

Excellent. So let's go to the audience and see if there are any questions for the Confluent management team. Just raise your hands and we'll find a microphone for you. Over here on this side. Go ahead, Andrew.

Just 1 question I had. In terms of the uplift that you see in on-prem pricing once you go to the cloud. If you just have like a customer that's running some sort of workload on-prem and then they just take that into the cloud, what's kind of the uplift in pricing that you see from the consumption-based pricing model?

Yes, it's a great question. There's 2 things I would say. So first of all, when we look at cloud adoption, it's more likely to be an expansion than a conversion because this ends up having to be kind of everywhere you have applications. So if you're running on-premise, you're still detected into applications there. Even if you move 1 thing, you now have Confluent Cloud there, but you probably aren't getting rid of Confluent Platform entirely. And that's why we see -- we've talked about this before, the strongest NRR is actually these hybrid customers who are across both. In terms of what happens to an individual use case. It depends, right? The cloud pricing is quite different from the on-premise. On-premise is by nodes, it kind of roughly scales with your usage, but it depends on the utilization rate, right? In the cloud, it is kind of more directly a usage-based model. And so you can imagine for a smaller use case, you might get a better deal in the cloud. For a large use case or kind of broad usage, you would expect that you would be spending probably significantly more in the cloud because it covers both the actual kind of team and operations as well as the underlying infrastructure as well as the software kind of all wrapped into 1 service. So I would say kind of broadly spend goes up with movement to the cloud. In individual cases, it would depend.

So you made a great point in the early part of your conversation about pricing on the basis of ROI, which is the way it should be done. What are the key metrics you use when you talk about output. Like how do you measure the ROI for your customers, how do they measure it? And therefore, as a consequence, how do you define -- how do you think about pricing bubble you have in the industry? That's the first part. Second part is, every cloud vendor with incredible -- especially with the data connection, it's been one of the best kind of selling season of all time. How do you think about next year and the year after? Is there some sort of tension with an organization that man, this is getting to be a very expensive part of our IT budget.

Yes. Yes. So to the second point, I think these kind of usage or consumption models, it is possible to spend too much. And you would certainly hear that from customers where accidentally they have too much spend. But it's extremely transparent where that money goes. It may be complicated, right, in terms of all the usage across all your teams, but it gives you actually a meter to control it. If you compare that to kind of on-prem spend, it's usually very opaque. And you see these big organizations with whole teams dedicated to just trying to figure out where these shared services are consumed and how do we charge back. They never really unlock it and they just end up with this massive spend they can't untangle. So I think the cloud model is much better. Like it's just a much better deal for customers. As with anything that you buy, there's a way to buy it and not get the payback, right? And of course, that will happen in certain instances. But on the whole, it's just much clearer. And you see that with customers. They move faster. We see that in the NRR for our cloud, which is meaningfully higher. And the reason is because we're kind of taking the risk away. If you don't use it, you can kind of pay as you go. You don't have to commit. You commit if you want to commit. It actually takes a lot of the risk in execution and consumption out of the customers' hands. And remind me the first part of the question.

ROI.

Yes, yes, ROI. Okay, that's a complicated -- like true ROI is what's the payout from that project. So like if you're a car company, and this is your connected car initiative, what's the payout from succeeding in your connected cars. I mean, I don't know. So we -- I'm not saying that we attempt to charge based on that and realized value for the customer. All I'm saying is good cloud pricing for cloud infrastructure, it doesn't depend on what type of instance -- what type of cloud instances you use, it's not a cost-plus markup on infrastructure. It should be based on the characteristics of that service that you're providing. Now is that the true ROI on the end project? No, right? But at least I think this is actually very important. Fundamentally, the question is, technology gets better, right? Moore's Law, cloud services get more efficient. Does that help you or does it hurt you, right? With traditional software, it typically hurts you. Like the computers get better, the software, you need fewer nodes to run it on, right? In the cloud, when done correctly, this should actually be a force that helps companies, where their cost structure decreases, what they provide to provide the same unit of output to the customer. And then you have a choice of, hey, we can give that back in lower prices or we can keep it in better margin. And depending on the competitive dynamic, you would expect to see companies do one or the other, right? And so I think it's very important to get that right upfront. It doesn't show up in the short-term in results, but it definitely shows up over the long-term if you've structured that better, and you're not held to just some markup on the underlying cloud infrastructure. That's what I was trying to convey is we have put a lot of thought into that model. Even when it requires more upfront work, even when it's a little bit more abstract to get across the customers, we think it's worth it to have that layer of indirection so that we can have teams working on kind of under the cover improvements that make our business better. There's a lot of depth in cloud infrastructure. So there's a lot of room to make it more efficient, especially because we offer a significant chunk of our stack multi-tenant, which means we can increase utilization by really pooling customers and using usage patterns across to drive efficiency that's totally impossible for any 1 company to do on their own because they don't have those skilled workforce.

Well, with that, I think we're all out of time. Thank you so much for helping us understand the Confluent story.

Thanks so much for having us.