There is a new reason to have all your data in one place, which is AI agents need context. If you don't do that, then it's sort of like using Chat GPT
from before Chat GPT was connected to the internet. Postgres, contrary to popular belief, is very old technology. It is not a good database simply
because it was written a long time ago. It has a lot of technical debt. >> Satya has said that there's
going to be the collapse of SAS. Do you think the SAS apocalypse is a thing and we're going to see a massive shift? >> threat is that AI native
companies will just zoom and catch up to the established incumbents and maybe be better. >> Like we'll actually have an HR and that HR team will
onboard AIs as they come. They'll be part of teams, they'll join the slack. And in that world, these aren't
software, that's actually more seats, more consumption of software. And so, do you think that for enterprise agents we're moving more to these you
treat them like humans or do you think that's too far? >> Um >> So, our guest today is George Fraser, who is the CEO of Fivetran. Fivetran announced
the merger with DBT. So, maybe to start, just give a quick overview of what Fivetran does. >> So,
Fivetran, we've been around for a while. We've been around since 2013, had customers since 2015. Uh >> 2013? 10 years? >> exactly. I've been doing
this long enough that the slide about the past state is the same for in my in my own slides is the same slide as the future state from when [laughter]
I started. But what Fivetran does is we help our uh customers get all of their data from all their
systems like Salesforce, NetSuite, all their SAS tools, their own databases into one place. Getting all your data in one place is not a new thing.
Businesses have had the need to do this since you know, filing cabinets. Um The the primary reason historically that people use Fivetran to get all
their data in one place was to do business intelligence, was to build reports about things like what's
your revenue, um what's going on with your sales team, what are we forecasting for this quarter, all those great things. Uh and now there is a new
reason to have all your data in one place, which is if you want to use AI agents in business, AI agents need context. And it turns out that the same
data foundations that work well for business intelligence and reporting with some additions and some
modifications actually can work really well for AI agents as well. >> I mean, talk about a sector of the industry which is under a lot of change
because of AI. And so maybe could you give like a high-level overview of how it is evolving, what are some of the considerations about, you know, the
shifts in data? And in particular, like we're seeing a lot of changes how vendors view their own data,
how the big labs use data. So just talk a bit about what the industry is. >> The thing about data in the context of business is it is always was born
somewhere else. It's always born in systems of record, like Salesforce, like Workday, like SAP. And even if it's your own applications' data, if
you're a software company and you run your own database, the data is born in that database. And since, as
I said, time immemorial, uh businesses have had the need for internal use to centralize a copy of all their data in another location. Uh it doesn't
work to just go and do all of your reporting and ask all your questions in each system individually. Some kinds of questions require you to look
across the entire system. And so that is not new. Um however, uh these AI agents are new and there has been
a in the last year a reaction which really started with the stock market. Um as we saw the SAS apocalypse happen and as we saw the stock prices of all
these systems of record that I'm talking about plummet, um people view them as under threat from AIs. We have seen uh some of these companies start to
think that a great strategy for dealing with AI might be to lock it out. >> [gasps] >> And to uh
say, "Your data is our data now, and you can't do you can't take it elsewhere. Uh and if you want to use AI on it, you have to use the AI tools that
we provide." Uh notably, just a couple weeks ago, SAP announced a new uh API policy that literally said uh all AI agent access was banned except
specifically except in a way specifically approved by SAP. Now, if you're an SAP user, don't panic. This
is just a policy. You have contracts with SAP. Those uh are authoritative as to what you are and are allowed to do, so don't overreact to these policy
memos, but it just shows um how extreme the reaction of some of these companies has been. >> I just want to tease this apart cuz I think there's a lot
of confusion on what exactly is going on, right? So, this is locking down access to the data that
an agent would use instead of an app, right? It's not access to data because you're going to train your own model. >> That's right. >> And do you So,
I'll tell you I >> Very few people are in the business of training their own models. Most people when they want to access their own data in their own
systems of record, even if those systems of record are managed by vendors, um they are using it for
context. They're using it in order to ask and answer questions about what's going on in their business. >> the concern is my SaaS app has less value
as an interface because now the agents can access the data directly and basically perform the same functions the SaaS app was before. Is that the
concern? >> I think there are many concerns. I think that is one of them. >> you actually just straw man
the set of concerns because like this is one of the biggest reactions I've seen in the industry in a very long time, and I'm kind of trying to come to
grips with what the actual worry is. >> I think uh people are worried that their uh that their systems that they've spent many years building will
simply be less valuable in a world where uh their users are no longer humans, but their agents. Um I
think they're worried that um >> But why isn't this just another seat? Like I mean, it seems like you mean arguably this is positive because there's
going to be more consumers of these systems. >> agents don't need as many individual identities. When you have AI agents accessing systems, you really
you don't you just need roles. You don't need You don't need the same granularity of users. Uh if
you have uh many product managers, each will have their own identity in a system. But, if you have a product manager bot, you really might just have
one role that it uses, and it has a It might have a single identity, and yet do the work of hundreds or thousands of people. So, there's not an easy
answer like that. Um Furthermore, these companies have a history of having open APIs. Open APIs are a
good thing. If these companies did not have open APIs, they would have been consigned to the dustbin of legacy SaaS decades ago. I mean, this is a
thing that happened in the '90s, right? The evolution of open APIs. >> Uh and um their customers have been using them and depending on them for
decades. And those same APIs are the primary target of AI agents. So, it is very hard to differentiate uh
whether the users are accessing the APIs in the same way that they always have been, or whether they are accessing them in agentic ways that may
substitute for human workflows. >> I'm going to keep poking on this cuz I still think it's not a real concern. So, let me make another straw man
argument. So, let's say you had opened up all your APIs in the '90s, which is the case. Like, why couldn't I
just write a procedural um uh app, which is my own version of the SaaS, and therefore also disintermediate your SaaS? Like, why why are agents somehow
different than me just writing my own software or my own dashboard? >> Maybe they're not. Um this may all be kind of much ado about nothing. I I think
it's foolish for them to close down their APIs. So, you're putting me in a weird position. >> I do
think that >> I'm trying to [laughter] trying to defend a position that I think is stupid. >> Yeah, yeah, yeah, I agree. Yeah. >> So, I think, you
know, a lot of these threats are not new. Like, well, maybe they'll use programmatic access and thereby use seats use less seats. Maybe they'll move
some functionality to their own interfaces. I mean, that is a real thing that has been happening for a
wanted to let you know, I I'm old enough to remember these discussions in the '90s. Like, the rhetoric was exactly the same. The reaction was
exactly We could never open up APIs, we can never like have them do this cuz they're going to disintermediate us. And it just turns out that if you're
buying into a business process, like the operational flow of something, like that is set up by the
company that you're buying it from. Like, Salesforce knows how to run a Salesforce. And so, whether it's an agent that's consuming it or SaaS, I would
argue that like there's still the value there. >> I completely agree, and I will point out another piece of evidence for that claim, which is if you
look at the budgets of real companies that are heavy consumers of software, they spend 5 to 10% of
head count on software. >> Yeah. >> Software costs are immaterial in the grand scheme of things. Software, compared to everything else a typical
business spends money on, is so cheap. The idea that they're going to use AI to value engineer the number of seats they have on Slack or something is
ridiculous. >> Yes. >> Uh they're going to use AI to go make their business work better in whatever it is
that they do. >> cool. [laughter] They're They're not trying to take that, you know, 5% software spend and turn it into four and a half. That is not
the highest best use of a >> I I mean I mean famously all the big AI labs including I mean and you know Andreessen Horowitz and we're all very heavy
users of AI like still use these SaaS tools. And so like four years into this we don't have a lot of
evidence that like >> As do we, as do OpenAI and Anthropic. >> Exactly. >> Who are both Fivetran customers and we replicate lots of data from these
various SaaS tools on their behalf into their data lakes. So uh if they're still using them >> [laughter] >> Yeah, yeah, right. >> uh is it Do we
really think the company of the future is not going to be >> Right, right. But one thing we can both agree
on is this is this is bad for customers, right? Like this kind of >> It is locking down the APIs is bad for customers. So maybe talk through like a
and why it's bad which may just be obvious and then B kind of your recommendation for how to manage that like assuming that this is happening industry
wide. >> So the reason it's bad for customers anytime vendors put up walls and try to um regulate
data access is that uh you need to have all your data in one place in order to do meaningful reporting, in order to understand is what the heck is
going on in your business and in order for AI agents to work in the context of business. If you don't do that, then it's sort of like using ChatGPT
from before ChatGPT was connected to the internet. >> Yeah. >> Uh if you used it back then you remember
it used to have this knowledge cut off and it would tell you I can only answer questions that happened by, you know, in my training window. >> ago. >>
Yeah, six months ago was when I was trained. I don't know anything after that because I'm not connected to the internet. That is what using today's
AI's is like if you're using them in a business context and they don't have access to your business
data. And uh so it's very important for every company who wants to do things with data to create their own data platform where they have a copy of all
of their own data and it's being kept continuously up to date. And anytime vendors start putting up barriers, it just makes it harder to get that
done. And the customers will still do it. They'll just work around these barriers at great cost and
complexity. >> You know, one of my favorite things that you've done as a company to educate the customers on this is this benchmark. Um can you maybe
talk through what that is? >> Well, we have a website. Is that what you're talking about open data infrastructure? >> Open data infrastructure.com. >>
have It's a benchmark. Like it does scoring, right? >> Yeah, so we score The list is growing. We're
trying to make it as long as possible. We score uh as many vendors as we've been able to catalog so far on their data access policies. So we basically
score them on whether they try to charge egress charges, they try to make you pay for getting your own data out, whether they um uh whether they make
it impossible to get a complete copy of your data cuz some vendors will do that or they'll make it
just very difficult. Um and whether they whether they have terms of use restrictions on accessing your own data. So we have there's a big grid on
there and it rates them >> Are you are you comfortable saying who the worst offenders are? >> Well, or should just point people to >> Just go to the
website and read it. It's all very fact-based and very well evidenced. I mean, the worst offenders
historically have been SAP has always been really bad. >> even when I was running a large business, I mean, that was always >> It's interesting
because they were getting better and I've sensed in the last few years that there's sort of two camps within SAP. One of whom who regards it as it's
the customer's data. The customer's got to be able to do what they need to do with their own data. And then
there's sort of the old guard who views it as SAP's data and you'll do with it what we tell you to. And uh and then, you know, historically Salesforce
has been really good with the exception of Slack where they're terrible. >> Yeah, yeah, I know. [laughter] >> But uh they started to get squirrely
about this. So, it's it's a moving target. I am hopeful that this is merely a brief flirtation with
closed data by most of these vendors and they will realize this is not a good idea that they are at war with their own customers and it's not even
going to work anyway and we will go back to the trend towards ever more openness. >> So, you just answered my next question but I'm asking anyways,
which is like do you feel like this is just like a a repeat of the open data API? It'll resolve quickly
like, you know, we always kind of go through this soul searching and then we'll resolve back to where we were, which is like open data's the right
thing. >> I do think >> Do you think that's the path or do you think it's different this time? >> Yes, I think it will be the same. That's my
prediction. It will be the same path as vendors will discover that they cannot provide inside their own
platform a solution to every data problem that their customers have because they are simply so diverse and instead they simply create a mechanism for
the customers to replicate it to their to their data platform of choice and do with it what they will. And even if they charge fees for that, it's not
the end of the world. On opendatainfrastructure.com, you really get yellow for charging fees, you
know. It's only red when you try to actually block it. At the end of the day, if you want to have a little toll, that's not the end of the world. The
problem is when you start when you start actually blocking it. >> Like there is no option. >> And and saying, "Oh, if you want to do anything with
data, you have to come use my tools inside my walled garden." which never works because all the rest of
your data is not in that walled garden and it's not going to be. And uh and you can never create enough tools to support all the different things
customers want to do with data. >> You know, this is probably related to this notion of of you know, or this belief in data gravity. And I mean one
thing that I've loved working with you over the years is like you're exceedingly smart and you're
exceedingly contrarian. >> [laughter] >> It's just so fun to like kind of you know, watch your opinions diffuse and more often right than wrong. And
one thing you have said is that data gravity is either overrated or not real. So [laughter] do you think that like a you know, do you stand by the
statement and B do you think that this is driving people to like try to do these wall gardens? >> Uh I I
think data gravity is completely fake. Uh I am [laughter] the only person who thinks this. >> You're the only person that says >> If you want if you
want to see evidence >> describe what data gravity means. Like people use the term a lot but like I don't think they understand the implications. >>
Data gravity is the idea that uh business data is so large that it's very expensive to move around
because of egress charges uh of cloud vendors. Um and uh if you want to see and that therefore it's very important that you choose a physical region
in the world where all your data's going to live in a specific region of a specific cloud and then you build all of your data consuming services in
that same location. Or you can partition >> of egress fees? >> Well, this is this is A's version. The
term data gravity does get used to mean multiple things. This is this is one particular >> Yeah. >> incarnation of the idea of data gravity and this
is the one that I am saying is fake. That egress charges are so important. >> Yeah. >> Um and if you want to see evidence against this, come look at
the networking dashboard of Fivetran's various AWS and GCP accounts. You will be astonished despite
replicating uh huge data sets for uh thousands of companies, and we have uh 7,000 customers of size and thousands more little ones. Um The the amount
of data being moved at any given time is tiny. And the reason is that we're doing change data capture. You can have a huge data set, but if you just
replicate the changes, the changes are always much smaller than people think. >> Right. Right. >> And
I I think that a lot of this idea of data gravity came from dumb data pipelines that people wrote where they would copy their entire company's data
sets >> Yeah. >> out of their database every day, once a day at midnight. And so they just had this crazy read amplification. You know, they were just
repeatedly copying the same data over and over and it gave them the impression that they had so much
data, but they really don't. >> May- maybe a good argument not to roll your own on these things anyways. >> Yes. >> Yeah. >> Yes. This is what happens
when people roll their own data pipelines is uh they fall back on these patterns that are easy to get right. Like that pattern I just described, it's
extremely easy to get a correct replica just by copying it all over and over. Um but very expensive
to operate in the long run. >> Maybe before we leave this topic, so let's say there's a CIO listening to this right now and the CIO is like, "Oh, how
do I navigate these kind of uncertain 3 to 6 months? Like what kind of leverage do I have with these SaaS vendors as they're closing things off?" Do
you have any sort of guidance for them? >> Yeah. I think >> Uh >> number one, you should insist on
having a copy of all of your own company data in a data lake that you control. >> Uh >> don't let go of that for any vendor. >> Um >> You have a lot
of leverage. >> Uh >> These vendors actually have a lot of obligations to let you do that. >> Uh >> The reason why they get away with >> Um >>
blocking people is simply because people don't fight. >> Uh >> So pick fights. >> Yeah. >> And >> Uh >>
write it into your >> Um >> into your If you have big contracts with vendors and you're redlining your MSAs, >> Uh >> write language >> Uh >>
guaranteeing your own data access into those MSAs. >> Are you are you seeing those show up now? I actually >> We have I hadn't even considered that.
We have model language on opendatainfrastructure.com that we recommend you incorporate into your MSAs. Uh
and even if you don't get it, just by asking for it, you are sending uh a signal. So, you know, if you if it's a $10,000 contract, you don't don't do
it. Uh >> [laughter] >> but if you're if you're uh signing, you know, 500k, million-dollar contracts, insist on data access in your MSA. Uh and you
will find uh surprisingly often that you get it. >> I'm going to talk to you a little bit about agents
now. So, I feel like we've kind of gone through multiple phases already in agents. So, the first one is they're just purely treated as software.
They're like um it was almost like search plus. Like, take all your data, put it into a data lake, and then you have an LLM that has access to it. And
then we go to that, and it's like enterprise search all over again. And then we went to like the agent
like open claw. And then that model was like a personal agent, but it kind of like was part of you. So, you'd give it access to your email, and you
would give it access to like your API keys, and give it access to your accounts. So, it was like part of you, an extension of you. Now we're seeing >>
I I actually set up open claw. >> That's great. I use nano claw. >> Uh well, I use set up open claw,
and then I turned off of it onto nano claw >> Yeah. >> because it's such a monstrous piece of over complex software. And then I actually turned off
nano claw onto nano bot, which is what I've stuck with. But I use it to manage my tennis team. But it has its own identity. >> Okay. So, I'm going to
say I'm going to say okay. >> It has its own email. >> this is I think we've all come to this
conclusion, which is like I don't want it having access to my email. >> Yeah. >> I want it So, I also I also have the Mac mini. I run the actually now
I'm working with somebody like build a harness, but like they're all the same, right? It's >> I run it on a VM. >> Yeah, perfect. Yeah. >> its own
WhatsApp number, its own email address. >> So, I got it on phone number, its own email address, and
then you don't know. Now as we think about A16Z, we're actually thinking about like you know, why don't why don't we just treat all these agents like
this? Like we'll actually have an HR. >> [laughter] >> And that HR team will onboard AIs as they come. They will train them. They will show them the
access to the documents that you need. They'll be part of teams. They'll join the Slack. You know,
just like humans do. And in that world, and we touched on this a little bit before, but in that world, these aren't software. That's actually more
seats, more consumption of software. And so do you think that for enterprise agents we're moving more to these you treat them like humans, or do you
think that's too far? >> Uh I think it is a um intermediate form. I think the reason this works well is
because you can slot it in to the existing workflows uh without having to refactor the whole universe. >> Yes. >> Uh so in my example of my agent that
manages my USTA tennis team uh it can email with the players, it can go to the USTA website, check the schedule, make lineups, check availability. Um
and it works well having its own identity because it can slot into all of these existing workflows
that were designed for humans. At Fivetran, we have an AI agent that uh helps uh respond to support tickets. Uh that goes and inspects the logs,
inspects the code. It uses all the context that we centralize with Fivetran >> Yeah. >> uh to find out what is going on with this customer. Um what
might be the solution to this problem, and it drafts responses. And right now, it slots into the system a
lot like a person would. But we are working on making the whole thing just a closed-loop pure AI system where it will only have one identity. There
will just be the uh the connector troubleshooter Borg hive mind. >> And there And there may be, but I mean let me give the argument for the multiple.
So so why do I use a Mac mini for my agent, right? I mean there's a couple reasons. One of them is so
it connects iMessage because there's no programmatic way to access iMessage and so like, you know, it's it has a desktop. Another one is like
everybody's moving headless like Salesforce is doing their headless thing and there's a headless browsers. Uh but it turns out just to talk about
browsers like if you have a headless browser all of the anti-scraping software kicks in and then like it's not
as functional. So it's actually much better to just give it a fully functional version of Safari. So you could argue that the interfaces that have
evolved over the last 30 years to deal with unpredictable users that know how to use computers is the the UIs we have today and actually the simplest
thing to do rather than try to rewrite all of that stuff is just to give these agents that have been
trained on human data access to full end-to-end systems. >> I don't know, the systems that I've worked on the browser use has never been necessary.
Browser use has a big cost which is very slow. >> Mhm. >> Uh and it consumes a lot of tokens. >> Yes. >> Uh and I have found that uh in my tennis
example the USTA website does not have any anti-scraping provisions and >> Well, you're not trying to
you're not trying to like read from LinkedIn or Zillow. >> [laughter] >> Try that if you >> Yes. Uh uh and so I'm just using uh I'm using just uh like
Python uh browser automation. Uh I'm actually using Selenium and then I'm actually there's actually a skill that emits uh just exactly what you want
to know so that so that the agent is not reading HTML and consuming all those tokens all the time.
And then at Fivetran, for example, um we are working right now on a Salesforce administration agent to um to integrate to basically do continuous
integration of small changes into our Salesforce um which is very labor-intensive right now. And it also does not use browser automation because the
Salesforce CLI we found does everything we need to do. We'll use browser automation if we need to if we
come to something that can't be done with a Salesforce CLI, but to their credit the Salesforce CLI is quite comprehensive. Pretty much anything you
can do in the UI you can do with a CLI command and the agent seemed to already know how to use it. >> So can I do a $1 bet with you for when we're on
this podcast in 5 years? >> Sure. >> I think the majority of use for agents in 5 years is going to be
the same interfaces that humans are using. Uh just because it's the long tail of integration has already been solved and like all the protections and
all the sharing and everything else. >> And would you say the majority would be through APIs that are kind of more of a more of a traditional computer
software so >> they'll just hit the APIs. >> Yeah. What do you think about things like uh you know
these technologies that mediate now like MCP which have emerged to kind of try and solve that problem. Do you think there's a future for those or do
you think that those just give way to like strict tool API usage? >> You know in theory it seems like they're an unnecessary layer uh because these
agents are great at calling APIs and calling command line tools. So why bother having this other layer?
In practice when you sit down and actually try to build systems um MCPs do solve important problems particularly authentication >> Yeah. >> and um
just like discoverability of what's available. So even though you can say kind of from first principles that maybe they shouldn't exist when you
actually sit down and write a a real system that's accessing context uh you almost always end up sticking an
MCP server into it. >> And this is authorization authentication authorization and discoverability like the fact that these things exist. >> Yeah and
there's just also a lot of little affordances in the AI tools that are built around MCP like uh um user granting authorization for specific tasks are
done at the tool level in MCPs. And that's just a rule that's been baked into the harnesses that ends
up working well for a lot of situations. It also works badly in some situations. But the the tools on the consuming side have started to grow around
MCP, and thus even if maybe theoretically you don't need it, I think in practice it's it's taking it's taken hold. >> Cuz the thing that I find so
strange about this is like even the tool use itself, like you could argue that like as smarter models
come out, they could build better tools anyways. And so sometimes I wonder if like an agent should just be the most minimal thing ever. Like it
manages like durable state, it manages its compute, and then, you know, you run like whatever, like the Anthropic SDK or the OpenAI SDK, and then you
just tell it to build its own tools. Like, you know, build your connection to this. >> Well, that's how
Nano That's how Nano claw >> No, it's exactly how it works right now. But you could argue that like there's so much money being poured into these
foundational models, like tens of billions of dollars, maybe come hundreds of billions. So like the most intelligent thing at any point on the planet
is one of these models. So why would you use an old tool if it could build a better tool? >> Yeah, so I
mean, Nano claw, for those who don't know, is a personal AI agent, sort of like Open Claw, except the way it works is you fork the repo when you start
up. >> Yeah. >> And then you just sort of vibe coded into whatever you want. >> Yeah, whatever you want, exactly. >> And the problem I encountered is
it sort of went awry. And I didn't really want to go and troubleshoot all of the details. >> I
debugged Nano claw. I debugged Nano [laughter] claw. >> I I I I I I >> I curse. I'm in there like actually going through the code and stuff. >> I
spent enough time debugging Nano claw that I was like, I want something that has more separation of concerns, where there's sort of an agent over here
that has an API, and it works the way it works, and then I just write like skills and stuff on top of
that. Ironically, even when I did that, I ended up having to add things to Nano bot because like it couldn't differentiate WhatsApp group messages
from DMs. And I think I actually have a PR against Nano bot because of that. Uh so I sort of ended up back in the same place a little bit. But I take
your point. Like if they get smart enough, they may uh you know, they may just build their own
intermediate abstractions as needed. >> Yeah, yeah, that's right. That's you go. Um just to you going to maybe wrap this bit up. Um I mean, you know,
Satya has said that there's going to be the collapse of SaaS. And you know, we know Databricks is trying to rebuild a lot of SaaS on top of their
platform. I mean, they've been very public about that. So do you think we're going to see like a massive
Like do you think the SaaS apocalypse is a thing or we're going to see a massive shift? Or and like, you know, it's going to be agents and it's going
to be on new types of infrastructure that they run or do you think that, you know, SaaS is fine, the market's overblown, Satya is, you know, wrong. >>
Well, uh to give credit to the public markets, I I think that they are accurately I mean, whether
the magnitude is right, I cannot say, but the direction is right. There's a lot more uncertainty embedded in all these SaaS companies, including my
own. That than there was a year ago. Uh and that's reflected in the changing and the and the declining prices. But I I don't think it's for this I
don't really buy into this reason that all these SaaS categories are going to disappear and be replaced
with five coded software. I think there will be some, but I think the bigger threat is simply new companies coming along. It is just so much easier to
write software now that AI native companies will just zoom and catch up to uh to the established incumbents and maybe be better in some ways. >> You
know, so interesting. I mean, you just you just mentioned that about Fivetran, but if you look
across the companies we work with that are traditional companies, and I wouldn't I actually would not include you in that, but I mean, listen, you
know, like both of the labs are your primary customers. Um but if you look at it across the traditional companies like you don't actually see in the
data that they're slowing down. Like FiveTran's doing great. It's actually the company's accelerating.
And so, how do you reconcile this high-risk concern that you just voiced with the actual the business? Is it more just kind of existential angst or >>
it's like X risk. You know, some some new way of doing what you do comes along that's dramatically better. And this will happen to some companies. >>
I know, of course it will, right? But >> Uh and more >> years into this at this point. You know, I
don't know. I just feel like you do you you can't derive this from the data as far as I can tell. And like maybe it's coming. Or or maybe >> not even
really in the public company data. >> No, it's not. No. Yeah, across the board it's >> It's when you start to see like less than one net dollar
retention, then you know it's it's uh it's come. >> Yeah, yeah, yeah, for sure. Yeah. And maybe it will.
Maybe it's in the future. But like we've been having this conversation. I still I remember I actually remember when I was when you put in the call and
it was a year ago or so and you're like, "But you know, the AI stuff is like really real and you know, like you can kind of code connectors with it
pretty good and it's pretty good and it's coming." But that was actually quite a while ago when you
put in that call and the company's done fantastic since then. So, it could be the case that like rather than someone trying to redo an existing
company that, you know, has figured out like a long tail of stuff, they'll go work on different problems that are more suitable. >> So, we have, you
know, in our particular case, we have been trying ourselves to use AIs to build uh data replication
connectors, which is the core of what uh for years since GPT-3. Uh and they continue to improve in terms of what they can put out. They still uh do
not discover this long tail of complexity. Uh it is it is it really surprises people how difficult it is just to make an accurate copy of a system and
keep it up to date. Uh and so and and now we are actually starting to see new capabilities inside
Fivetran to push the bounds of quality particularly quality even further like completeness of coverage of the sources and the correctness of
replication. You can imagine how you can use AIs to do that more comprehensively than you ever could with human beings. And so I think in addition to
the sort of you know the AI threat is getting closer but it's still it's still I think a ways away from what
we do. We're actually starting to see the opportunity pull us forward. So we're we're starting to get better at our own core business by leveraging AI
internally in extremely non-obvious ways that I don't think anyone else has discovered yet. So >> you talk to those or is that trade secret? >> Uh
well it's it's um you know at the end of the day uh what's going on inside Fivetran is just this crazy
mass troubleshooting effort that never ends. >> Wait that sounds like every startup ever. >> Well we have it is but it's it's the breadth of it is
much larger for us cuz we have 750 connectors to different systems of record everything from Oracle to SAP to Qualtrics to you name it. They all have
different idiosyncrasies and you only discover these idiosyncrasies when real customers bump into them.
And they show up as performance problems correctness problems and failures. And you know the way we have always solved it is I I always like to say
the trick is there's no trick. It's just a lot of effort behind the scenes and it's kind of an economic trick. We only have to fix every bug once and
then every customer who uses that connector benefits from it. But you can imagine how you can use AI
coding agents which are basically an infinite supply of junior engineers, that is a particularly valuable tool for this kind of problem. >> Yeah. >>
And the the details of putting that into practice turn out to be quite tricky. Um, but we've really, especially the last couple months, started to see
it work uh and started to see um you know, like improvements at scale. Many many small improvements
start the we've seen the flood start to come. And I think you'll see uh the quality and reliability of Fivetran take get another leap this year
because of that. >> Awesome. You know, you're in this very unique vantage point uh because you um have the big labs as customers like OpenAI and
Anthropic are customers. Um, so, you know, they are AI native, they're at the forefront. Do they use Fivetran
differently than traditional enterprises or anything that the enterprise can learn from that? >> No, they're use cases are very typical. They use
Fivetran to replicate data from lots of different systems of record into a a centralized data lake. Um, and they do analytics with that. They feed
that as contacts into their own internal AI workflows. Uh, so, they have built data foundations that look
very much like um the data foundations of many other companies. Uh, the data the systems uh at Anthropic, one of the people who helped set them up was
a consultant who had set up Fivetran and DBT at many other companies. >> Yeah. >> Uh, so, they're their data their data platforms look very typical.
And I think um this is a very important message. If you are thinking about data foundations for AI,
do not make the mistake of thinking you need to build some exotic new system as a data foundation for AI. The right data foundation for AI is probably
the one you already have. If you have a reasonably modern uh data platform, something like Snowflake Databricks, or BigQuery or maybe even you have
transitioned to an Iceberg data lake with those compute systems running on top. Um that is a great
foundation for your context for AI as well. >> You know, there used to be this idea and again, we've touched on and in the context of FiveTran, but
more broadly there's this idea that AI commoditizes infrastructure broadly, right? And so the idea was like, well, it can write anything. Um the
opposite seems to be true. More software is being written than ever before. The software is actually pretty
buggy. It needs kind of stable infrastructure below it, you know, and so most infrastructure companies have seen a lift as a result of this. You know,
in your in your sense, is this transitory? Like the eventual AI consumes infrastructure is coming or do you actually I mean, let me just give you my
my quick view on this, which is um building rock-solid software that you can operate for long
periods of time is just not what AI is best at and you're probably better spent, you know, focusing it on other things, but is my view blinkered in
like how powerful it's going to get over time? >> Uh no one knows how powerful uh it will get over time. I mean, the nice thing about that is that if
it gets sufficiently powerful, all these questions become sort of moot cuz we'll just be living in a
post-scarcity world. Uh but uh I think if we look at the present day, I think it is mostly true that AIs are just creating more demand for
infrastructure and not commoditizing it at all. You can think of infrastructure as having layers and at the bottom are like data centers and then um
you know, you go to cloud vendors like AWS and then you have um systems like Convex, sort of serverless
platforms that try to make the cloud vendors easier and then you even have um you know, systems that sit at a higher level of abstraction than that,
which could include uh you know, Databricks, a lot of their business is hosting notebooks, right? Uh I think that last layer is the one that uh is
threatened by AI. Because AI is quite good at navigating slightly more complicated infrastructure. So,
if you have an AI agent, maybe you don't really need that very uh most user-friendly layer. You can drop down to the next one and use that. >> Yeah. I
mean, you could argue the consumption layer is up for grabs, which also happened with the internet, right? Like you kind of went to different places
to go and do things. Like it changed the UI. Like it changes a bunch of stuff. But like the core
infrastructure stays in place, right? Like you still have operating systems, you still have chips, you still have databases. And like you did they
kind of evolve over time rather than they get >> Yeah, and maybe you peel one layer or maybe you peel three. You're not going to peel it all the way
back down to glass. >> Yeah, that's right. Let's talk on let me actually just do a quick time check here
just cuz I just didn't enjoy talking to you so much we just talk forever. Um okay. Let's uh let's uh change um topics a bit to the DBT merger. Yeah.
So, um so you acquired Census in 2025 and then Tabular Data and SQL Mesh uh and then you signed with DBT Labs. And so, I mean, this has always been a
space that's been relatively acquisitive, but I would say for the new style companies uh Fivetran has
been the most acquisitive. So, maybe can you talk through the strategy and the plan? Or is this was this ad hoc? Is there some grand strategy? >>
Well, I I am the child of investment bankers, so maybe I'm just realizing my destiny. >> Not not just investment bankers. PE, right? >> Uh well, my
brother did PE and my cousin and a bunch of other people in my family. >> There you go. >> But I'm not my
parents. My mother was a commercial banker and my dad was a M&A investment. >> Oh, there you go. Okay, M&A wealth. >> Yeah, yeah. But in the But in
the in the M&A world. >> Okay, I see. I see. But anyways, I I you know, listen, for a startup and having watched you do it is actually been very
impressive to watch you run the strategy. >> Well, but seriously, um it was not something we set out to do.
Um I Fivetran does not have a corp dev function. Uh I felt with every single >> I never really thought about that. That's true. >> Yeah. Yeah, I I've
always felt that any acquisition or merger um and the first big one was really HVR. >> HVR, yeah. I remember that very well. >> Um it should feel like
it's for these unique reasons and it feels like it's the last one you're ever going to do. And it's
not going to be the last one you ever do, but the reasons to do it should be really, really strong. >> Yeah. >> Uh you shouldn't go looking for this.
Um nonetheless, we have found these strong reasons several times. I I think the DBT one is a great fit. Uh these are two products that have
historically almost always been used together. Uh and uh they they kind of go together. Fivetran is the tool
that gets all your data in one place. DBT is the tool that you use to organize it and turn it into a model that reflects the particular details of
your business. And then that is what feeds into all of the data consumers. >> You know, you've actually said publicly that DBT is going to be one of
the biggest beneficiary of coding agents. Can you kind of pencil that out a bit? >> Yeah. Yeah, so
there's this great >> know what that means, so. >> Uh there Well, I think I think there's going to be way more usage of DBT. >> I I see. >> coding
agents are going to write tons of DBT models. >> told you that we're we're actually already seeing that. I mean, that's >> Yeah, and and it's going to
be a great beneficiary. There there is this great um uh quote from Dijkstra, I think, which is uh >>
Dijkstra's algorithm, Dijkstra. >> that Yeah, that uh computer code should be seen as a means of communication between humans and only incidentally as
an execution format for computers. Uh, and nowhere is that more true than in SQL queries in DBT projects. Uh, it is a great way to express these are
the rules of data at my company. >> Yeah. >> Um, and even if it's being written by AIs, you still
want to have that artifact that is a is a executable documentation of how your business works. >> All right, so you have the pleasure of uh, being the
CEO of a relatively large company uh, during the AI wave. You've gotten to back to writing coding, which a lot of us have. Um, uh, you're running a
lot of experiments like you mentioned experiments your nanocloud experiment. Though you're now
running what? >> Nanobot. >> Nanobot. That's right. Yeah, yeah. Um, so how much of this is you know, George the the scientist the techie versus like
you actually do this like pragmatically useful for the CEO of a a large company? >> I don't know if it's a good idea. I just can't resist. Uh, and
coding agents are great for CEOs who want to write code on the side because they work sort of
asynchronously. >> [laughter] >> So you can you can have a lot of things spinning in the background. I I have I have a lot of projects going right
now. Um, >> Can you can you name them? I mean, >> Uh, I I mean I have things I am just doing as hobbies like um, uh, like the system for managing my
tennis team. I'm working on a little on a on a tennis statistics machine vision app. Uh, but then I have
many things at Fivetran. They're all experimental proof of concepts that I share with people and we talk about. Um, there's a um, a potential like
nano data lake catalog that I have going that attempts to if you when you use data lakes you have to adopt this additional service uh, called a
catalog and it's the answer to the question could we make the catalog invisible? So, that's an example. Um
I'm working on just for the hell of it uh a from-scratch uh classic OLTP SQL database. >> What? >> I I think that's I think there is an Well, it's
crazy. It's crazy, right? But it the whole point of the project is No. No. It's not distributed. Uh >> Yeah. >> It it it's it's what it attempts to do
is to be uh like SQLite except S3 is the backing store >> Oh, that's cool. >> That's a great idea. >>
for it. Um because when you build AI workflows, you have this need for like zillions of tiny databases uh and it's a proof of concept. It's mostly an
exploration of like, could you with sufficient AI coding just take on something absolutely ridiculous? If you're hearing this and you want to work on
this and you are an expert in databases >> GitHub? >> I don't. I don't. But if you want to work on
this, come to Come come talk to me and maybe you can come do this at Five Tran. You don't even have to use my proof of concept. I think there's
actually a real opportunity right at this moment. I I really lament that we're sort of stuck with Postgres forever. Postgres, contrary to popular
belief, is very old technology. It is not a good database. Um undergraduates writing class projects write
better databases than Postgres. Not because the people who built Postgres were not smart, but simply because it was written a long time ago. It has a
lot of technical debt. Uh and I really think the world should create a new operational database rather than just endlessly repackaging uh Postgres.
But >> That's an amazing take. I have >> [laughter] >> Yeah, that's another one of my controversial
takes. Postgres is bad, actually. I I should also say >> No, no, no, even better. Like a an undergrad in a database course is writing better databases
than >> Well, under >> In in many respects, the storage engine that you would write as an undergraduate in a database course is better than Postgres's
heap storage engine. The Postgres's storage engine I don't think you The creators of The people
who promote it today would admit it is not a good design. Uh it's been patched up in a lot of ways. Uh but the Postgres the Postgres storage engine >>
I'm not I'm not going to digress on this. I have a million questions up. But I But I I will say just like this conversation, you ever find this
becomes a bit of a distraction like it is so dazzling and so fun as well >> Yes. >> these things and
you're like, "Oh, you know, I should be like doing that one-on-one, but instead I'm here in my >> No, I think about that a lot. And I make You know,
you got to you got to like keep it at bay. Cuz it it is like you know, there is a danger of cloud psychosis, which is a term that I I love. But you
can just get sucked in. >> Yeah. >> But you know, I have a lot of time. I don't have any kids, so I
have a lot of time. >> [laughter] >> I mean, people with children will say that's like it's like having a whole 'nother self. >> [laughter] >> Yeah.
Yes. >> got >> across me. And I do. Yeah, yeah. I mean, one thing I do I do really appreciate about you as an executive as this you as a founder is
you're actually quite reflective. And one of the mental exercises that you've been doing as long as
I've known you is like pretending if you were a new CEO brought in by the board to fix Fivetran, like what would you immediately unwind? Which by the
way always happens when you bring in a CEO. And I know you kind of do this mental exercise. So, is there anything recently that you thought like,
"Boy, if I was brought in to like run things, I would change this." >> Many things. I That's an exercise
I I do regularly. I'm trying to think of a recent example. I mean, a not-so-recent example is I did do some things to try to simplify pricing. I I
think those have been successful. They were painful for the company because they mostly cut prices for small customers. >> Yeah. >> Um another
exercise I do is I ask myself what should other CEOs do? It's hard It's a It's a trick to get to do things
that are big and scary. >> Yeah, yeah. >> Uh so in the DBT merger, you know, when I was reflecting on that, uh on whether that was a thing we should
seriously consider, one of the tricks I use is I ask myself what should what should Tristan read or do. Tristan read is the CEO of Snowplow >> Oh,
yeah, yeah. >> who we've worked with for a long time. It's a good mental exercise. >> Oh, yeah, that's
right. >> I just go do that. >> [laughter] >> And and that was like a clear answer in my mind uh was like merge with DBT, absolutely. >> Yeah, yeah.
By that by that framework. Even though it seems very big and scary when you imagine is this a good idea for someone else, uh then you can kind of
get there. >> Yeah. May- maybe just kind of a softball cliche final question, um but you know, you do
have like the unique perspective of managing a CEO during this transition. So first, what are you most kind of existentially worried about? And
second, what are you most excited about? >> Well, I think the thing I'm most worried about is just, you know, that the uh at some point the coding
agents will get so good at writing connectors that people will just shift to DIY. Um I think that's a real
threat uh to Fivetran. I think some different businesses are more or less threatened by like maybe the customers will just write code it themselves.
That is a thing I worry about with Fivetran. And um we uh we will we will find a way to thrive in that world if we get there, and we um we will
provide the tools that you use to do that if that indeed becomes possible, even if it comes at a short-term
cost to ourselves. Um but I do worry a lot about that. Uh and then the biggest opportunity um I think is that AI is just a whole new set of things to
do with data. The need for getting all your data in one place, organizing it, um is so much greater now than ever before. Um I think that there's a
whole set of tools that people are going to need on the other side of that data platform, and what I
think we and especially we and DBT are perfectly positioned to provide them. >> Amazing. Well, it's always a pleasure to have you, George. Thanks for coming. >> Good to see you, Martin.