All right. Thanks, Tyler. Good morning, everyone. Welcome to day two after what I thought was a very informative first day yesterday and thanks for coming back. It's great to see a full room. Oftentimes at these events, the second day you get a bit of a drop-off and it looks like we've got a very similar number of people. So, I am thrilled to moderate this panel. You know, I reached out to these three hoping I'd get one of them. And if we had one, it would have been a huge win. And all three responded favorably. And so, I don't think I've ever shared the stage with such a concentration of entrepreneurs and innovators as we are this morning. So, let me start by thanking the three of you for joining us. I thought we'd just start and maybe Tristan, we can start at your end and just tell the origin story of DBT. We're going to get into the merger with Fivetran and where you see the industry going. But maybe just kind of bring people up to speed on how you came up with the technology and the company.
Yeah, totally. I'll keep the story constrained because I could tell it in 30 minutes. This was primarily a story of me scratching my own itch. The rise of DBT coincided with the move of data infrastructure from on prem to the cloud. And it seemed pretty obvious to me that we needed to change the workflows we were using with data, but nobody really seemed to be putting that into practice. I you know, you could do the anthropology of the data industry for a long time, but it seemed like people were kind of moving their on prem workflows to the cloud without really changing them. And so, I started a consultancy called Fishtown Analytics, which is essentially an experiment to see if I could bring software engineering best practices to the way that data practitioners worked. And DBT was just a necessary component of how I brought those workflows to life. And I honestly didn't have any aspirations of you know, lots and lots of people using it. It ended up being more widely used, more popular than I had anticipated at the outset. And so, we've adapted and grown in order to kind of follow the community.
So, Lucas, we've known each other for a few years. Weights & Biases uses ClickHouse on the back end of your Weave product. You recently merged with Core Weave and that company is absolutely ripping. Did you anticipate that being the outcome when you started Weights & Biases? And maybe bring us back to when you actually came up with the concept in the company.
Sure. So, you know, I've worked in AI my whole career and I did a different company that was a data labeling business. And you know, there you really had to sell into executives and um I felt like that was bad product founder fit. You know, for me, like I really just wanted to spend my time with the researchers. When I sold that company, I just really wanted to make a company that's on the side of the researchers. And at that time, the market was small enough that all the other stuff that sold into AI teams was totally a top-down sale. So, I wanted to build a product and the reason we called it Weights & Biases was I wanted it to be confusing to everyone that's not a researcher. Like Weights & Biases are the part of the neural net. And so, you know, we kind of started with an ICP in mind versus a product. And we kind of just you know, spent some time with our friends at you know, OpenAI and Toyota Labs and just kind of worked with them to make a product that they would like. And I think I also didn't you know, necessarily expect it to be a huge business. I felt like AI was absolutely poised to take off and I felt like being on the side of researchers would be a powerful thing. Um but it was like less of maybe like a drawn-up um you know, venture pitch than um than maybe some other businesses. Actually, a funny story is Tristan um was our analyst. So, I I was like looking for somebody to analyze our data, and I got connected with Tristan who like put this weird DBT tool inside I think we might have must have been like a very early customer.
Yeah, like user 50 or something like that.
Yeah, yeah. And it's funny cuz he wrote I remember he was writing SQL. And I was like I can't even believe the SQL runs. Like he like the weird like SQL stuff that you do, I just wasn't like used to it as like an AI guy who writes like terrible SQL that you probably all um hate, but I actually learned a lot about SQL from having to take over when DBT started to take off and then I SEO got handed back the data analyst role cuz none of my engineers were willing to do it at the time.
We raised money, and our new VCs were like, "You cannot continue to work with Lucas. There's other things you need to be spending your time on."
Well, the good news is with LibreChat, you never need to write SQL again. So, we're all good. Um Guillermo, uh you your story is extraordinarily unique. So, bring us back to when you were a teenager in Argentina, and then kind of bring us current to where you are at Vercel.
Different place. Uh but I'll tell you one of the things that has enabled a lot of my career has been uh deployment velocity. When you have an idea, how quickly can you get a URL for that point-in-time version of that idea? And I'm a big fan of the Charles Munger uh take a simple idea and take it really seriously. So, Vercel has been this idea of just making deployment fast and putting it into the hands of as many people as possible. The plot twist is that people are now encompasses agents. So, a lot of our acceleration in our business has come from agents have this thirst and appetite for deployment. Um so much so that uh the rate of deployment of Vercel has uh three x'd in just a few months, uh which is pretty uh astonishing. And one of the cool things about Vercel is that it sort of it presents this incremental adoption journey with wherever your data lives. So, chapter one of the company was sort of serving a lot of web companies uh that, for example, Under Armour or Porsche need to create an awesome, you know, front end to their data. And we never asked them to migrate their data. We always said, "We can bring this incredible front end capabilities to wherever your data lives." And so, over the years I've been really impressed with how well, you know, these technologies can integrate. And so, super excited to be doing more with ClickHouse. Uh I think the power of agentic infrastructure is one where, you know, for any kind of data set that you have living in the cloud, you can uh create an enormous amounts of value on top um by just using agents.
You know, when when you and I met uh feels like 2 years ago, you articulated ClickHouse in a way that uh most people can't. Um and you kind of talked about where it sits in the in the data ecosystem. Maybe create that vision for the audience and how you're using it currently at Vercel.
Yeah, at Vercel it powers a lot of our data infrastructure because the business has been scaling exponentially, uh and one of our, you know, core values is performance. So, you're going to hear a lot of I'm sure you guys have been talking a lot about performance before I got here. Um but we really needed a data infrastructure that scaled with the speed of our business. One of the key things that Vercel brought to the industry is the popularization of serverless infrastructure. A lot of new software is being created every day. Uh and obviously everyone here is using coding agents. I hear anecdotes from CEOs of very large companies that tell me, "Hey, I didn't know about this Vercel thing, but I'm back to coding." And Claude code told me to use Vercel. And uh so they're rediscovering programming through this. Um but serverless computing has been about scale out, scale up, and scale down. People can create these experiments, these prototypes, and scale them down to zero. And a lot of the access patterns are quite unpredictable. A lot of the things that people like about Vercel is that if you go viral, uh we scale with you. If you uh if your business grows dramatically, for example, we host openai.com, uh we scale with you. And so we need a data infrastructure that scaled with that um uh dramatic acceleration in both the business and the world that we're seeing now. But the other thing that's kind of like peanut butter and jelly is uh I think agents and technologies like Next.js always do best when they can access the data directly. Uh there's no layers of indirection, no slow APIs, no clunky rate limits. Uh and so the technology I think has fit extremely well in this world. Um and um yeah, that's the gist of it.
Uh Tristan, uh you and I met probably five years ago when I was forming the company. And it was around the time that Andreessen Horowitz authored this modern data stack uh that I think many people in the audience have seen. Um and I was so impressed by Tristan I asked if he would invest in the company and he did. So Tristan was one of our early angel investors. Um and so fast forward five years later, like how relevant is that? That was pre-ChatGPT. Um DBT was was very prominent uh in that architectural diagram. How how do you see that changing over the last five years and where is it headed?
The modern data stack um is an idea that had prominence for a little while because it was uh it was the new thing. It was what we needed to bring into existence to like move the frontier forwards of like what you could do in data. And by and large, whether you've adopted those specific logos that were on that slide from Andreessen Horowitz in 2021, you you basically every company has some version of those category boxes. And we all use that infrastructure now whether it's for analytics to which you know maybe you use dashboards, maybe you just use agents to plug into that infrastructure. But but increasingly that same infrastructure is being used to power agents throughout the enterprise. You know there there is one of the most interesting kind of evolutions or like conflicts that's happening right now is actually MCP versus the data lake. And it is really like where are you going to go to hydrate your context? And MCP has obviously exploded and there's a tremendous number of valuable use cases for MCP. But MCP is extremely token hungry. You'll have all these different calls to get data from all kinds of different places and they will fill your context window and they will charge a tremendous number of tokens when one single call to a data lake could get you all of that and save you a tremendous amount of money. So I think that MCP is going to be great for experimentation but we're going to increasingly see as those workloads mature, we move back to the data lake to create efficiency to save a tremendous amount of money.
So if you think about how DBT fit in then and how it fits in now now that you've merged with Fivetran, you know historically DBT drove a lot of workloads towards these cloud data warehouse technologies like Snowflake or Databricks or or ClickHouse. You were an independent company then, you and Fivetran decided to merge the two companies together. These companies are all trying to canvas a broader surface area and expand their TAM and increase revenues. How do you think about these companies today versus how you did even just two years ago?
Let's go five years ago just because I think that it's big enough time span to show the difference. If you look five years ago, the platforms of every one of the major data warehouse data lake providers were fairly simple. They mostly provided compute substrate and data storage solution and you could make requests against them and they performed compute that you couldn't perform locally. They were growing at whatever 200% year over year. As growth rates in that industry have started to tick towards like more normal levels, platforms tend to broaden out. They do more stuff. And so companies that were pure plays and partnered together really well start to step on each other's toes which is a dynamic that I think all of us have experienced before with the cloud providers. Like originally the cloud providers are everyone's best friend and then there's some toe stepping that goes on. And so you know, we're navigating that like everybody else and the thinking around the merger was really that we wanted to come together to provide a more open pluggable version of a data platform versus some of the other solutions in the market that have become kind of insular closed ecosystems.
Okay. Very diplomatic response. Which is fine. Um Lucas, maybe you'll be more provocative. With the relationship that we've had over the past few years and then our decision to acquire LangFuse. Uh-huh. Uh so Weights & Biases has a product called Weave, which is in this kind of broad LLM observability category that we've gotten to know quite well over the past few years as we've been the back end to Weave, we've been the back end to LangChain's LangSmith service and we've been the back end to LangFuse and kind of in Q3 of last year you heard from Mark yesterday we met the LangFuse team and started to kind of romanticize about whether or not we should make an acquisition in this category. And the first thing that I thought of was like how is this going to impact my relationship with Lucas. Um who's also an investor in ClickHouse and has become a friend. And how's he going to respond to this and you know, we were coming from a database company and we're getting into the application layer. And having spent a long time at Salesforce where we ran on Oracle databases, but we competed with Oracle at the application layer, it's quite common. As I think we all know to be an infrastructure provider and also to compete at the application layer. So I kind of got comfortable with the idea. Um and Lucas and I have since talked about what this means and whether or not they'll continue to run on ClickHouse or now that we're you potentially a competitor and you know, you squint hard enough there's a lot of overlap with all these technologies. Maybe help us understand how you you know, A kind of discovered ClickHouse originally, but then bring us current to how do you think about us now as a partner where there's some competitive overlap?
Sure. Um Well, look, I mean I you know I love ClickHouse. I think unlike you didn't ask me to uh invest. I think I begged you to invest. Cuz I thought you know the product is awesome. It really works well for us. You know, we finally actually are getting it in our um original product. It was a little too early to have ClickHouse in it and the you know, there's a lot of performance gain. So, um you know, there's no doubt like you have a great product. I actually like honestly like you know, we didn't like that you acquired a like what we consider to be a direct competitor to one of our, you know, products. I think like LangFuse and Weaviate you know, kind of directly serve the same market. We go head-to-head on a lot of deals, but you know, I feel like in Silicon Valley sometimes people kind of beat around the bush. I appreciate how you were just like, "Look, we bought LangFuse. Like, you know, we're competing with you." And um I I feel like it's, you know, we compete with all the cloud vendors and we also work with them and um I feel like the best product should win. Like, I feel like all the stuff around consolidation. Like, I feel like you know, stupid companies maybe would like buy these tools because they wanted to just have one line item. I think like the companies actually want to buy the best technology, but part of best could be like does it integrate well with the other stuff that I use, right? I mean, like, you know, so I think like you know, it's a battle to make the most useful tools in these markets that people care about and um you know, we're excited to keep competing with you there and like look, we have to work with ClickHouse cuz it's, you know, by far the best database for our purposes. So, um you know, I I um uh where I feel I mean, I feel like competitive with you on on this one front and also willing to work with you on the other uh products.
Awesome. All right, I'm going to take us in a slightly different direction and talk a bit about open source uh and Guillermo or Tristan, if either of you want to start. So, uh ClickHouse, the core database, is governed under an Apache 2 license uh and many of us worked at a company that uh went through this change and had to compete with AWS who both redistributed the database and then forked the technology um even before we started the company, we talked about whether or not we should change the license to something that's uh server-side more restrictive that would prevent the hyperscalers from redistributing it. And we made the decision to uh stay with an Apache 2 license and we've stuck with that decision. And we revisit it every quarter if not more often and we have maintained that position. Do you believe that strategically the right decision historically? If you were in our shoes, would you have changed the license? If you're in our shoes, would you change the license knowing that there's a number of companies that have forked ClickHouse, there's a number of companies that we compete with that are running on ClickHouse because of this very permissive open source license. How should we be thinking about it? You want to go first?
I can start it with, you know, I think for each space is different. Uh in our case it's obvious that we need to be MIT licensed with Next.js. Uh it's paid handsome dividends because by growing the largest possible ecosystem, um we've we're now deeply into the minds of the LLMs. Um I actually tried this out yesterday with all different tier models like, "What is the best full stack web framework?" Next.js I always put gun to their heads like, "Gun to your head, name the best full stack web framework." Next.js
Did you do it in private mode or does it
I do actually. Very important consideration for all of you who are probably wondering, you know, what does the AI think about me? You want to do all of these different analysis. You want to do context-free analysis. You want to ask the model versus the hardness cuz the tokens in the hardness can influence the decision and recommendation of our technology. Um but anyways, like even if I didn't do this exercise, I would know that I'm pretty well represented in the training data set. And I think this is the equivalent of like what I wanted to do before which is that I want as many developers in the world as possible to know about our technology. I believe that education for a web technology should be free and open. So, for us with Next.js it's an obvious no-brainer. And I think the key thing is how you create an infrastructure business that is highly complementary, but decoupled enough that you can give this thing to the broader world and they can make independent businesses on top of it, right? Like we collaborate with all of our competitors in the in the maintenance and integration of Next.js. So, for us pretty obvious. I think now with with agents and LLMs even more obvious that you just want to create the broadest possible open ecosystem platform.
I think that there's been real change in my thinking on this question over the last really over the last like 6 months. Um, the both of us with Next.js and with DBT have experienced a thing where uh a long-running agent, goal-directed agent, can rewrite your open-source thing. Uh, with with, you know, very high degree of fidelity. Uh, you know, it it writes tests. It it it rewrites the the code. Um, you know, it's almost like an interview question at DBT Labs now for engineers. Like, can you rewrite DBT in another programming language with an agent? And the answer is like, yeah, you you can totally do that. And so, uh there it it used to be that there was this spectrum where you proprietary was on one end and permissible licensed open source is on the other end. And there was actually a middle to this spectrum, too, that Elastic was a big part of defining with the Elastic License. Um, and the the Elastic License and the source available licenses were generally there to prevent AWS and the other hyperscalers from uh essentially just like redistributing code that you had you'd written and not adding any value. And I think that that part of the world, because of this ability to essentially rewrite from scratch given an existing source code base. That that part of the world is just going to go away. And so you're going to see the world bifurcate and there's going to be a small number of very widely used permissibly licensed things and then most of the world's going to be pure proprietary. And and you know, I I don't honestly have a big opinion of like is that good or bad, but I I think that's realistically the world that we live in.
Okay. Uh shifting gears again, Guillermo last week when you and I were at an event together, we were talking about this shift in the industry towards a headless experience and how we should be redesigning our products. We saw Salesforce report record earnings yesterday despite this SAS apocalypse that has been reported over the last 6 months. We saw Snowflake report record earnings yesterday as these agents that are hammering these database services are consuming a lot more resources. How are you thinking about it at Vercel?
Yeah, I think it's a fantastic time if you have a consumption-based business model, right? Because the demand from agents of your infrastructure has just increased dramatically. We see it in just how many deployments get made. The headless thing is fascinating because we were pushing for headless for many many years because we wanted to liberate the user experience. We didn't like this monolithic application model where you go to a vendor and you get everything and you're kind of enslaved to the vendor forever. You get the database which you don't really have access to. Yeah, you know, we work with a lot of companies that have like arbitrary rate limits. You have to conform to proprietary APIs and very high-level APIs in some cases. And so things like ClickHouse are incredible for the modern developer because you get ClickHouse, you get a platform like Vercel, and anything is possible. You just tell your agent, give it a prompt, and it'll build however many experiences you want, including some ephemeral experiences, right? We're seeing a lot of customers that are taking to creating applications that are, you know, might be short-lived, medium-sized applications, large applications, etc. Um so, super bullish on headless. Um to your point about MCB, I'm actually I was slightly skeptical about MCB in the beginning. I went on a journey with it. First of all, it's amazing that we have open protocols, and I think as an industry we should continue to double down on open protocols for AI. At Vercel, we maintain the AI SDK, which is sort of a developer experience that sits on top of all of the model providers. We ship the AI Gateway, which allows you to basically access and change models very easily. And I think paired with evaluation tools is a really powerful tool for enterprises to have. But open protocols, I think have been a blessing. We've seen a lot of
Success with companies building agents with MCB. You can host the MCB on Vercel, your data on ClickHouse, and then see magic happen. We've also seen the rise of the CLI, like Salesforce's recent announcement of a CLI. It's a technology from the 1970s, a VT100 terminal, it's so back because it allows agents to easily fetch data and make mutations. But also, we're seeing the proliferation of code mode and being able to grab data by writing JavaScript or TypeScript, running it in a secure sandbox. One key consideration of this headless future is how low-level you go and how you enforce identity, ACLs, audit trails, prevent prompt injection and data exfiltration. Anthropic wrote a blog post about their sandbox thesis and they saw data exfiltration even with domain allow lists. So the key is how to put guardrails around what agents can do and how to govern them.
If you were contracting with one of the large model providers, like OpenAI or Anthropic, and a requirement was that you give them access to your source code, would you do it for your proprietary products?
And what would they do with the source? So, train on it?
Debug. I think my assumption is that source alone will never be a big differentiator for your business. Maybe I'm in disagreement. With the amount of data flowing into these models, value has to move somewhere else. The operational expertise, rigor in software evolution, and the ecosystem you build are the moats, not a snapshot of source code. We've done experiments on automatic translation of large code bases; you can get an okay snapshot at the beginning, but agents are very far from replicating any serious infrastructure. GitHub has been having outages. They have two problems: being in between on-prem and cloud native, and they have a business model issue. If you charge per observability data point, you're happy to absorb queries; if you charge per seat and it costs you a thousand dollars of ClickHouse compute, that's a problem. You need the right business model to succeed in this new world.
You know, I was talking to the CEO of a company we all know. They were on a per seat pricing model. He just got married and I asked when he would start a family. He said, 'Once I move to consumption based model.'
Um, good answer. Per seat pricing, what a bad answer. Hey Lucas, CoreWeave is one of the most misunderstood companies. I got it wrong and many others did. We dismissed it as just reselling Nvidia GPUs, but now it's evident there's so much more. You saw that when you decided to sell your company to them. Talk about how you saw that when the rest didn't, and post-acquisition, what have you observed about this emerging juggernaut?
