Business Breakdowns
· Alan Tu
[00:00:00] S1: I actually think that analogy is pretty accurate, but there are nuances to that. As a consumer, we are used to this construct of there's a freemium version and then we pay for the premium version. And I think that decision about what goes into the premium version is where the nuance is. Again, going back to enterprise, the typical traditional wisdom is, "Oh, well the average developer that's working in their garage, we like that they can use this technology for free. We really want to monetize the enterprises, and so why don't we monetize the enterprise features?" Things like single sign-on and again, governance and security. That actually makes sense. But the reality is that while it is true that enterprises will pay for some of those additional features, how much will they pay for those additional features? And at the end of the day, those additional features are not the core product. So, going back to your example of the LLM, there are different ways of deciding how to paywall product. I think the analogy here would be to say it's, for certain freemium products, you can use it 10 times, but then the 11th time you have to pay. Or in other situations, there's extra features that you have to pay for, and then you have to go to the premium tier. The closest analogy in the case of Databricks would be actually the better model that is smarter and will give you better answers, you do have to pay for. And so, I actually think that comparison is not a bad one when you think about it through the lens of that core performance of the model, not just these ancillary things that you're paying for.
· Matt Reustle
[00:00:00] S0: That differentiation of, it's not added features, the core thing is actually higher quality, is a meaningful differentiator. And this is something, to your point, that every business has to think through. And I talked to many people who want to roll out a premium tier of something, and extra features are just not that valuable and nobody's going to pay for it. I did want to touch on Databricks, the meaning. What's the origin story to the name?
· Alan Tu
[00:00:00] S1: To draw a contrast, there are a lot of examples of companies that have been formed on the back of a successful open source technology that have basically named their companies the technology. So, whether it's Docker, was a startup that was built to commercialize Docker the technology, you can think of MongoDB is another example. In the case of Databricks, the analogous thing to do would have been to name the company Spark. The reality is that there are a lot of benefits to that because again, Spark was a very well appreciated name. The brand and awareness that Databricks, the company, would have gotten from coming out with the name Spark would have been very beneficial, actually. But the reason why they went with Databricks is because from day one, they always felt like it was going to be more than just Spark. Databricks, the way they thought about it, was that there were going to be many, many bricks that you could all be used to apply around this broader problem around data. A simple idea, but underneath the decision to name it Databricks as opposed to Spark is this reflection of this long-termism of thinking about, what is actually going to set us up to become much more over time.
· Matt Reustle
[00:00:00] S0: I often think about that when companies evolve. There's an enterprise value of a brand that has multiple different products, and you could stick with that core product or you can evolve above it. And it's a little artsy in terms of the way I describe it, but I do think there's something representative of that. And I think it alludes to one of the points that you made early on, which I think is a good thing to bring in now, which is they've evolved in terms of what they offer, and they have many different things under the hood now. And I think this coincides with you and WCM's involvement in the business. So, can you talk a little bit about the evolution of what Databricks offers to customers and how it's evolved past that original state?
· Alan Tu
[00:00:00] S1: Databricks today has truly reached that point of platform. There's sometimes an easy framework of feature, product, platform within enterprise software, and I think Databricks has made strides over the years along that journey. Immediately following the success of commercializing Spark, what the Databricks team did a really good job of after that was recognizing, "Hey, who are we serving in the enterprise? It's the data engineer and data scientists." These are folks that are, after they process the data, they're actually building machine learning models to run some of these predictions and forecasts and recommendation engines, all those use cases we talked about. And there's actually a very complex tool chain to enable that process that Databricks very naturally extended to. And one of the products that they came out with, which ended up being open source again, was called MLflow. And so, this was another product that just extended the value proposition along the same use case for these data engineers and data scientists. They then came out with another product called Delta, which was a first step towards data warehouses, which we'll get into the convergence between Databricks and Snowflake. But Delta was another step in the direction of saying, "Okay, a lot of these use cases for machine learning are for advanced scale-out use cases, but they don't necessarily need to have the same level of performance that allows for what's called transactional use cases." That was actually an important next product as well.
· Matt Reustle
[00:00:00] S0: The transactional use cases, does that have to do with speed?