Business Breakdowns
· 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?
· Alan Tu, Matt Reustle
[00:00:00] S1: Speed is part of it. There's a concept in the database world called ACID. It's an acronym, A-C-I-D. The actual letters stand for Atomicity, Consistency, Isolation, and Durability, which is a long way of saying that there are certain workloads that require a certain level of guarantees around the quality and integrity of the data. So, when for a lot of operational analytical workloads, for example, just taking it back to a data scientist that's running an analysis about how many shirts we should stock in inventory, it actually isn't that important that all the data underneath it is perfectly in sync such that if one of the data sources is tweaked by a little bit, that totally throws off the analysis. But there are other workloads for which you need to have that guarantee that there are no inconsistencies in the data, that there isn't one person is changing a piece of data here which has follow-on effects there. So, that is another segment of the market when you think about the types of workloads that databases can address. That was an important extension and evolution of Databricks. And so, they then came out with a product called Delta, which was a first step towards addressing these ACID requirements. And one other really interesting thing about Databricks is that I think one of their core competencies is marketing. There's a funny story where when they came out with Delta, in order to explain to folks what Delta was, they gave out free T-shirts that said, "Delta is Spark on ACID." [00:00:00] S0: That's amazing.
· Alan Tu
[00:00:00] S1: So, that was another, again, extension of Databricks introducing another product, logical extension of their existing products, but also commercializing it well and understanding how to market the product to the broader community. And then from there, to your question, there in my view was a very pivotal moment a couple years ago when we got involved at WCM and investing in Databricks, which was when, following Delta, Databricks started to show the ability to address traditional data warehouse workloads, which is the end part of the ACID journey that we discussed. And that was very important because up until that point, you could largely say that the products that Databricks had built were all addressing again that core persona of the data engineer and the data scientist. But the types of folks that actually engage with the data warehouse are more traditional data analysts. So, these are folks that typically use SQL to run queries against more structured data, versus data scientists running Python and building machine learning models against unstructured data. But because Databricks had built the foundation and logically laddered their way to the data warehouse, they were then able to come out with a SQL product that was more directly competitive with one of their peers, public company Snowflake. That was, to me, an incredible proof point because they already deserved a lot of credit for expanding from a single product to multi-product, but then to expand further to multi-persona, for lack of a better term, was just a tremendous TAM expansion in its own, right, but also a demonstration that there's so much that goes on underneath that to enable the success of a product like that. And so, that was around a couple years ago they introduced their data warehouse product. Earlier this year, they announced that's on pace to be a billion dollars in revenue, which is just an incredible amount of scale for a new product. And that to me really started to demonstrate this idea of Databricks is successfully becoming a true platform.
· Matt Reustle
[00:00:00] S0: Yeah, it's very interesting to hear. And we had discussions before this conversation about your involvement in the business, and I'm very interested in late-stage investors and private businesses and what insights they glean. And when you painted that picture to me of that evolution into a true platform, it checked out to me just in terms of, "Okay, this was a unique moment. They've evolved." On that point about competition, at the highest level, if I'm an organization using Databricks, am I potentially also using Snowflake? Am I using multiples? Is it not necessarily winner-takes-all market? But how does that work just in terms of how much dominance there is with customers when they choose one versus the other?
· Alan Tu, Matt Reustle
[00:00:00] S1: The reality of the market is that there tends to be multiple vendors that enterprises will use. And actually, I think Databricks has contributed towards a trend of enabling more types of tools for more types of workloads. Now, Databricks we believe will then be able to come out with more products to address those different workloads. But to answer your question, it is very much the case that you see customers using both Databricks and Snowflake, for example. If you roll back the clock to that core use case that Databricks addressed early on around data processing, it's actually a very classic situation where an enterprise might use Databricks first to process the data and then store that data in a Snowflake data warehouse. Snowflake has started to try to move upstream to do more data processing, and Databricks has moved downstream to do more of the data warehouse. But that can give you a sense of the way that these tools can live together within the same company. [00:00:00] S0: I will acknowledge, this is very easy for me to say from the cheap seats, but it would seem as though moving from the processing, the unstructured world, into the warehousing, more structured world, might be a smoother evolution than vice versa. Because in my mind, that unstructured world is a very complicated solution that was being offered, and not that data warehousing is not, but do you think that's a fair representation? And definitely feel free to push back on that assumption.