What Happens When Billions of AI Agents Hit Your Database? (Andy Pavlo)

Hey, Matt, how are you doing, man?

We never thought Wu-Tang Clan. Do we have to talk about Larry Ellison? I mean, it's a little early to come out of the gate, although he is hilarious because he's like the supervillain of databases. He owns a Hawaiian island.

I will say my contract with ClickHouse does allow me to talk about Larry Ellison. I made sure that was in writing.

Vector databases, although you're right that, in terms of being in the zeitgeist of AI and databases, probably two years ago is when RAG and vector databases came into play. But the vector databases themselves, a lot of them were around since 2016. It's just now that the use for them became obvious because you can use them to enhance and improve agents doing things. So I think the vector database market is interesting because they were early in the space, but they were really pushing the idea that you want to do this approximate similarity search on vectors or embeddings instead of doing an exact search that database systems have traditionally done.

And this helps, too, when you're dealing with natural language, where the semantics of maybe what you're trying to look for or query against, you can't precisely define. Like, find me all the albums from artists in New York City that talk about doing certain kinds of activities. Right? It's very hard to define exactly what that is. And the magic of approximate nearest neighbor search, or these vector embedding searches in a vector database, is that you can look up things based on the semantics of the thing you're looking for, and it just sort of works out that way because you're not trying to do exact keyword searches.

So when ChatGPT blew up in 2023, when everyone became aware that this is now a technology that exists, the vector databases were in the right position at the right time because they could augment and improve these chatbots. But the moat, if you will, wasn't that big because at the end of the day, it's just an index. And within a year, pretty much every single database vendor had their own vector index. And now it's become sort of standard table stakes.

Every database system that we're using has its own vector index. Now, it doesn't say that the vector databases can't do certain things better than what the traditional data system could do. It's just now that everyone has that basic functionality. So I think that you still use vector searches to enhance and improve the chatbots or the agents. Now, you don't need to have a specialized one database that can only do that.

Or the databases created by agents was larger than everything else.

The creation of a database. And then there's branching of an existing database. And I think the Databricks metric was about the branches being created by agents. So what does branching mean? Branching is when you have a database and you want to make a sort of copy-on-write snapshot of that database and have it look like two unique databases. And the reason why you want to do that is you could have your production database that's running your business, your application, where all your system-of-record changes are going into.

But then you want to have either a human developer or an agent be able to start trying out new things, make changes to the application, and you want them to operate on the real database. Because oftentimes, traditionally, you would make copies of the database or have a smaller version of the database, like a sample of what already exists there, because it's just too expensive to copy things around. So you have, like, a staging or development database, and then you would hopefully apply your changes to the production database, and you hope that once you go to the larger scale, everything works out.

So what branching allows you to do is it allows you to make a snapshot of the real database, have all the changes that you make go to this snapshot, and not affect the production database. And once you're okay with the changes you've made, maybe not necessarily for the data, but usually for the schema or the application code, once you know you've vetted it on the snapshot, then you can put it live in the production database. So now, with these agents, people are spinning up these coding agents to write new features, write new parts of their application.

It's not something humans are doing anymore. And now you want to have these agents vet their changes on a copy of the database, so you can create branches on these things. Often it just shows up when you're running testing as well. A lot of the time, the branches are created by PRs running in GitHub Actions or testing things like that. So you want to run your test code on a copy of the database rather than the live one.

So this branching capability is mostly being used for development. People are using agents to write a lot of new code, and so you want them to run in their own sandbox. You make a snapshot of the database. So the branching capability is super useful for that.

Yeah. So certainly, if you say, "Create a database from scratch," then yes, your coding agent—you give it the prompt, say, "A billing application does this"—then yes, it will create a database right away. But most of the branches or new databases, if you want to call it that, are being created for this development. But yes, the agents can now create databases. For better or worse, you can have them drop databases. People often get in trouble with this because it's doing things that they shouldn't be doing.

Almost every year, there's some story.

It's the Wild West for people that don't know the history of databases. For years, we've had the capabilities to make sure people don't do things they shouldn't be doing, stupid things like dropping a data table or deleting records. Those controls exist. It's just everyone wants to reinvent the wheel, and people learn the hard way of just doing what's already been done in the past.

Guardrails, right? It's like you wouldn't have a new child, like a new toddler, and just not put up the guardrails so they don't fall down the stairs or put their finger in the socket, right? It's the same kind of thing for these agents. Think of them as toddlers, a little more sophisticated than that, but you don't want them to run wild or do whatever they want on a database. Now you could sit and babysit it and just say, "Approve, approve, approve," like in Claude Code or whatever.

But of course then you can't scale and have hundreds of agents trying to do things at the same time. So you want to set up the right permissions and controls so that they can't go into the production database and drop tables that they shouldn't be. And likewise, you don't want them to go read things that maybe you necessarily wouldn't want them to read as well. So if you have the right guardrails in place, and through branching or whatever means you want to create these sandboxes, you can avoid disasters. Like every month there's a story where someone lost their production database because the agent deleted something.

Did something they shouldn't do. With the right guardrails in place, you can assure that these things don't happen. People get lazy, they use the same password across the entire company or organization, and then they give the same password to the agent, and now wonder why the agent started doing things they shouldn't do.

Yeah, so maybe the larger question is: do agents, at least now, behave differently than humans? Other than just being able to run 24/7, I haven't seen anything that would suggest the fact that they don't develop software the same way or interact with data the same way that humans do. Right? At the end of the day, the data system only sort of exposes so many different capabilities, and that's the API that gets exposed to you. So as long as you can constrain those things for humans using those APIs, you could do the same thing for agents. But the level of sophistication of what those guardrails could be beyond just, like, don't run delete or update on a table.

The level of sophistication really matters on what sort of product you're using. And I will say this is something where I like open-source databases, but the enterprise commercial legacy databases, if you will, they've already done all this for humans in the past. So they have a lot of the protection mechanisms you would want. Just expose that to agents as well.

And how they interact with databases? I got to be honest, I don't know the answer. It's still early to say. I mean, the volume, of course, because agents are running 24/7 in a way that humans cannot. But we've seen similar patterns in databases before where we've seen increases in volume. And I would sort of say there's been three eras, and we're now in the fourth one. The first one was at the very beginning of just having a database in general, that you can now start putting in information and run transactions and store things for your organization in a way you couldn't before when it was all pencil and paper.

So probably like the '70s and '80s, there was an obvious increase in the volume of traffic you needed to handle in a database. But in that era, it was mostly humans interacting with the database at their jobs, because no one would go home and no one had a computer necessarily in the '80s, certainly not the level we have now. So that was sort of, say, one era where we had an increase in volume. Then in the 1990s, early 2000s, the internet comes along, and now everyone can interact with databases through websites and through the internet.

At home. So you saw a sort of spike in volume at that level. Then the next era would be mobile phones. And now everyone at any given time has various apps running. They can interact with websites, then put things and read things from databases. So I would say that would be the third era. So now agents, I think, is the next chapter in the story, where now every human not only has a cell phone, but they also can have maybe hundreds of agents interacting on their behalf that are then interacting, reading, writing data from a database.

At the end of the day, when you name an application, it's always going to be backed by a database. So it's going to cause the application to read and write information, read and write data. So I don't think we're there yet, because every human obviously doesn't have hundreds of agents running 24/7. But what's interesting about what could happen is, when you think of a human interacting with their cell phone or their laptop on a website or an application, they're kind of really only doing it when they're awake, right?

You can only do one thing at a time. Like, I can't sit with my one cell phone in one hand and a laptop in the other hand and do things at the same time. You're kind of only limited to what the human can actually do. But you can imagine a world where these agents are just 24/7, always running and acting as if they were humans interacting with things. So the volume would increase quite significantly. And then furthermore, unlike a web app, they're usually going to be— you could argue, how's this agent really different than IoT devices or cell phones now?

Like IoT devices, you're just streaming inserts of, here's the measurements I'm getting. With cell phone apps, you're usually reading data, right? But you can imagine these agents do more complex operations where it is a combination of reads and writes, and then that makes the traffic more interesting. So I think there's going to be potentially a 10 to 100x increase in volume and the number of queries that are going to hit databases. And I don't think we're there at that level yet, but I definitely have heard from my friends in industry that they're seeing the sort of thing we've seen.

We've seen the same thing at ClickHouse. What I don't know yet, though, is whether the sophistication of the interactions are more sophisticated or less than what humans can currently do. I've seen some people say, well, the type of queries that the agent would generate, or SQL queries the agent would generate, is actually more shallow because it's just trying to maybe read one or two tables at a time, try to figure out what's in there, versus if someone uses a dashboard or a BI tool like Tableau or MicroStrategy, you may be doing very complex joins across different tables.

I don't know yet whether agents are at that level or whether they're kind of going at it, really trying to read data against the database in more simple terms. So your question is, are agents going to change things? I think yes, right now, definitely in volume. And I think that's going to increase even further. And of course, now when the agents are running, they're generating their own telemetry, so that you have to store that and make sense of that.

And that's another challenge. But in terms of whether the actual patterns of what they're doing, how different is that yet? That remains to be seen. This is something I'm trying to research as well.

What is a file system? It's a database, right? Everything's a database, right? You have a directory of a bunch of Excel files. That's a database, right? You have a notebook, a pencil and paper. That's a database. When my daughter was like three, we were trying to teach her the importance of databases. And I would make her write down—well, we'd do it together—we'd write down the temperature every day in a little lined notebook.

And she'd close it and go, "Commit," to save the data. That's a database, right?

It really comes down to what the form of the input or the context you want to provide to your agents is. And as far as I know, it's all human-readable text, right? So whether or not that human-readable text comes from a bunch of JSON files you have in your directory, or it's extracted from a database system that can then convert that into the correct endpoint form, at the end of the day, it doesn't matter.

I think there's obviously advantages and safety guarantees you can get when you use a database management system that can protect data. SQLite is famous for this. Why would you want to use a file system and try to manage whether you're writing things correctly and safely, and that you can make multiple changes and commit this, versus just SQLite? SQLite just does it, right? So at the end of the day, everybody should be putting everything in a database system, right? Even some file systems, like WinFS, underneath the covers, it's a database system, right?

At the end of the day, if you need to share state across multiple machines or instances of these agents, whether they're running on the same box or not, again, a database management system provides that capability that you could have multiple readers reading the shared state, right? I haven't seen anything where the agent, as part of its memory lookup, is pushing down filters and things like that into the database. Usually that's provided as part of the context. Again, this goes back to the RAG or the vector database stuff. You provide the context based on what you've already looked up against your memory in the database files or the database itself.

So again, from my understanding, the API for the input of the context is just human-readable text. And whether that comes from a file system or a database system, it doesn't matter. But the database system provides certain guarantees and luxuries, if you will, that a file system can't provide. And shared state is one of them across multiple agents.

I mean, you're asking in terms of using it for memory, or having an agent choose one particular database system over another when they build an application?

So maybe the latter. The models are trained on what people are writing about. And so, if I say I'm building a new application, chances are it's probably going to recommend Postgres at this point.

Yeah. And I will say, I can't say who, I've had two database companies ask me how to get their database to be recommended first by an agent over Postgres. And I was like, first of all, that's not what I do. That's not research. And two, don't talk to me. Go talk to the guys building the models because that's clearly something that they could have sway in. It's basically like SEO. How do you get the agent to learn, like, hey, I should use my database X instead of Postgres?

So this is very much a first-world problem, and I'm not trying to humblebrag, but one problem I do have is when I ask questions about databases, it cites me back to myself because all my course materials—

Yes. Well, no, because, say, when I was teaching database courses, I would say, "Show me—I want to learn about data systems that do this version of an index, like a B+ tree or whatever." And I would say, "So now I have to say, I already know which ones do do this, so show me the ones that don't do this." And then I have to say also, "Don't cite me. Don't cite Andy Pavlo or anyone from Carnegie Mellon."

But then the problem is that our course—

ChatGPT, no. Yeah, ChatGPT actually says, like, "I know who you are." It says—I've said something like that. But Perplexity doesn't do this. But the problem is also, since all our course material is open source, anyone can just take and use it. So then it says, "Okay, well, you can't cite Carnegie Mellon University. Let me cite another university." But it's my slides being used at another course. So I gotta be very specific about what not to return back to me.

So I think that, to your original question, for OLTP, I haven't tried this in a while, but usually it spits back, "Hey, we should use Postgres." Unless you say something very specific, like, "I'm going to run on embedded devices," then it'll say use DuckDB or SQLite or something like that. Or, "I only care about key values," and it'll come back and say, like, use RocksDB. But for OLTP, it almost always says use Postgres.

And then it might recommend, like, "Do you want a hosted version or not?" if you have further chats. For OLAP, I'd be interested to see if there's any kind of ranking on this. It's actually not a bad idea. Maybe somebody's already done this. That one, it definitely would come back, and maybe you have to refine it further and say, like, "My workload looks like this, my data looks like this." And then I think it can give a more nuanced answer.

I haven't tried this for about a year or so, but I've definitely seen before it'll say, "Oh, do you have any money? Yes? Okay, you could use Snowflake or Databricks. Do you have no money? Okay, you could use DuckDB." Or, "Do you want to run on-prem? You could use ClickHouse," things like that. So then your second question was about agents?

I mean, I have strong opinions about graph databases. I don't think you need one. I have not seen any benchmarks that show native graph databases outperform relational database systems when those relational systems have the right constructs in SQL or the API so that you can do graph traversal all on the server side and not go back and forth. The SQL standard in 2023 added support for property graph queries. Oracle supports it.

Postgres was supposed to support it this year. It's coming out in Postgres 19, but I think it got delayed or rolled back. I don't know why. But anyway, that's beside the point. No, I think that the context layer, again, depending on the requirements of how many agents you have, whether you have shared state or not across multiple agents, Postgres often should be the first choice for many of these things. For OLTP. If you're doing analytics, that's a whole other story.

Yes.

So text-to-SQL, it's like natural language to SQL. So this is something people have been trying to do since the '70s, right? And every so often there's maybe some kind of breakthrough in natural language processing. People say, okay, now finally it can happen, right? It hasn't happened except for LLMs. I've been skeptical of the academic literature and the recent publications on various frameworks that do text-to-SQL because oftentimes the benchmarks are showing SPIDER and a couple other ones. Like, these are well-known benchmarks that the models are trained on.

So, of course it's going to regurgitate the correct answer. I actually was talking to somebody from a very large bank yesterday who said they now have a text-to-SQL interface. But in the initial implementation of it, they were using something off the shelf, and then they further refined it a little bit further in-house. But it was about 60% accuracy, meaning the LLM or the agent could produce the right SQL query, produce the right answer 60% of the time.

And that's roughly what I think I've seen before in some other reporting. 99.5%, which is insane. I think that's a viable thing now if you invest the time to have the right semantic layer and the context information you need, so the agent has enough information on how to derive the right SQL query from the question you're asking. I think, again, that's a large bank with infinite money, and they can pull this off.

I think if you just download something now, a random person will find that these existing tools are not going to be at that level of proficiency and accuracy. But it doesn't mean we can't get there, right? So now in terms of MCP, the Model Context Protocol, I get why they did it. I think this came out of Anthropic, and then everyone sort of quickly adopted it as the standard. And every so often there's a Hacker News post saying MCP's dead or whatever.

I don't think it's going away. It's basically a REST interface, right? A standard way to specify what you want the request to be from the agent to whatever data system you have. And then that data system that receives the MCP request, it's their job to convert it into whatever the correct API calls are to get the data you need. And in the case of database systems, it's going and writing the SQL query to get the data you need.

But usually it's oftentimes a strict translation of what's being passed to you and not trying to derive the semantic meaning of the MCP request, because the MCP request has to be somewhat well-defined. I have no problem with MCP. I think it's not this magic bullet that solves all the world's problems. It's just a digital interface, right, that you can now use to interoperate these different agents and different systems to collect the data you need.

So I'm all for it because you're using the standard rather than some homegrown thing. So yeah, fantastic. It's great. Could it be improved? I mean, I think it's inefficient because you're sending human-readable text over the network to go retrieve data. There's obviously better ways to do this with binary protocols, but at the end of the day, it's good enough, right? And it seems to be the standard everyone's using.

Yeah. But it's no different than if the request came from SQL, from a traditional application client using JDBC or ODBC, the network protocols or terminals for these different data systems. It's no different if it comes from that versus a REST request with MCP. At the end of the day, okay, I got those requests. I need to understand who's asking for it, what are they asking to do, and should they be allowed to do it?

The guardrails we were talking about before, they're the same if it's coming in as SQL versus coming in as MCP.

Yes. So, to give one anecdote, I teach a course on database management systems at Carnegie Mellon University. A year ago, the agents couldn't do our entire projects. So the projects would be like, we give you a scaffolding of a database system, and you have to implement the indexes, the query engine, and things like that. It could do some of it, not all of it. I think it was Opus 4, whatever Anthropic put out last year, that just opened the floodgates, and the agent could basically do all our assignments.

Right? With very little prompting. And of course, there is a lot of training data for it because all our projects are open source. They're all on GitHub, not just for students at Carnegie Mellon University, but also students outside of the university. We let them use it. So there's a lot of training data for them to implement things. And so I think agents basically could implement anything you would want to build in a database system now. Obviously, you have to prompt it the right way and hold its hand and make sure you generate the right design or it produces the implementation based on the design that you want.

At the end of the day, I think these agents are very capable of being able to do this.

The old adage from database systems is that it takes 10 years, but it's a system. You can build the first 90% in three years, and then the remaining 10% takes the next seven years. So yeah, I think that the agents are very capable. With enough tokens, of course, and with enough guidance, you can vibe-code an entire data-driven system. And there's certainly companies that are doing this now, and pretty much every single data-driven company is using agents to help develop things.

And one of the things we do now is we keep track of every single database system that I know about. And for the open-source ones, every single night we pull down all the latest commits on GitHub, and we then track to see which ones are actually being co-signed by Claude or Codex and things like that. And obviously, if people turn that feature off, you don't know whether it's actually being generated by an agent, but most people don't do that.

And at this point, I think over 60% of the open-source database systems have commits coming from agents.

Roughly, yeah. Peloton.

Yeah. So when I started at Carnegie Mellon University, one of the things I did in my first years was go visit companies and sort of see what sort of challenges they were facing with databases. And the overarching theme I saw over and over again was just running these systems, maintaining them, and optimizing them was a huge struggle. And this is not a huge revelation for me. People have been trying to do this for decades. I mean, since the creation of the relational model and relational databases in the 1970s, people have been trying to do autotuning for indexes, partitioning keys, sharding keys, and tuning knobs and so forth.

Microsoft Research did a lot of work in the early 2000s in this AutoAdmin project. They had a bunch of tools that allowed you to manage and optimize databases automatically.

Right. So there's, like, what indexes should I have on my table to speed up queries? And obviously, if you have too many indexes, the writes go slower and you run out of disk space. There's the various knobs that control the runtime behavior of the system, how much memory to use for one memory pool versus for indexes and so forth. This is beyond the capabilities of any one human to reason about. And then if you start looking at if you have thousands of databases, it's just not possible for anybody to manage these things.

So we spent some time looking at how to build automated tools using machine learning and then what you may be able to call AI now, but using automated methods, machine learning techniques to automate this. And we sort of had two research tracks. We had one where we sort of took an opaque-box view of the database system where we said, we can't change the internals. What can we do just with the APIs that the system exposed? So, basically, how do you optimize automatically existing databases, MySQL, Postgres, Oracle, and so forth?

And then another track of research was, if you build the database from scratch, assuming it was going to be controlled by machine learning tools, or now we'd call agents, how would you design the system slightly differently? And a lot of things we learned from trying to optimize MySQL and Postgres, we ended up building in our own system. So the challenge always was then for these automation tools just having enough training data of production databases and being able to take the things you learn optimizing maybe one deployment and apply it to another.

Like, as I was saying before, most people have a staging or development environment, and then they have the production database. And so you obviously don't want to try random things on the production database that may cause you to slow down and degrade performance while you're trying to figure out how to tune it. So you would vet things on the production—sorry, the staging database—and then try to apply it to the production one. But oftentimes, it's never the same hardware, never the same workload.

So that was a big challenge we were always facing, just getting enough training data to feed into the models that can then make good decisions on the production databases. And then the LLMs show up, and that really changed how you can approach the problem because they are basically trained on blog articles, documentation, best practice guides that are all available on the internet of how to tune these databases. And so, on the research side, what we found is the LLMs can get you maybe 85% of the way there in tuning certain things.

And obviously, there are weird corner cases; bespoke algorithms can handle those. But our models oftentimes would take hours and hours to train, assuming you had enough training data to produce the pristine optimal configuration. But the LLMs can come in, just like in 15 minutes, and produce something that was good enough. And that's good enough for most people.

I mean, the answer is yes, but of course it depends on how much improvement you actually want. Like I'm saying, the LLMs can get you 80, 85% of the way there. Is there always more performance to squeak out?

And some people are always going to care about these things, and therefore the automated methods we built in the past would matter a lot more. But for most people, actually, one of the things I was surprised so much was when we had the startup and were trying to do this auto-tuning stuff for PostgreSQL, is how many—

OtterTune, yes. But how many people were running with the out-of-the-box configuration from Amazon or Google in their cloud platforms? And they would tell us, "Oh, we thought Amazon was tuning this for us." And no, they're not, right? So there's enough people that are maybe running with the default configuration, which is, that thing is just terrible. Don't do that. An LLM could come and take care of some low-hanging fruit and provide some meaningful improvements for people in a short amount of time.

So, what I would tell my students always was, for my courses, even if you're not going to go off and become a database system engineer, like go work on the internals of ClickHouse or CockroachDB or Postgres, at the end of the day, everyone's going to interact with a database system. And if you understand the internals of them, how they're implemented, what the data system is trying to do or not do for you for given queries, you're just going to be in a better position to understand what's going on in the world in tech stacks.

Now, do you need my course to figure that out? No. I'd be naive to think so, that the agents, they've sucked all my stuff in so they can regurgitate everything I would teach anyway. So, but at the end of the day, again, whether you're learning it from a traditional university course or self-taught or having an LLM teach you things, if you understand what a database system is trying to do, then it just sort of removes months of mysteries and helps you understand what's going on in your application. Why are queries running slow or not running slow?

Just, you're in a better position to understand what's going on. And so, if you pursued a computer science degree or engineering degree and focused on database management systems, I don't think the era of, like, you're gonna write a system from scratch by yourself, I think that—I'd be naive to think that that's still going to be around. But at the end of the day, the database companies are still hiring people to work on these things because you need someone to understand what the agents are actually doing and make sense of it.

I would say that the traditional role of a DBA, as we've known in the past, I think that's going to be relegated. And a lot of that can be automated. Doesn't necessarily mean those roles go away. They just now get to pursue more higher-minded activities. Like data modeling is always, always important. And again, agents can do a lot of that too. But you sort of need someone to understand, like, yes, does this data model capture what our organization or business is trying to represent in the database?

All those things are super important still. Just like, does someone need to be tuning the knobs or picking exact indexes for tables? I think that ships out. Agents can do all that.

So when I started at Carnegie Mellon, I was the only data systems professor there. There was another professor there, but he did more graph mining, data mining stuff. And so when I started in 2013, I was like, okay, well, I got to figure out how to get tenure. And competition is not the right word, but I'm competing against MIT, Stanford, and Berkeley, and I'm the only data person there. So, all right, well, let's just put everything for free on the internet.

And help promote our research, what we're trying to do. It also had the side effect of, like, I would end up being more prepared for classes because I would—not that I was phoning it in anyway—but I would make sure I had my stuff together because I knew it was going to be recorded and watched, because I don't want to say the wrong thing. I would be more professional. I would say less crazy things, which is, people are shocked when I say this, that my course even now is considered watered down.

Like, even for them, that's bizarre. So yeah, obviously the benefit is not everyone can go to Carnegie Mellon University. It's not cheap. It's a private school. Not everyone can get in, but why should that education be held back from other people? So it doesn't cost me anything. I just put it on YouTube and make everything available to everyone else.

So it started in 2019. I was like, all right, well, let's have fun with this. And when you set up the cameras and things like that for your lectures, there's obviously time to set things up, the wires—we had to set all this up too, right? There's time. So I'm like, all right, well, this is awkward silence where the students are coming in, they're staring at you. There's nothing really going on.

There's nobody saying anything. So, like, let me get a DJ to sit next to me and just play beats and play music next to me the whole time, right? And then you start talking to them a lot during the lecture and you find out they live pretty interesting lives. Like, one guy had a bunch of ex-girlfriends trying to hook up with him. One guy would loan a bunch of money to people he shouldn't be loaning to.

So we just talk about it in the class, plus databases.

As one does.

And then I think one year we had—I did a little joke where oftentimes the top database conferences are always at the beginning of the semester, at the end of the semester. So I have to travel. So the first week of classes, I'll be traveling to go to a conference. So you don't want to cancel class because it's super important for students to know what the course is going to be about the first week because they're trying to figure out classes they want to take.

So I would film it remotely. So one year I was in L.A. for a conference. And then at the very end of the lecture, because I filmed it, I was like, oh, by the way, the most important things you need to know about databases. And I just listed all the members of the Wu-Tang Clan on the first album, plus Cappadonna, who was in jail at the time. And I said, this is the most important thing you have to know about databases.

And then when it came to the end of the semester, the final exam, the very first question was: list all the members of the Wu-Tang Clan on 36 Chambers, plus who was in jail. And you have to get exact spelling. And if they got that question right, they would have got 100% correct on the exam.

That's right. So someone got that wrong. They missed the H when they should have had it. So no one actually has ever got that. And obviously I can't do it again because students are expecting it.

Yes.

I mean, without going too much into politics, the nature of research in universities is kind of tough right now. The funding in the United States is not what it used to be. There's also a larger question of, like, what does it mean now to have a PhD student when an agent can kind of do a lot of things, right? Do you need to have as many PhD students working on stuff when an agent can produce things and work with me as the professor?

To write papers and things like that. I mean, there's certainly still value in educating students, and I like doing that, but it just wasn't clear to me, like, how would I raise money to have as many students as I would want? So I had some companies reach out to me about, like, hey, are you interested in going and doing some interesting things with us? But it was always a bit more like, hey, do you want to come be an engineer with us, or kind of watered-down versions of what I wanted to do on the research side.

And then when I talked to the ClickHouse people, it almost seemed too good to be true because they were like, hey, come do research with us. I'm like, okay, this is what research is. You understand this? They're like, yeah, yeah, go do this. I'm like, okay, do you understand, like, things might not always pan out correctly because this is research? I don't know. Like, yeah, great. Do it. Do this. And it's insane because they're not an early-stage startup, but they're a startup.

They're not a public company. And normally you only see companies, at least in the database world, set up research labs when they already get established.

And for them to take this kind of risk, or to have the luxury of having someone like me come in to do pure research, is amazing, and they're very serious about it. So the opportunity almost seemed too good to be true. And so far, I'm two months into this, and it seems to be working out. I'm sort of in this observation period right now where I'm going through and understanding the stuff that they've built so far because they haven't really published it or written about what they've done.

They have some blog articles which are super interesting, but they've done some amazing work that I certainly can't take credit for doing. My job right now is sort of helping them turn those into publications we can disseminate and put out into the world, as well as start ramping up longer-term, more exploratory things. To be very clear, even when I was at the university, in database systems, my work is very much applied.

So it's not like I'm doing theory work that only 10 people in the world can understand. It's not directly related to anything that's going on. The kind of stuff I want to do at ClickHouse is directly relevant to what ClickHouse wants to do, not just on the ClickHouse system itself, but also now they have a Postgres offering. There's a bunch of stuff we've done in the past on Postgres, and now we can start looking at real data, trying to put some of these things in production workloads and help people put things out there.

So that, to me, is super exciting: to have a direct impact. Instead of me writing the paper and then hoping someone comes along and takes it and adopts what we're doing, we can do the research and evaluate whether it's a good idea or not on real workloads, on real production systems. And if it does make sense, then we can push it out in a short amount of time. So that part is super seductive to me, that I have this opportunity.

Yeah.

Yeah. So, as I mentioned, my job as a database researcher is trying to understand what else is out there, because databases are a really interesting research area. Not only am I, again, using the term "competing" loosely—I don't mean that in a pejorative sense—but you are in competition with other researchers trying to get ideas out and published. So not only am I competing with other researchers at other universities,

you're also competing against the big tech companies—the Microsofts, the Googles, and Amazons of the world. Plus, there's all these startups that have their own database systems. There's not a lot of operating system startups. There's a lot of database system startups, as you know, as an investor. So my job is to try to figure out, when a new system gets announced, what are they doing differently than my own research? What are they doing better?

What can I learn from how they approach the problems that they're trying to solve? And so, when the announcement of—or the release, the unveiling of—ClickHouse in 2016 came out, I was like, I know how hard it is to build a data system, and for this thing to appear out of nowhere and have all these capabilities, like the vectorized execution, the columnar stuff, the compression things, the compaction stuff, it almost seemed too good to be true, or it's a fork of something that already exists.

But at the time in 2016, there wasn't an OLAP engine that was open source that would have all these capabilities, right? So that threw me for a loop too. I was like, oh, so I just assumed it was fake. And then sure enough, it's real. Obviously, it has a lot of benefit.

So I would say the architecture of ClickHouse, the core fundamentals, by 2026 standards, is not novel. By 2016 standards, certainly, it was. The nature of, like, you can store data in this columnar layout. So it's storing all the attributes, all the data for a single column together contiguously, versus, like, in a row store, you store all the values for all the columns of a single tuple contiguously. Like, storing things in that manner, using vectorized instructions in CPUs to process multiple pieces of data at the same time within one single instruction, versus, like, having to do for loops and run things less efficiently.

The built-in compression mechanisms, the way they do a log-structured storage where you're appending a bunch of changes and then, because you want to ingest as fast as possible, eventually in the background you'll compact it and store it in a more efficient manner. A lot of those ideas of the core architecture come from the work done at Snowflake. And prior to Snowflake, there was another system called VectorWise, or X100—sorry, the MonetDB/X100, which then became commercialized as VectorWise from CWI, which is the same school where DuckDB was built.

So a lot of the ideas that people have been developing for these column-store systems and analytical systems and real-time analytical systems had been sort of floating around, but nothing was open source in 2016, at least as far as I know, that did all these things. So when ClickHouse came out of the gate like, hey, we have all this stuff based on all this research that people have done before, it was amazing, right? And since then, DuckDB has something similar, Polars from the guys in Amsterdam, Firebolt started off as a fork of ClickHouse and they rewrote a bunch of stuff inside, and now they have all these things. Like, Databricks has their own version of the engine.

So everyone has this sort of architecture that is predicated or based upon the work done from Snowflake and VectorWise. But again, in 2016, that was super novel. Now it's sort of table stakes. And one of the things I think ClickHouse has done really well over the years is just keep improving the performance even further and expanding what workloads they can actually support.

So I think going back to the agent stuff, the agent stuff seems really interesting too, that people are using this to observe the information, the telemetry that these agents are generating, and be able to react to them in real time and ask questions about them. There's a bunch of stuff done in the financial markets as well, fraud detection. Again, anything where you want to be able to ingest data very quickly and then ask questions about it, complex questions about it, very, very quickly and get back things in milliseconds rather than seconds.

Like that. I think the combination of doing those two things puts ClickHouse, I think, in a unique position.

I mean, somebody asked me, like, why did I join ClickHouse? Again, I'm only two months into this, and it's kind of like asking, like, you just got married and somebody asked you, why'd you choose your wife or husband? I'm like, oh, because they chose me, right? Like, it's a bit more than that. No, honestly, before I decided to join ClickHouse, they were doing things at the business level. Like, so this is ClickHouse Incorporated, not ClickHouse the system.

They were doing things at the business level that I would've done if I was running a database startup like they were, like having a Postgres offering, not just a single OLAP engine that's really good. Now starting in the OLTP space, having the monitoring, the visualization, the observability stack, not just for traditional BI or traditional data, but also now the agents and the LLMs. Like, they're doing all the things to expand out different verticals that build on their platform. Like, all that, to me, that all makes sense and tracks.

Crunchy Data last year.

There's two things. Should a database company offer both an OLTP transactional operational data system and an OLAP system, or at least whether or not they're separate systems or not, that's up for larger discussion. Should you do that?

I mean, going back to what agents allow you to do, obviously maintaining these things is still a challenge, but the bar of entry of deploying a Postgres offering has certainly been reduced. Another conjecture I have in my mind is, is it better for an analytical company, a startup that starts with an analytical database, to then later add an OLTP offering versus an OLTP company then later adding an OLAP offering? Again, I realize I'm saying this and I'm biased because I'm at ClickHouse, but you look at what Databricks did, you look at what ClickHouse has done.

To me, that appears to be the right path to do this. If you want to start a new data startup, start doing analytics first, get traction there, then you can add the OLTP offering. But I can't prove why. Just from the business perspective, it seems to be the smarter play. Now the question is, okay, should you have a single API, single interface, or a single logical endpoint that allows people to run transactions and analytics on what is perceived as a single database instance, or should you have separate services?

ClickHouse right now is separate services. But they have a fast path to get the data out of the OLTP side from Postgres into ClickHouse. What Databricks announced this year was their LTAP engine, or LTAP story, for their Lakebase, where you can run your transactions on Postgres or Lakebase or Neon, and then have the OLAP engine be able to read that data directly so that you don't have to make two copies of it in the way ClickHouse does or other systems do.

So that idea is not new, to have this sort of two engines but one copy of the data. There was a previous startup in the 2010s called Splice Machine, which actually I was an advisor for because the founder was a CMU alum, and he asked me to be an advisor for them. But they were running HBase plus Spark SQL, and they had a single copy of the data that was a row store. I mean, people have been wanting these HTAP systems, or these hybrid systems, since the very beginning.

It's just the challenge has always been, how do you reconcile the fact that some of the data might still be in the row store versus the column store? And the major commercial vendors like Oracle and SQL Server, they'll store two copies, one in the row store, one in the column store. It's called a fractured mirror approach, and they have an internal mechanism to synchronize these things. But the challenge has always been why this sort of hybrid approach has never taken off is because the stakeholders at organizations or companies for these two different categories of workloads have always wanted their own best thing.

The OLTP team, the people that are running the application, the operational side, they don't want something that kind of does okay at operations and can do okay at analytics. They want the best operational database system. And for better or worse, that's Postgres now, right? And best is not always in terms of performance. It could be a variety of reasons why it's considered the best. And same thing for analytics. You don't want a system that kind of does okay at analytics and does okay on operational workloads.

I want the best analytical system. And so that's always been the business challenge, the go-to-market challenge for these hybrid systems. I think, though, Databricks might be in a good position to potentially pull this off because they already have that sort of market from the analytical side, machine learning side, and the data warehouse side. And now you're just adding in this OLTP side. And so ClickHouse could potentially pursue the same thing. That's getting kind of in the weeds of database system architectures.

But I think everybody's always wanted this. The challenge, though, often isn't always just pure engineering. There might be organizational reasons or human reasons why you can't achieve this.

Like a router.

Yes, but Postgres is the best of breed now in many cases. So betting on your front end as a Postgres deployment that is compatible with Postgres, that might overcome that issue.

What is thumbs up, thumbs down?

One of the things that would happen before when I was a professor is, you always hear rumors about who's doing well, not doing well, through a combination of either the investors or former employees or students that maybe go to internships or whatever, or maybe interview some places and they come back. So you get sort of bits of information from everyone. You kind of piece together what the data landscape looks like. Problem is, now we're in ClickHouse, now I see everything.

As an investor, you see everything too. The one vector database company that I know is doing very well is Turbopuffer, and they are hyper-specialized in doing vector search at a cost-performance ratio that's much better than everyone else. So I don't think that the vector databases are going to go away. I think that they'll evolve in two ways. They'll have to become either a sort of general-purpose system like a Postgres, like a MySQL, where they become the system of record where you're storing the original tuples plus the embeddings or the vectors for them.

Or they become like an Elasticsearch, where there's a separate system where they have a copy of the data that's being pulled from the operational side. And in that case, they can live sort of comfortably as being this additional thing you add on. And if you want the raw best performance of vector search, in some cases you may have to go to one of these specialized systems. So I don't think that's going to go away. I just don't think I've seen predictions that, like, oh, Postgres is going to die at the hands of a vector database.

That's not happening. That's not happening.

Yes.

Sure.

I have an outstanding bet with somebody on Hacker News where they said that by the year 2030, the graph database market was going to be larger than the relational database market. And if this becomes true, then I will wear a shirt that says, "I love graph databases," and I will use that as my driver's license, my university ID. I'll put it on my website till the day I die. I'm pretty comfortable. It's 2026.

We got four years to go. This is not happening. No, it's always been a niche market. And I think that, because my perspective on the research side, the research shows that if you do certain things in implementing the engine, which ClickHouse does do, DuckDB does some of this as well, there's things you can do that allow you to do the traversals of graphs, which are essentially just joins, self-joins on a table. You can implement those things very, very efficiently, and you can easily outperform Neo4j.

And that's kind of a kicking—like Neo4j, saying you're faster than Neo4j is like saying I'm faster than somebody that's in a wheelchair, right? You can run fast. It's a low blow. So, but I'm just saying that all the graph databases, I think even the best ones, you're just not gonna—

There's no system that has as much of these optimizations that are in the research and actually appearing in some of these systems now. You're gonna lose. What you will lose against a graph database is if you're doing the graph traversal with the client side and the server side, meaning, like, I got to figure out what the next node I want to go look at. I go back to the client and that decides the next node to go traverse.

If you're doing that back and forth, yeah, they'll beat you guys. But like I said, the SQL standard now supports property graph queries. Oracle has this, right? They were a big pusher of this. This extension of SQL allows you to do that traversal on the server side. So graph databases, I think, are a horrible idea. There's no reason why anyone would actually want to use them.

Yes.

So, a GPU database is a data management system where the execution engine for queries is offloaded to a GPU running on PCIe, or running in the same box or another box. So, the history of people trying to build accelerators for data systems goes back to the beginning of data systems. In the 1970s, they were called database machines. So people would build specialized hardware to run sorting and query execution operators. And that obviously died out in the early 1980s because by the time it'd take you to design and fab new specialized hardware, Intel or Motorola would put out the next CPU, or the hardware got better and just the gains you were getting went away.

So hardware accelerators for databases basically died out in the 1980s. There wasn't a lot of activity in the '90s, 2000s. You saw sort of the rise of people trying to do FPGAs for databases, and every so often that comes back now. Some of the cloud vendors do a little bit of these things, but usually to filter things on the NIC, on the network side of things coming in. So, with GPU databases, again, there was a bunch of systems in the 2010s that were trying this.

We did a seminar series at the university where we invited all the GPU database guys to come and give talks about what they were doing, why they were faster than existing systems. And the big challenge at the time was that those systems, you had to put the entire database inside the memory of the GPU. Because if you had to go back up through PCIe, it was just way too slow. And a bunch of those startups sort of fizzled out. Some of them are still around, but they're sort of specialized for doing visualizations.

And then there was, in the last year or so, NVIDIA has basically gobbled up a bunch of these GPU database companies that were kind of struggling along. And I was an advisor for one of them called Voltron, but they also picked up HeavyDB. And so NVIDIA is all in on this now. So it remains to be seen whether the idea that you're going to build a CPU-only database system, long-term, whether that's going to still hold. I've heard, again, mixed reports. This is public.

Microsoft has offerings now in the cloud that can be accelerated for your data system, can be accelerated with GPUs for analytics. Another major database company that I can't say who they are, they looked at the economics of GPUs and decided it wasn't worth it. So one of my former students, now a professor at the University of Wisconsin, they're now on leave at NVIDIA. They have a project called Cider, which is not necessarily a new database system, but it's a layer in between an existing system and CUDA.

And so it supports taking DuckDB queries and running that down on the GPU. I think they can do this in Doris or StarRocks and DataFusion. And so at ClickHouse, we've been potentially looking at this as well, but it's research. I don't know. It's interesting to see how much translation you have to do between how ClickHouse expects things and how CUDA wants things to be, the data layout and so forth. How do you organize memory or share memory between these different components?

TBD. It remains to be seen whether this actually makes sense. But certainly, there's a lot of research energy behind this. And publicly, I can say this: NVIDIA is obviously pushing this because it'll sell more GPUs, right? Because it's hard enough to get new CPUs. Everyone's compute-bound, or memory is hard to get. The computing hardware is very expensive, hard to get now. And GPUs, of all the things, are the most expensive hardware to get. And now you're going to say your entire database is going to run off GPU.

I don't know if that makes sense, at least in the short term. But if the performance improvements are quite significant, and some of the research shows that it is, maybe it makes sense.

Of databases?

I mean, you can always build new data systems for new hardware, but my track record on this is terrible. We've done a bunch of research on experimental hardware, and it always gets canceled. Or it's even not that experimental. It's like Intel had this Optane persistent memory stuff. We did a bunch of research on building systems for that. Because if you assume now your DRAM is persistent, like you pull the plug and you don't lose anything, that changes how you fundamentally build a data system.

We did a bunch of work on that, and then Intel killed that product line. We were doing other research on processing-in-memory hardware. So think of DRAM sticks with CPU cores directly on the DIMM. So the data system now can say, okay, instead of pulling things from memory, bringing it into my CPU caches, and then I can compute things on them, I'll just send the query down to the DIMM itself and run it there. We were doing a bunch of work on this thing called UPMEM that got bought by Qualcomm and got killed last year.

So that didn't work out. So there's always a bunch of work you can do on data systems, on new hardware. I would say that, actually, I don't know the answer, right? This is one of the things I'm trying to figure out at ClickHouse. And we talked about this in the very beginning: are agentic workloads significantly different than what humans or what existing applications do now? And if so, why or how? And how would you change maybe the development of a database system to take better advantage of this?

That remains to be seen, how that works. I think there's always a bunch of problems in query optimization that I think are interesting. That remains the hardest part about database systems. Incremental materialized views, another big challenge. Again, these are not things that no one else has thought of. People have been trying to do these things for decades. So I think the agentic stuff is probably the most interesting and relevant thing to me right now: what changes with these workloads, and what changes in the system architecture?

And to be honest, I don't know the answer because I just haven't seen it yet.

Stagnant, maybe. Yeah, no, but we've been through this trend before, right? There was a lot of activity in relational databases in the 1970s, 1980s, and then the 1990s. Again, people sort of, the market sort of solidified around these major enterprises: the Oracles, the IBMs, Teradatas. And then if your only viewpoint of databases were from those kinds of companies, then yeah, it looked like it's been stagnant for years. But as you said, a lot of activity in the 2000s, 2010s.

I mean, relative to AI, then everything looks stagnant because there has, in the history of computer science, been nothing like that before. Like, it's just like taking a cheetah, giving him a bunch of cocaine, and putting him in a Ferrari. Like, the amount of speed that people are developing these things is insane. So everything looks slow or dead or stagnant to that. But at the end of the day, I think the volume is going to matter a lot.

I think that one interesting question is, to your point of cost and efficiency, squeaking out the best performance you can get for the hardware that you have, trying to reduce that cost. That's always an interesting challenge that you could pursue. But at the end of the day, I don't think there's going to be a massive change in what data looks like that requires us to throw everything away that we've known about databases. In the same way, you wouldn't come up with a new notion of arithmetic or mathematics to replace one plus one equals two.

The relational model itself is the foundation of how you want to represent data. You can vary the implementations of that. And so there's certainly a lot of work to make these systems more efficient for this. But I don't think you're going to throw everything away and the agents need some kind of database system that you've never even conceived of before. At the end of the day, it doesn't make sense. So I don't think that part changes.

I think, like I said, there's always new hardware. I think there's certainly improvements that can be done for SQL. There's always going to be people trying to replace SQL. I think that might be a lost cause, although SQL could end up being like how, in the same way that people don't write assembly anymore, SQL might end up being like that because text-to-SQL works so well. I think the agentic stuff is super interesting, and I think getting better performance is always going to be, at least from my perspective, a fun challenge, just things we can pursue.

You can imagine a crazy world where you say, "I don't need a general-purpose data system anymore. For every single application, I want to vibe-code exactly a data system that does this for this one thing," and it can then be hyper-specialized. You kind of do this now with code generation or just-in-time compilation for some aspects of queries. And some systems do that: ClickHouse, Postgres, Umbra from the Germans. But hyper-specialization and making that be sustainable might be a bigger research question going forward.

He owns a Hawaiian island, right?

He was. As of today, he's back down to eighth.

Headquarters is in the shape of a database.

But I would say no one is trying to make a serious attempt to replace Linux, right? Yes, there's niche operating systems for different environments, different hardware, and things like that, but no one's trying to build a significant-scale replacement for Linux entirely. FreeBSD predates Linux, from the BSD era from Berkeley, so that's why it's still around. But for databases, there's always new ideas where people think they can do things better than others. So I wouldn't say it's stagnant.

I would just say that a lot of the energy is going to be focused on Postgres in the short term, and there's certain things we can do to improve it. But meanwhile, I still think there'll be these sort of specialized engines. And I don't know what the next workload is. Again, it's not clear to me agentic workloads are significantly different, right? Because they're modeling things that are how humans design applications. Like the vector lookups, that's significantly different than what was in the past.

You needed additional operators. You needed additional indexes to do those things. It's not clear whether—I don't know what the next thing is, but there will be something. There always is.

So when you say better, though, there's two notions of better. There's, like, can an existing query run faster? Yes, ClickHouse has room for improvement. We can improve that. Other stuff is going to do the same thing. But like I said, the architecture, the high level of what ClickHouse is doing, is similar to what Snowflake did in 2013. Databricks is basically copying some of the existing ideas as well. Everyone is kind of doing the same thing, at least for analytics.

And what really matters, and one of the things that Snowflake did right, was part of the success is the stuff around the database system, like the user interface, developer experience, building to ingest data, interoperate with other things. That part they did really well. So it's almost like the things around the scaffolding of the foundation of a database management system that actually matters a lot. And one of the things that ClickHouse is actually—this is not research for me—but this is one of the things they are doing better.

Over time, it helps expand the reach of what you can use the system for. So the core kernels of the system can certainly be improved, but the fundamentals of what ClickHouse is doing versus other systems, at the smallest level, they're pretty similar. But the stuff around it matters a lot. And I think ClickHouse does some things well, can do things better. Snowflake does some things well, can do things better. Same with Databricks and the other guys.

It's like when you look at Run the Jewels, it's like taking El-P and Killer Mike. Those guys were established on their own. You put them together, it's like people putting peanut butter and jelly together for the first time, right? So I like to think me and ClickHouse getting together is like that.

I'm glad you found that in there in the blog article. That was my—it wasn't a test. That was my—because I wrote the blog article, I was floating it out there to see what ClickHouse would be okay with. Obviously I didn't want Larry Ellison in there, but I wanted to see, like, hey, if you get Andy, you're also getting other baggage.

Thanks, Matt. Happy to help.

Bye.