Is the Modern Data Stack Dead? with dbt Labs CEO Tristan Handy

Well, so I communicated it poorly. I thought I was inviting you onto my podcast, and it turns out that—anyway, here we are. I'm excited to be talking.

I won't say that I coined the term modern data stack. I will say that I think I was a part of the community that started using that term, and I did some of the writing and thinking that led to its popularity. And it became a thing that people frequently said in the 2016 through 2019 period. The way that I experienced it was that I had a decade-plus data career prior to 2012, and that data career felt very different to my data career post-2012.

And the big dividing line there for me was Redshift, and not specifically Redshift, because there have now been other databases that have come out that are like Redshift, but it is the year that the cloud first came for analytics. And the cloud really changes a lot about how you build an analytics product. It changes a lot about how you, as a practitioner, want to go about the work that you do. There's just a lot of assumptions that, when you start off baking the cloud in, you have to reevaluate.

And so in 2016, I was a consultant. I helped people implement, quote-unquote, the modern data stack. And at that point in time, it really meant something. Like, I had a strong preference to use tools like Mode or Looker over a tool like Tableau because Tableau was pre-cloud and it assumed that you were going to be able to—now, it did have some capability to write SQL, but it mostly assumed that you were going to be able to download all the data that you needed to operate on into your local cache, and then it did most of its calculations in memory.

And in the cloud world, people started doing analytics on top of clickstream data, behavioral data, and that just didn't make any sense in Tableau's model of the world. And so tools like Looker and Mode and others that pushed all the compute—I mean, it was cheaper to build a product like that because these tools didn't have to build the caching layer, but it also meant you could do a lot more because you were relying on the database to do more. Anyway, that's where things started out.

And since 2019, I think things have evolved from there. But I do want to defend the idea that when people started using the term modern data stack, there was a there there. Fivetran, dbt, Mode, Looker, et cetera. These are tools that were built around an idea of how data technology should work. And it was and is a good idea.

Yeah, VCs. It's your fault. Well, I think it became clear to enough people, both investors and practitioners and even enterprise buyers, that there was something going on here. And I think that the Snowflake IPO was a big part of this. I mean, the biggest enterprise software IPO of all time. And all of a sudden, that unlocks—I mean, it creates a huge marketing event for this technology ecosystem broadly, but it means that all of a sudden, enterprise buyers take this wave seriously in a way that they hadn't before.

And as a result of that, there was increased demand from buyers, and there was increased interest from investors. And all of a sudden now, I mean, I don't know your portfolio particularly intimately, but my guess is that you probably felt some need also to get exposure to the overall data stack trend. And when you have that belief from the VC side, it was very common for many early-stage VCs to actually go out into big tech companies and find people who worked on X or Y or Z modern data stack-type problems.

Yeah. And then they would just pull them out and say, "We'll give you $5 million, go make this." And there were too many companies created too quickly. And I think that created some, I don't know, unpleasantness in the mouths of the practitioners that had been using this term for a little while. They felt like, "Ah, this is my term." And now they saw all these other people, and it became a marketing buzzword.

Yeah, I mean, I don't like to get too deep into the specifics because people can feel like you're badmouthing them in public. But I will say that I talked to a data catalog vendor a little while ago, and they said, "We're the number six data catalog." And I was just like, "That's not a great place to be in. That's too many data catalogs." Anyway, there's two reasons that I have been thinking a lot about this. One is that my post said, "I don't think the modern data stack is a useful idea anymore."

And the main thing there is that it's not technically descriptive of anything anymore, because what I was just saying about Tableau isn't true anymore. It was true in 2016, but if you haven't adapted to cloud in the data space today, you probably don't exist anymore. Now, maybe there's some legacy big enterprise software-type stuff that is still operating in the bowels of many companies that will kind of be—it'll have a half-life, but it'll never really die. But there's just no world in which Tableau doesn't have a good Snowflake integration and it's still a viable tool.

And in fact, they have gone through this journey just like everybody else has gone through this journey. And so now, the term that was used to describe this difference of pre-cloud and post-cloud, it's not that useful anymore because everybody's post-cloud. I mean, we're eight years on here. But the other thing that I think is very interesting is that there's this idea around the modern data stack: it is a stack. It is many different tools that are all best of breed in the things that they do, and you buy them all together.

And they work together, and they use SQL as a standard operating interface. And that's how you should be doing analytics work, is that you should be buying seven, eight, nine, 10 different products and integrating them all together. And that stopped being true also, because in the macro environment that we're operating in, buyers have less patience for that. They just don't want to operate in that way. That's not to say that there isn't still a stack. I don't believe that we're going back to Oracle and Microsoft in 2000, and everybody's just going to buy all their stuff from one vendor.

If you say, "I want a modern data platform," as a CDO, the right answer is not, "Go out and buy nine different products and integrate them together." That really changes the way that founders in this space have been operating because we had all kind of developed this way of, like, we all had our swim lanes, we had partnerships, we went to market kind of together as a team. And that's still true to a certain extent, but it's less true than it was two years ago.

Yeah. So you mentioned that it's funny that I wrote this and not somebody else. And maybe our incentives as a company are for the modern data stack to be the buzziest of buzzwords forever. I don't know. In writing this post, I tried to thread the needle of saying the way we talk about this, the terms that we use, maybe need to change. But that's not to say that the workflow, the methodology, the tooling is in any way outdated. So there are, I'm sure, many different things that have gone through this wave, but it makes me think of Agile in 2008.

I mean, freaking everybody was talking about Agile. Everyone was so excited about it. You went to get your Scrum Master certification, all this stuff. All that stuff is still very relevant. People still run teams on Agile, but it doesn't blow up the internet anymore. It's just an accepted way that we do work in software engineering. And I feel the same way about one of the trends inside of this: the transition from ETL, extract, transform, load, to ELT, extract, load, and transform.

And that seems, to anyone who's not in data, that might not seem like a big thing, but in fact, it's a really significant transition in the way that data work is done. And I think that that will just be true forever. That's not going anywhere. And so that means that companies like us and companies like Fivetran that are big parts of that, we're not going anywhere. So this, to me, I think that my big conclusion is I sent an email to our head of product marketing.

I was like, hey, can we just say the analytics stack? This is a set of technologies that works together to do analytics, and it kind of tries to get away from the buzzwordy nature of the modern data stack term.

This is the question. This is like my job and George's job at Fivetran, and Ali's job and Frank's job. This is the thing that people are trying to figure out and elbow each other around right now. Really, AWS, Azure, and Google sit at the top of this food chain, and then people like me and George get to figure out what everybody else above us is doing. But here's some things that I would guess.

My guess is that if you sell compute and storage, most of your money is going to come from selling compute and storage because it's a great business model. It's all five of those companies' primary business model. And it's been funny to navigate the partnership there because they have actually—my read, it's not like I know the minds of the folks at Snowflake or Databricks so clearly—but my read is that people like us, people like Fivetran, while we are critical to their success as platforms because we drive a ton of consumption, they don't actually really care about the dollars that we make as businesses because they're so tiny relative to the actual business of compute and storage.

When you talk to the folks at the hyperscalers, they will say, "We're making sure that our solution covers all these different areas." But it's mostly not because we want to compete in these areas. It's mostly because people come to us with RFPs, and we need to be able to check all these boxes. But if the customer has a preference to use X or Y independent product, I mean, they've been navigating this stuff with Elastic or Confluent or whatever for a long time now.

But if their customer comes to them with a preference for a best-of-breed product, they're like, "Hell yeah," because guess what? They're all still running on top of that same cloud infrastructure, driving that same compute and storage.

Yeah. Are you involved in any of the reverse ETL companies?

No, it's very interesting that you mentioned that because that was going to be one of the things that I said. I think one of the potential evolution pathways is for people that were originally—companies that were originally selling to data buyers—to instead sell to a different buyer. And reverse ETL is, I think, a very good example of this. It turns out that the value of a reverse ETL tool does not accrue to the central data team.

It accrues primarily to sales and marketing teams who get the data. So I think there's a lot of those companies that are much more focused on selling to sales and marketing buyers. And that means that, just from this ecosystem standpoint that we were talking about before, we and they are no longer talking to the same buyers. We don't have the same kind of marketing events. We just start to diverge, which is fine. Ultimately, our incentives are for there to be more value created in the data warehouse ecosystem, but there's less direct partnership activity to do there.

There's other paths. I mean, there's the direct acquisition path. I mean, we acquired a company about a year ago called Transform, which broadened our solution.

Yes. Yep. Their technology now powers the dbt Semantic Layer, which we launched in October. My guess is that there will be some more of that. The funny thing is, though, that I think a lot of modern data stack companies had to build—there's the iceberg, which is 10% above the water and you can see it, and then there's 90% below the water. For a data company, the platform is the below-the-water part, and then the functionality that you build on that platform is the 10% at the top.

And a lot of times, different companies in the space have already built their platform. And that ends up making acquisitions harder because you're like, well, I could acquire this other company and get the 10% of their stuff above the water. Because anytime you acquire a company, you've got to combine platforms. It's just a shit ton of work. So you could buy the 10% of the stuff that sits at the top, or you could probably just build that yourself, and it might be faster and cheaper to do that anyway.

So I don't know how much acquisition will happen, but I'm positive that there's going to be a lot of side-to-side kind of people trying to figure out if they can widen their swim lanes.

Well, if what you were trying to do is maximize the multiple that your software company was trading at, then AI is the enemy because all the multiple expansion has moved from modern data stack to AI. But honestly, from my perspective, that's a good thing. You can't build long-lasting progress on top of buzzy press ecosystems and high multiples. So I think that the analytics ecosystem is in a place where, after some kind of resetting over the past year or so, there is sustained progress getting made.

Practitioners are seeing continued forward movement regardless of what layer of the stack you're talking about. And then the question becomes: just like cloud was a huge secular trend that this entire set of technologies was built on, AI is another huge secular trend. What do we do with it? And you could kind of ask that for all the different data workflows, and that's way more time than we have here. But I'll tell you that owning the data transformation experience from end to end, from code authoring to testing to execution to discovery, owning that entire process gives us so many opportunities to inject AI in there.

From the beginning with development, it turns out that there are just some pretty straightforward unlocks on how to make authoring dbt code way more efficient. We've already got internal prototypes working of, "Generate me a model that does this," or, "Generate me tests for this model," or, "Write documentation for it." So we've got all of this stuff that is going to be making its way through at some point.

No, it turns out that the hard problem here is actually, there's enough SQL written in the world, there's enough even dbt code written in the world where just your standard foundation model will do this stuff pretty well, which will be interesting for us to figure out. Can we, over time, scale this stuff with lower cost, whatever? GPT-4 is not as fast as you want and it costs more than you want. But something as stupidly simple as insert formula, and you describe in English text what you want the formula to do, and having it write the regex without you having to go to Stack Overflow and say, "Remind me how to do email splitting regex."

It's just such a big performance accelerator. I think analytics engineering is going to change meaningfully over the next two years. And beyond that, I have no idea what anything is going to look like. So I don't try to predict beyond that.

Well, one of the core beliefs that we have about the profession is that data and software are not that different. And when you're building a production data system, you're building a production software system, which means that we should be taking lessons as a profession from things that software engineers often figured out decades ago. Now, in the case of AI, we're not so far behind because a lot of these capabilities have only existed for the past year or something.

But I don't think that anyone believes that software engineers are going to go away. I think that they are going to get dramatically more efficient. There are so many things, when you try to express an idea as code, that you don't have loaded up into your prefrontal cortex, right? And for a long time, we've used Google and Stack Overflow and constant recompilation until you get a success message as kind of the workflow there. And that, I think, is really what the future looks more like.

You express the thing that you're trying to accomplish, you go in there and you fiddle around with some of the bits that require proprietary knowledge that only lives in your brain, and then you ask the thing to repeatedly recompile itself and fix errors until it gets to a compilable state.

Yeah, okay. So I don't think we have good words for this yet, but we're seeing it happen internally, and anecdotally, I'm hearing it happening at other companies too. One of the first places that we have invested from an AI perspective is making our support team more efficient. We don't have our customers interact directly with AI agents, but we have AI agents that are there to accelerate response times on the part of our support reps. And that has made a massive improvement in support, primarily from an efficiency standpoint.

It's not that previously we were giving terrible responses and now we give good responses. It's that we're now able to take a brand-new support rep and ramp them up in half the time. We are also able to get response times down. And all of that relies on data that lives in our data lake, our data warehouse. dbt has kind of no awareness today that that is happening. And so in some ways, you could say, well, the quote-unquote modern data stack has nothing to do with this.

But in fact, infrastructure is exactly as valuable as the business value that is created on top of that infrastructure. So to a certain extent, the fact that there are people developing AI use cases all over the place that dbt-generated data is powering is very good for us.

I think a lot of times the answer to the question, how much can dbt and Fivetran and other companies in this ecosystem, how much can we help you, is often determined by how functional are the underlying platforms? I mean, in 2016, Redshift was pretty buggy. I mean, very frequently you would get weird compiler errors that there was no help on the internet. It just kind of broke. And that's not true anymore. And the ways that AI functionality show up inside these platforms in kind of a native way, not in a bolted-on way, is going to unlock—I mean, I hope that both Databricks and Snowflake and all the hyperscaler offerings are going to do a great job integrating AI, because then it means that it won't just be AI and ML engineers that have the ability to build these kinds of systems.

What we really want is we want these capabilities to be available to anybody who understands how to think about data.

The big theme for us over the past year was we were starting to see companies deploying dbt at a scale and complexity that previously had not happened. And so they were starting to run into some really unpleasant experiences. They had a hard time. Here's a really stupid one. dbt didn't make it easy to refactor a very large codebase into multiple different projects or modules, and then integrate those using reliable APIs. And it didn't allow you to view that large, complex project in our kind of native visualization tool, which was called dbt Docs, because that was a single-page web app, and too much information in there actually crashed your Chrome tab.

So for the first time, we were like, oh my gosh, we have people that are really pushing the limits here. Let's see if we can solve some of that for them. And so part of that was making it more possible to refactor dbt projects, giving people a kind of first-class tool to visualize dbt projects that scales as far as you want. But then the semantic layer was a big part of that too, one of the kind of, I don't know, Don Quixote-style windmills inside of data forever has been that you get to a meeting and somebody says revenue is this, and somebody else says, no, revenue is this.

And they're like, well, I'm using whatever. And so the conversation becomes about the numbers instead of the business. And this is fundamentally a problem of complexity. It's like too many disparate sources of truth. And the semantic layer, in the same way that a cloud data platform centralizes data so you can all use the same data, centralizes meaning. How do you actually analyze that data to produce a particular business metric? And so, we are one of—there's a very small set of people trying to solve this problem.

It is, how do you separate the semantic layer and the concepts defined in the semantic layer from the BI tool? Because historically, many BI tools have this kind of technology baked in, but you can only really use it inside of that BI tool.

Yeah, right. MicroStrategy way back in the day. But we were talking about AI. One of the most interesting uses of the semantic layer is that it presents a roadmap to the AI to actually analyze the data in your database in a reliable, consistent way. So there's a lot of companies out there that are helping people do analytics on top of their data warehouse using AI, because AI can write SQL. But it turns out that that's kind of a probabilistic way to approach a problem that really should be deterministic.

Like, every time you ask, what's my customer count, you need to get freaking exactly the same answer. And so the semantic layer injected into that AI pipeline can actually help you ask an English-language question, compile it to the same SQL every single time.

What's next?

There's a bunch. I named some of the AI functionality that we're looking into. We've always cared about getting more humans involved in the process of analytics engineering. And there are certain humans where the way that they work with data is much more visual and not with code. And so this year will probably be the year where we start playing around in that space. Now, there are companies that have been doing that for 20 years, and we don't think that all at once, we're going to just make some better mousetrap.

But we think that bringing the analytics engineering workflow to GUI-based workflows is, I think, a big unlock to lots of new people doing this stuff.

Yeah, it historically has been almost a religious topic in the dbt community. But I think the thing is, you have to get no-code, low-code experiences that read and write code so that code can go through a Git PR process and it can have all the same mature stuff built on top of it as any other code. There's other stuff, but those are some of the big things. I am very excited about our nascent data catalog experience because I really care.

Again, this democratization trend. I want everybody in an organization to just know what's out there and then maybe use AI to be able to ask questions of it. And that shouldn't be a tremendously expensive thing. It should be assumed that you have that kind of capability as a company if you've invested in creating these datasets in the first place.

It's something I've been thinking about a lot. I think that everything about being a founder is about context. There are times that you want to be patient, and then there are times that you want to move very fast. And I think, to the extent possible, you almost always want to be patient. And I think that was very, very successful for us for a very long time. We waited a long time to raise any venture funding at all.

We had 1,000 companies using the product before we raised a single cent. And that gives you a ton of power and control. But with all of the market changes over the past, let's say, 18 months, and with the very fast changes in scale of the business, it became very clear very quickly that we needed people around the table that had a different set of experiences. And so if you look today, the only people who are a consistent presence on our executive team from a year ago are me and our CFO, and everybody else around the table is new.

And it's something I'm thinking a lot about right now. There are a lot of strengths that come with that. These folks know way more than I do about operating an at-scale business. I mean, every one of them has operated at a larger scale than we're at now. And so then where are their weak spots, and how do I make sure to correct for those as much as I can? And I think a lot of that has to do with context.

They don't know our space that well. I mean, our team from a year ago, they lived and breathed our space, and we could, as a team, have incredibly deep conversations about this player or that player or the trends or whatever. But now that's not the case. And so I need to figure out how to download that context into everyone's brains as quickly as possible, because I didn't hire for that. That's not what I wanted. But I also need to take seriously that that's now a thing that's on me.

I've got to make sure that I'm adding that context. So I don't think that there's ever one right answer. Should you value this type of team or the other type of team? But we cared so much about operational maturity that I think this was the right call for us.

You waited until the very end to ask a very hard question. I don't know that there's a secret, but the best that I figured out is just be as transparent as you can be. This goes for employees as well as external community members, because generally when you're an open-source company, you hire a lot of people from your open-source community, and then they really care. They care a lot. So in this transition, we've both had to have hard conversations internally, like, hey, there's a set of things that we will need to charge for.

And maybe that will mean some people aren't able to use it. But the alternative is we will not be a successful business and we will go away. Which is kind of silly when you say it out loud. Like, of course that's true. But it's a hard transition for teams to go through. And then in the external community, we've done some things over the past year. We've changed the way that we price. And anytime you change the kind of, not contract, but the agreement between you and a user community, it ruffles feathers.

And it ruffled feathers when we changed pricing. And I have tried to do my best to communicate honestly and openly about that. And by and large, our business as a result has not really had a hiccup. But if you only existed on Twitter or LinkedIn, you would think that our customers deserted us en masse and every single one of them was livid and canceled. But that just didn't happen.

We've gone through Command of the Message-type training with our sales reps. We do much more deal inspection. But also, we've had to focus a lot more on pipeline generation. We have to be really serious about making sure that we know what our pipeline coverage looks like for next quarter because two years ago, we could walk into a quarter with 1x pipeline coverage, and the deals would just show up. And that's not how the world works today.

And that's okay. That's not usually how the world works. It just means that we have to be better.

Thanks for having me. I'll see you.