Inside Google’s Database Infrastructure for the AI Era

Speaker A: Historically, databases were responsible for storing data and returning exact results in response to queries. However, AI is now bending that contract in a new direction. Applications increasingly expect structured and unstructured data to come together. This is pushing databases into territory that looks more like search, where relevance and ranking matter and results are no longer strictly exactly. Agents are also beginning to write their own queries and even propose their own schemas, which raises new questions about how data should be structured, governed and trusted. Silesh Krishnamurti is a VP of Engineering at Google and in this episode he joins Matt Merrill to discuss his background, how databases have evolved over the past 50 years, and where the field is heading as AI reshapes how data is queried, structured and trusted. Matt Merrill is a software engineering leader with over 20 years of experience building and scaling software teams across enterprise and product focused organizations. His background is in um, backend development, cloud architecture and distributed systems design. He currently architects and delivers software products and leads a team of engineers at Dept Agency. You can learn more about his work@code.theothermatmm.com foreign.

Speaker B: Hello everyone, I am Matt Merrill and I love databases. So I'm very excited to be here with VP of Engineering for Databases at Google Cloud. Silesh Krishnamurthy so before we start getting into all the geeky stuff, I was prepping for this interview and reading through your background and I thought it was quite incre. So can you tell folks about your background and leading up to what you do at Google and then we'll kind of dive in after that?

Speaker C: Sure. Thank you so much Matt for the opportunity. I have been in the database industry for most of my professional career. Started in the mid-90s. Um, I worked at IBM, worked on DB2 and enterprise databases and then I did something a little crazy. I decided I like databases so much. I went to grad school. I went back to grad school. Second attempt at grad school. This time I went to UC Berkeley. I did my PhD on streaming databases. I ended up starting a company around to try to commercialize my PhD work. It was an interesting time to start a company, late 2000s, a lot of challenges, lots of ups and downs, a lot of interesting learnings. In the end we sold our company to Cisco and it was a very interesting opportunity. I learned about networking, a whole new space I didn't know anything about. And then I went to Amazon, I worked at AWS and I worked on a system called Aurora. Uh, and I was there for about five years and I came to Google in 2019 and I've been there since.

Speaker B: And so with a little system called Aurora that I think a lot of our folks probably know that too. And was that was with multiple different flavors of databases or was it with one particular one?

Speaker C: Or in the end my eventual role, I ended up leading both Aurora, MySQL but all the other, all the MySQL engines. So there was also uh, classic MySQL managed MySQL part of RDS and other systems.

Speaker B: So that is fascinating. I think it's suffice to say you know a thing or two about databases. And so what are you doing now at Google?

Speaker C: Database is probably the only thing I know at this point. But yes, I like to have two jobs at Google. I lead transactional databases for Google Cloud, but I have a second job. I also lead operational databases for all of Alphabet. And so whether it's Gemini or Gmail or YouTube, all of these run that same database, uh, infrastructure on the same set of systems and Spanner and BigTable. In many ways my second job is very much like the interlocutors of my first job. People who build and run infrastructure teams, they run it on behalf of various businesses. Sometimes businesses listen to them and sometimes they don't. And that's very similar to my world for my internal job. Again, we have a lot of legacy infrastructure at Google. It's a 25 year old company. Sometimes of course we do know that we have to keep modernizing our infrastructure. One of the beautiful things about working at Google is through the years we've been really good at taking long term bets. We've been willing to take the hard risks, willing to try out things which may not be very clear when you're taking the bets. And so the reality though, when you have so much infrastructure, you can't afford to take bets for everything. And so sometimes you go and run a complicated migration to modernize some old infrastructure and sometimes you can't afford to do it. And this is in many ways very similar to what people in the enterprise world would do.

Speaker B: Absolutely.

Speaker C: They had their druthers, they would like to modernize every single system but sometimes you just can't.

Speaker B: Yeah, that's pros and cons. Oh boy. I don't think when I was prepping I fully appreciated that that was your quote unquote other job. So we might dive into that a little bit too.

Speaker C: For what it's worth, when I got hired, no one told me about that other job. I came and learned about it when I came in here.

Speaker B: Oh boy.

Speaker C: Okay.

Speaker B: Just a little Thing just run the databases for Alphabet. Yeah. Uh, okay, just so folks know, how long have you been at Google now?

Speaker C: About seven years. Very soon.

Speaker B: Seven years, Cool. So let's dive in. So you said you did your PhD on streaming databases, you turned it into a company. I think not many people have researched databases in academia and at uh, a startup and inside a company as large as Google. So over those 20 years, what do you think has changed and what do you think has stayed the same?

Speaker C: In many ways there have been a huge amount of change, but in other ways there's not been that much change. Fundamentally. I joke that with databases you have one job. Don't lose the data that's being stored. Give the exact results that you're asking for. This stayed true for remarkable amount of time for all these 50 years of databases. In fact, it's interesting, a couple of years back I was giving a talk at Berkeley, my Alma material, I think it was on May 5th or something in 2024 and I became curious, I wanted to, I was wondering when the original uh, SQL paper was written. It turned out to be almost exactly to the date, maybe two days off in 1974, the year I was born. And so it's easy to forget. But this remarkable industry, the system, the set of technologies has been around now for 50 years, but the truth always was about building reliable systems, making sure you get exact results for your data and something I like to call database dogma. Database dogma is really being focused on specify what you want, having a declarative notion of what you want and where the system goes and figures out how best to do it. And there have been all kinds of excursions around this. You had different kinds of systems, non relational systems, various other kinds of things. But in the end of the day database dogma has remained the same. Try to build systems where you have declarative interfaces where people can ask what they want and the system focuses on producing it. System makes sure, like I said, don't lose the data, small detail and produce exact results that you can rely on. One of the things I like to say when you say don't lose your data and being highly available, availability itself is an interesting idea that it's not just about if the system is on or off. A long duration performance event effectively becomes an availability event because if you start seeing latency excursions effectively your site may go down. A long duration availability event effectively becomes a durability event. So all of these are deeply connected. So in many ways the crux of how databases were built what we are serving to do, our purpose in life has not changed, but in other ways they have changed a lot. Especially over, I would say the last three to four years in the AI era. But even if you zoom out from that, one of the biggest changes I think has happened maybe over the last 10 years is how sophisticated enterprise it has become. It used to be the world that people built in corporate IT people would buy off the shelf applications and in the process install a database. Enterprise IT in the past was not necessarily as sophisticated. A lot of the excitement, a lot of the change was sparked by open source software. It took a long time for the best practices to make its way to enterprise it. That's not true anymore. Enterprise it, I talk to customers all the time, just incredibly creative. And so the idea that enterprise IT would just take software and run it, it's not true anymore. They're innovators and so they are demanding a lot more from these systems. There's been a lot of experimentation, there's been traditional databases where scale up systems. And so while they evolved, coming to the cloud in a very evolutionary path, there were also these, what I call revolutionary systems, scale out systems. BigTable was one of them that we built in Google about a little over 20 years back and Spanner is another one of them. And these set the tone for a whole industry, uh, where people approach this data management problem from a fundamentally different way. And so a lot of things has changed I think over the last 10 to 15 years, but I want to zero in over the last three years or four years. I think what is happening with AI is taking things to the next level. What we are seeing is it's not just about producing exact results on exact data. What we are seeing is the confluence of structured and unstructured data. And what that's leading is applications, workloads, where people are expecting that these things get put together. And now the database world starts to look a little bit more like the search world, or in academic terms it looks like information retrieval. And so it's no longer just enough to not lose your data and produce exact results, but when you're asking to combine structured and unstructured data, you need to provide the best results. And so now you have a mindset shift producing exact results to starting to produce inexact results. And so the relevance and the ranking starts get important. And this underscores a more secular change. Even when you go from databases to systems at large. I think we have to think about how you build non deterministic systems in a fundamentally different way as you started

Speaker B: talking, that's exactly what I was wondering about is the exact information retrieval, because it definitely seems like that is something that's changing. I also, like I might be going out on a limb here. Of course, the database's goal is to not lose any data. But in an age of big data, you know, if we lose a couple of click events or something like that, it's not quite as big a deal as losing a financial transaction or something like that. Right. So I'm curious if you see that at all or if that's built into any systems. I would imagine it's not.

Speaker C: But I mean, there's certainly systems which can choose to have a different constraint. It becomes at some level a cost issue, a performance issue, a latency issue. And so I think it's true that it's no longer one size fits all. It used to be that all databases looked roughly the same. And I think that's not the case anymore.

Speaker B: That's a good lead in to Spanner. So if I'm being honest, I don't know much about Spanner. I've heard of it, I've never actually used it. So for those of my fellow Spanner noobs. So why would I reach for something like a Spanner instead of a Postgres, my favorite. Or MySQL or something like that, and then we'll go into this new product. You have sold Spanner Omni as well. But let's start with Spanner itself first.

Speaker C: I just want to preface that Postgres is amazing. I love Postgres.

Speaker B: Me too.

Speaker C: As a grad student, I wrote code in Postgres and it's really taken the world by stock. And it's really a testament to the power of an open source community. And that's a whole separate discussion we could have. And there are many, many good reasons to use Postgres or MySQL and there are people who will use commercial databases. There's a role for Oracle, there's a role for SQL Server, and we support that too. I think some of the biggest differences that are there in Spanner is first, extreme scale. So you are not limited to what you can run on a single node and you have the flexibility to scale out, scale in. And so that's pretty remarkable. In the past, as I mentioned before, with revolutionary systems, people skim at the problem space of needing more scale than you could on a single node. And given that they were building more bespoke applications, web crawling and things like that, the requirements were different. From what needed to be served by traditional databases. And so a whole era of these revolutionary systems started getting built. BigTable, various other efforts, trying to build something like it. At the same time, there were many things that were amazing with relational databases. Strong consistency, transactional semantics, secondary indexes, a whole bunch of things that application developers take for granted. And no one had, prior to Spanner, no one had figured out how to make these two worlds work together. In fact, the origin story for Spanner goes in Google, the ad system used to run on sharded MySQL because when it ran on MySQL because it was so big you had to shard it. And so that was a complicated process. And roughly it was something like every year you would have to figure out how the system was going to grow and you'd spend a huge amount of time sharding it. I think one year, I think it was sometime circa 2008, 2009, they came to the conclusion that in the time they would take to shard it, the world would have changed again. And this was a, ah, hamster wheel that they had to get off. And at that point, Google leadership again, as I mentioned before, one of the amazing things about Google was take those big bets, decided, this cannot stand, we've got to do something better. At the same time, there was also recollection that if you look at ads, it's very different from Google search or Photos and so on and so forth. By the way, some of these consumer services that run on Spanner, you can look at the DDL file like the sets of tables, and you can stare at it and make sense of it. 15 tables, 20 tables. But you look at ads, it's a classic enterprise application. Thousands and thousands and thousands of tables. And not just one, many, many applications. So if you look at the ad system, you needed the scale of that was there in Google, but you also needed the functionality of enterprise applications. You needed secondary indexes, you needed transactions, you needed all that other stuff to build enterprise applications. And so we set out a build Spanner to solve this problem that you wanted the functionality of enterprise applications, you wanted scale. And then there was an additional twist, a very uniquely Google twist. You wanted systems to run globally. And so while people had figured out some ways of trying to address scale, no one had figured out how to solve all these three together. And so that was how Google builds Spanner. Now you asked a slightly different question though. You asked, hey, what should I reach to when I was used as an everyday developer? And I think, uh, if what you're trying to do is something that will run in a single node. Postgres is just fine. Even if you need to run a bunch of replicas, Postgres will work for a lot of situations. I think what we've found with Spanner is there are enough and more people who need some combination of things. Sometimes they need global resiliency, they need to have a um, multi regional configuration that's synchronous. Sometimes they need scale, sometimes they need a multi model database. So one of the big things in Spanner now is you can have, have beyond just a relational schema. You can have a graph database, you can have full text search, you can have vector search. It's all integrated into one system. Having said that, I would say that's probably we're just a little ahead of the times there. If you look at Postgres evolution, you'll see graph databases, technology coming to postgres, full text search coming to postgres. So at some level you will see all of these databases are seeing the same things. They are seeing this emergence going back to inexact processing, structured and unstructured data coming together. That's the need for um, AI. And so in terms of that kind of functionality, I think you will see it in many other places. But scale, being able to run on multiple regions, being able to scale up and scale down trivially, these are things uniquely that you will get with Scan.

Speaker B: Nice.

Speaker A: Every visitor on your platform looks the same at first. Can you trust them or are they a threat? Fingerprint lets you answer this question right away with one API call, no model to maintain and implementation in minutes. Fingerprint recognizes bots, AI agents, VPNs, tampering and over 100 more unique signals to give you durable risk scoring and threat detection in real time. Even as human and agentic activity blends together, you can identify suspicious traffic faster and build safer and more secure sites and apps. Over 6,000 companies rely on it every day. Join them now@printprint.com youm're listening to Deepgram Flux TTS.

Speaker C: Different voices, same model, all ready to speak. Flux TTS is a streaming text to speech model built for voice agents.

Speaker A: Flux reads the room.

Speaker C: It holds context across the conversation, turn

Speaker D: after turning with consistent tone, interruption, handling

Speaker C: and um, plenty of personality. So your agents keep it flowing and customers can just keep talking. Try Deepgram Flux TTS free now until September 12th. Visit Deepgram.com keep talking terms apply this

Speaker D: episode of Software Engineering Daily is brought to you by warp build. AI is writing more code than ever. Which means GitHub Actions is running more than ever. Your GitHub Actions bill is now a function of how much AI code you generate. And every engineer knows the feeling. You push a commit and then you wait. Warp build makes GitHub Actions twice as fast at half the cost with a one line change to your workflow. Linux, macOS and Windows runners in Warp builds cloud or your own Enterprise Ready SoC2 Type 2, attested and trusted by teams like sky from Comcast, bitcoin and braintrust. AI get started with $50 in free

Speaker B: credits@warpbuild.com Sed M okay, now that all makes sense. And then there's just released Spanner Omni which lets people run this on Prem.

Speaker C: That's great.

Speaker B: Which is really interesting to me based on everything you just said. So you need to run globally. I mean obviously it's a little different, right? But why is that a big deal for Spanner? And really how does that work with being able to pull something out of the massive Google infrastructure and allow it for somebody to deploy it on Prem?

Speaker C: The engineering work that uh, went into building Spanner Omni is really actually an inspiring story in its own right. We've taken runs at this problem before and certainly knew it was going to be a hard problem. And I think the key was the technical leaders who had talked about it before decided we're just going to go do it. We are not going to worry about how hard it is. Again, classic Google. We'll take the hard problem, we'll start working on it without figuring out an end date and delivered it. I think it was two years. Just remarkable work, remarkably fast. But let's talk about, and that's a whole separate story and maybe that's a story over beers. Let's talk about why this is important and what does it mean. I think there are two or three broad themes. One, the nature of Spanner. Many of these customers are backs. They're highly regulated. They are people who have extreme requirements and either they needed to have some kind of business continuity or regulators in some industries, in some jurisdictions mandated that you need to run in a world where you also have the optionality to run in their data center for a stressed exit scenario. One customer of mine who works at a bank was telling me when they were moving a traditional legacy system and he was complaining to me about the regulator's position. He said, I know that I'm, um, considering moving from a system which gives me two and a half nines of availability to a system which gives me four or Five nines. But whether it's a single region or a multi region configuration, and the regulators are asking me to justify it, this makes no sense because I'm actually getting to a better situation. But I think the everything is better. Why?

Speaker B: The regulations always have to catch up with tech, right? Yeah, right.

Speaker C: Uh, to be fair, I think I can understand the regulators positions. I think you'll see a lot of different positions that are there. And it's, you know, having continuity of data in multiple places I think is important. So I think this is one of those big requirements that really was there for lots and lots of customers that we talked to and in many ways it inhibited their ability to come on spanner. So many people would say, I want to come on spanner, I want to take the bet, but how do I get optionality? So that was one. The second, I think big theme is customers in this AI world are scrambling for capacity and infrastructure everywhere. They are not in a unidimensional world anymore. In fact, I think two things that have happened here. One, it used to be that it was uh, a unipolar cloud world. Now there are multiple cloud service providers, there's Neo clouds, there's a whole bunch. It's a very thriving ecosystem. And second, it used to be that cloud vendors hated the word hybrid. It used to be that you could not even use that word if you worked at certain cloud vendors. But that's not where customers are. Customers today have a lot of infrastructure. Sometimes it's because they want optionality, sometimes it's because every non trivial business grows through acquisitions and integrations and acquires different businesses. And so diversity in their infrastructure is a reality. I was at a customer advisory forum um, few weeks back and one customer passionately explained that their crown jewels will remain in their data center. So this is I think the reality of 2025, 2026, that it's not a secular world where everyone is running, picking a single cloud and their world is simple. The world is complex and the world is messy and we have to react to that messiness and that opportunity. And there's a few other reasons. Sometimes the customer wanted something, desperately wanted spanner. Because look, the truth is there's nothing quite like it anywhere in the world. And so between the mix of all of these things, it became very clear for us that making spanner available on other infrastructure, on other data centers, in other clouds was actually important for us. Now it comes to maybe what you're trying to get at. How does this work? How do you peel it apart? What is the fun technical part? So there's I think two or three separate streams here. One, the way we operate Spanner is a little different than how we are packaging Spanner Omni in the cloud. We get operated as you would imagine. There's lots and lots of different microservices, different piece parts, different things that we run separately and that's organically evolved and it's the way we operate it. We know how to operate it. But when we are making it available for someone to run that infrastructure, we knew first and foremost that packaging was very important. We had to actually simplify the operation. You could not expect people to go and run Spanner Omni just the same way we run Spanner. So one of the important packaging things is we collapsed it all into a single binary that you can go run on a deployment. So all of the different microservices that we have, you don't need to worry about it. You download a single binary, you can run it on your laptop, you can run it on a deployment, you can assign a set of nodes and you're off to the races. May sound simple, but it was actually, as you might imagine, a really hard thing to do.

Speaker B: Oh, the simplest things are often the hardest. Right. So I think that's incredible.

Speaker C: It is actually a really incredible achievement. Right, then what is the infrastructure that it's running on? Certainly storage is important. And so how we run Spanner inside Google, we benefit from Colossus, which is this really amazing system that no one else in the world has, which I think so key to how we operate inside Google.

Speaker B: What is that like a RAW storage? I'm not familiar with it.

Speaker C: It's a storage system basically Ros.

Speaker D: Right.

Speaker C: It's a disputed storage system and it's a zonal service. Spanner depends on it. One of the reasons Spanner and bigtable are so much better than any other scale out system is because we leverage Colossus. And so when we need to split or merge, when you have to scale out, unlike um, everyone else in the world, we don't need to copy data, we only have to copy metadata. It's a huge superpower. No one else can do it because everyone else is keeps copies of data and then they sit copying the data back and forth when they have load. So we have to model how we deal with storage. And so there's a whole bunch of innovation and clever tricks that we came up. And then the thing that everyone wants to know is true time. So one of the things that marked Spanner when we first Came up with it in having a uh, globally replicated system is to tame time. And so in order to make transactional semantics work, to make distributed uh, transactions work, it's very important to be able to reason about time. What we did at Google relied on special hardware atomic clocks in the data centers. Whole bunch of things that I don't actually understand, but to be able to talk about what we call the epsilon, the delta between these different times. Spanner's transaction semantics essentially depends on what the delta is. And we are able to impose things like how long you wait on commit various aspects of the transactional system by looking at the different participants in the transaction and what is the notion of time they have. And with our understanding of the actual epsilon, that is the deltas between the time and because of these atomic clocks, we are able to keep the delta very low, which makes Panel run like a champ inside Google. Now the question was, what do we do when we go to other environments? A few things I think that helped. One, the fact that we talked about true time and other things have meant various other systems have done a better job at providing better time primitives. The state of the world in 2025, 2026 is very different from the state of the world 15 years back, in no small part because of what we did with Spanner and what we uh, helped teach the world. And so there are better time primitives that are there still not as good as our hardware clocks in our data centers, which we still think are the best, but they are probably actually not meaningfully that worse than Spanner, than our world in 2012. I talked to you about ads 2008, 2009 was when we had our come to Jesus moment, right? 2012 is when Spanner went production inside Google for the ad system. And the world of what you can get with time outside Google is certainly not as good as what we have in our data centers, but it's ballpark how it was in our data centers 15 years back. So the world outside is kind of like the world Inside Google in 2012. And Spanner was built for that time. So we built something called software through time in that we have available that you can run in other cloud providers and other legacy cloud providers and data centers. And with software TrueTime and with Spanner we're able to provide still a very quality experience. There will be aspects of it which will not be as good as if you run inside our infrastructure, but we believe that for many, many use cases it'll do just fine. That's the secret Sauce.

Speaker B: That makes a lot of sense. So basically what I'm hearing is, so, especially with TrueTime, the level of accuracy needed to scale. At Google levels, you need that level of accuracy. But when you're at lower levels of scale, which that's not undercutting what some of these major customers probably need. But it's also not Google scale.

Speaker C: It's not Google scale. And in many situations it depends on the actual workload. You can accept a little bit of that extra. Maybe it's a slight different latency implication or, you know, something like that. In many, many situations it's, it's just fine. And by the way, I think other interesting things have happened. There have been customers who come and talk to us and said, hey, what if we install the same kind of atomic clocks that you have in your data centers? What if we do it in our data centers? And my answer is, let's talk. I'm very happy to support that. I think it's one of those things. In many ways, how data centers have built, are built today are, uh, because the work my colleagues have done over the last 20, 25 years. And so each of those lessons from commodity infrastructure, from things like atomic clocks, I think they will make their way to the wider ecosystem. And as a labs researcher, leave aside my role as a Google employee, I think that's a good thing for the industry at large.

Speaker B: Yeah, that's fascinating. If you can share that idea of that single binary fascinates me first of all because I love the idea of a single binary. Uh, I don't need to install anything else, it just runs. What is that written in? Is it some sort of.

Speaker C: Is it C or a lot of C code? Yes, yeah, a lot of it is

Speaker B: primarily C. All right, cool. All right. Good old fashioned C. Maybe I will

Speaker C: help us write it all in Rust or something.

Speaker D: I don't know.

Speaker B: I've been talking a lot about Rust lately with, with some clients, so. So graph algorithms natively just shipped in Spanner as well. And I'm having a little bit of a hard time wrapping my mind around why would I need that in a transactional database. So can you talk about a real use case and where this clicked for a customer and why this is really valuable.

Speaker C: It's a great question. It really gets to the heart of why running these graph algorithms natively in an operational database like Spanner is so amazing. Right. It's real game changer. First, what we did with graphs let you natively model the data as graphs without moving the data out. You could have your data in a relational schema. You can build an overlay. On top of it, you have a DDL command that says, create property graph. And you don't actually move the data. You just start querying it like a graph. It's amazing. It's really, really, really powerful.

Speaker B: So it's like a graph view, essentially.

Speaker C: That's right. Now, you can also come and say, I don't want the relational view, I just want a pure graph interface. We support that too. What actually happens when you create a graph view effectively? In a way, you're modeling relationships that are there. And then once you are viewing it with the graph prism, maybe you ask questions differently. You ask questions around traversing the system. By the way, it's still declarative. The database dogma is not lost. You still ask, find me all the nodes which are two hops or three hops or four hops. And so where this becomes powerful is in any place where there are lots and lots of these relationships. And there are many classic use cases, of course, just talking about graphs and we'll talk about algorithms in a second. Some of them infrastructure, right? You have ports and network switches and things like that, and you want to connect them. But a lot of use cases often come, um, in the security world. You might have users and relationships between them and accounts. And you want to look at the trust graph, if you will. Customer360 is something that is very big. That's a very big graph use case. You have a lot of information about customers. You have business questions that you're trying to ask. But customers are similar in many ways. Maybe they share certain purchasing profiles, maybe they have interconnections in social media that you are able to find out. Another very important case is around fraud detection, where you were trying to understand relationships between users and accounts and things like that. But tipping aside, I think the biggest interesting thing is you can ask more complex questions on the data in your transactional database without running a messy ETL pipeline. We can all run pipelines to move data and ask questions somewhere else. But do you want to? Do you need to. In large part, what we're trying to do with Spanner with the multimodal approach, is to be able to ask more complex questions in your data in C2 without having to move it around. Graphs are all about relationships. So the first version of what we did with graphs was made it easy, like I said, to define these graph views, as you put it, or a graph overlay, and start asking questions, make these things perform better, like a Beast. But then what we started seeing was, again, a little bit of inspiration from what we're doing inside Google. So inside Google, we've been building these graph algorithms for decades for solving many complex problems in the web space. But now we found they're all actually very transferable to problems that customers face when they think about graphs. So, classic question, financial fraud detection, right? It really clicks. For many customers, sophisticated fraud, like money laundering or synthetic identity fraud, often involves networks of colluding accounts. And the problem is that these fraudsters create these complex webs of accounts and transactions to try to obscure their activities. And they're always moving. It's an arms race, right? It's a cat and mouse game. As your systems become more and more complex, they're changing things, they're doing different things. Which, by the way, is one of the challenges. If I have to keep moving the data from my operational system to another system and run it. Scams are moving very, very fast. So analyzing individual transactions in isolation often misses the bigger picture of coordinated fraud. So how Spanner graph helps is that banks and payment processors can store customers and transactions in Spanner. They can model this graph, this data as a graph, like I said, as an overlay. Accounts are nodes and transactions are edges. And you have very interesting community detection algorithms, like weakly connected components, modularity, clustering, that you can now run natively in Spanner. Because I have this big monstrous graph, I want to keep finding out, what are those sets of related people? What are these communities? What are the clustering things that you're trying to do? Once you detect these suspicious clusters, some of them may be suspicious, some of them may be not. You want to zero in on who are the most influential people within that suspected cluster. Now you can squint at this problem and say, what is this like? Actually, it's just like PageRank. In fact, it is PageRank. You can run PageRank on the nodes within that cluster. And so although PageRank was originally for web pages, it's actually really very good at, uh, identifying who are the most influential nodes or the central nodes in the network. So not only can you figure out, here's the colluding set, you can now zero in on your actual problem space. So I think this is kind of a great example of how you could actually run these things. And it's really valuable to be able to do this in C2 without having to move this to some other system. So, for example, I think we have a customer, uh, danapay. It's an Indonesian digital payment solution. So they're using Spanner Graph for their anti money laundering use case. And by running these algorithms directly within Spanner, they can do a whole bunch of things. They can detect suspicious networks much faster again without having to go through an ETL cycle. They can identify key players within those networks. They can potentially flag or block transactions. And this is where the real time comes in. Sure, you can go run this in an analytics system, but if I can flag and block the transaction, I can prevent financial losses and really avoiding these unnecessary operational overhead. So maybe in general the average transactional database doesn't need PageRank, but what you really need is fast, actionable intelligence on relationships within your fresh operational database and native graphs and uh, standard deliver exactly that.

Speaker B: I can see the value now. It's, it's a proximity thing. It's built in right into data. So that makes a lot of sense. And I would imagine even some places not at scale that can build from the ground up can take advantage of that and not have to worry about ETL and things like that.

Speaker C: Right, right. And yeah, it just makes it easier. I think SoundCloud, for instance, they're running graph algorithms and batch more for years. I mean a lot of times people may have been thinking, well, that's the only way to do it. And I think one of the things I told you earlier about how impressed I, um, am how inspiring it is to work with enterprise IT and developers who are so smart. I think as you provide more things, we get surprised. They will find things that we didn't even anticipate.

Speaker B: I think it's fascinating. Something that um, I'm seeing like a pattern coming up is like, you guys dog food. This amazing technology with this amazing scale problem that Google has. You productize it and then it's out in the marketplace. And there's also more creative things that happen. And it's this, I don't know, it seems like a nice circle. So.

Speaker C: Indeed.

Speaker B: So let's zoom out a little bit. For a long time, the first hard decision in any project was which database, how do I structure my data? So now we have LLMs which are happy to pretty much gobble up any data that you might want to throw at it, structured or unstructured. And we have agents writing their own queries. And so what actually has changed in the last few years about how you should structure data? And is schema design still relevant? Is it not relevant? I think that that's a little bit of a rhetorical question. But I think what still remains important about schema design by the Way it

Speaker C: just occurred to me there's, I think of a famous Dilbert cartoon strip which says the first thing you do is you design the database. I don't even know what I'm doing. I'm going to design the database. So I thought about that.

Speaker B: I think I remember that.

Speaker C: Yes, it's a very interesting question you're asking and I think, you know, just to be very candid, I don't think we know everything that is going to change. It's changing very fast with AI. Uh, having said that, there is an enormous amount of applications, bespoke applications of the self, applications that I don't think will disappear overnight. These applications still exist now. I think there's an urgent need for them to be more easily used in agentic applications. So even before you think about schema change and what needs to happen, I think you have perhaps a more urgent, pressing problem, which is how do you activate and light up the existing database for these systems? And so, in our vision of the agentic data cloud, uh, we think there are three important pieces. One is the AI native infrastructure, and I alluded to you before, things like Graph, by the way, are very relevant. Vector search, full text search, all of these things are very important as you imagine the world of structured and unstructured data coming in together. So that's the first, I think the second thing we also talked about, we think in this world of agentic AI, a lot of gaps, friction needs to be eliminated. And that's a big part around maybe a borderless world. You have these lake houses which are spanning clouds, you have things like Spanner Omni, we have Alliedb Omni for postgres applications. So I think that's kind of the second thing. And the third thing, perhaps starting to get very relevant to what you're asking, is all about trust. And trust really means in order to light up these databases, you need to have the context, you need to know what's in these systems, what's in the data. And you talked about schema design. Yes. It used to be, you know, you have to design schemas, but it turns out for agentic applications, just the schema itself is actually not even enough. Forget getting to how schema changes back in the day. When I first worked on DB2 almost 30 years back, I was wondering, why does the SQL standard let you say add a comment? I don't know. If you know, when you say an object create table, you can add a comment to it. And, uh, it seemed like a extraneous theoretical thing or something.

Speaker B: Yeah.

Speaker C: Now that kind of stuff is actually interesting because it now tells you what you know. It could be used to record what is the meaning of something. But more realistically, I don't think we're going to depend on a comment in a, uh, schema. You're going to try to gather information about the schema. So while the structure of the schema is an interesting question we should talk about, I think perhaps the more interesting question is where's the context around the schema? I'll give you a very simple example. If I have a table with a billing address and a shipping address, there's two columns. If one of them is null, there is some implicit knowledge that these two are the same. That's not there in the schema. You need to extract that information. That's the critical context. So for LLMs to activate your operational databases, and I think before you even think about new greenfield applications, this is the pressing need to light up those databases. You need to have the metadata more than the metadata, the metadata and the context about your data in order to have agents go ask questions. And it's not just about things like that. If I have a column called City and I have an agent which is going to use an LLM to generate a SQL query to query the database, somehow something needs to tell the agent that the values in the city column, are they in lowercase? Are they pre letter AIRPORT codes? So again, this information about the data is super important now I think. So one stream is yes, schema and context. Schema is important. What's more important is context. I think that's the first piece. I think there's a second piece which is also interesting, which is is there a world where you have citizen developers just generating apps? And I was reading some stat about how the number of applications on number of repositories in GitHub is exploding. We have a partnership with Google, DeepMind with AI Studio, where you can go and say, when I'm building an application AI Studio, you can say, I want this to be a persistent application. And you can choose either cloud SQL to store the data in relational format or Firestore to store the data in document format. More practically, you ask the AI and the AI will decide. We are just actors on the stage, I guess. So in things like that, there's an interesting question, how is the AI going to define schemas? Well, the truth is AI is going to define schemas the way humans have been designing them, because that's what's trained these AIs. So I actually think even when you took a look at that, AI models will tend to pick this kind of schema structure that made sense. Now, I think it's very valid to ask, is that the right one? In a world of AI, Someone was telling me about a situation where they realize they don't care about abstractions of code as much as they used to, because they're like, yeah, sure, I'll just have AI go copy it and make changes. I don't know. I mean, surely that's a path towards more chaos. You know, I'm not entirely sold that the general rules for defining and structuring schemas is going to be fundamentally different if AI is generating the code or humans are generating the code. But I think there's a third piece. The third piece in my view, is there is a world here with new kinds of applications where the question of what is an application changes. Today an application has what I like to call four walls. It has a boundary, an API surface area. I think we're going to see a new world where applications are ephemeral workflows. The application as such doesn't exist. Maybe today, um, one morning a knowledge worker comes into work and says, you know what? I have system A and I have system B. I want to create some more complex purchase order that combines them. M. But what would they have done in the past? Well, maybe they would have done a contract with large system integrator, paid a lot of money, we have got some results after six months, whatever it is, Right? But now in this new world, they're just going to ask the AI to go do something thing right? Now, where does that information that connects all these things stored? It has to be stored somewhere. So you need to store these trajectories on the data on these agent interactions somewhere. But systems also need to be more flexible. For instance, if you travel internationally, you're probably well advised to call your bank and put a fraud alert so that your credit card keeps working. Well, what if you decide to chuck your job or go and spend a week in each country in Southeast Asia and come back after three months? And so in the AI, uh, world, you might call you back and say, I want a fraud alert. I want one week in Vietnam, next week in Laos, the next week in Cambodia. Well, the bank system is probably going to choke because people who designed the system didn't think about the world where you have setting 20 different fraud alerts. But I think in a new world, people are going to expect that expectations are different. So I think one of the interesting questions is should these schemas itself be more forward looking, to remain more flexible? I think maybe this is really the spirit of your question. Uh, sorry, I came to it in a slightly long winded fashion.

Speaker B: No, it's actually not what I was angling at, but I think you're getting at something much more interesting, so please keep going.

Speaker C: But then there's also this interesting question that when we look at think about agents on data, we're all being very conservative right now. We are trying to say I want to be doing primarily reads because everyone's generally scared. Right. No one wants to have the bobby tables thing going and deleting records from our database. And we've seen the horror stories already. Bad things happen if you don't think about security and trust. So in general, I think writes are going to be a complicated, challenging space because you're not going to try to have think about how agentic applications or these ephemeral applications are going to do writes. How are they going to do schema changes? It's not fully clear to me what you need. For instance, even writes, maybe here's a proposal that when you're trying to make a change and modification to the database, you don't actually make the change. You make a proposal for a change. It's a proposed change and it doesn't actually make it right there. It may happen through some set of steps. So I think the entire way in which data has changed and schema has changed, I think is all subject to revision. Applications as we know it, I think will change, but I think the existing applications are not going to disappear overnight. Business logic, which maybe applications may be reviled, but business logic lives in applications and so we have to activate them.

Speaker B: Yeah, the data has to. You said the key thing, the data has to stay somewhere. And I think I've talked to a lot of colleagues and other people and I tend to agree with this and maybe, maybe I'm the one that's behind, but I'm certainly willing to let agents do a lot of my application code. But where I kind of draw the line is at the data model.

Speaker C: That's right.

Speaker B: Okay, you could take a cut at it, but I'm going to review the heck out of that and I'm going to make sure it makes sense to me and that I can pressure test it based on my own experience and where I think things are going to go and creative thinking and things like that. So it sounds like it's very much in line with that. All right, we already said This, I think we're both Postgres nerds, which is great. It seems like every AI startup stack is Postgres plus PG Vector. And so Google has Alloy db, which is basically like a souped up postgres. And what breaks when people try to do serious vector search on vanilla Postgres. And what did you have to change under the hood on AlloyDB to fix it?

Speaker C: There's, I think a few different parts to this one. PGvector is awesome as you put it. I think it makes it very easy to use and in fact there's a whole site thing about the Postgres ecosystem and extensions which let the experimentation go. PGvector took off. And so for many, many use cases, PGvector with the HNSW algorithm works really well. Now at Google we've been working on vector search for I guess over 15 years now. And it's at the heart of a lot of things that we do like YouTube and search and so on. And so we have this amazing technology called scan and it scales to over 10 billion vectors, delivers very much more performance in terms of latency than just hnsw. And one of the things we did was we used Scan, uh, which is a tree based algorithm and made that available inside AlloyDB. Now uh, we tried to make it look and feel like PGvector. We also offer the vanilla PGvector so that the applications shouldn't have to change and applications that work against PGA Vector will also work against cats. So that's the key part. Now there's a lot of, you know, challenging work in making that happen inside postgres and also various things that we've done on the side. How do you go build these indexes, how do you go maintain them and update them? And there are many, many reasons how we run AlloyDB with scan to really get faster performance. So in our tests we can get 6x faster vector queries than HNSW, PGvector and standard Postgres. We use 4x less memory, which anyone who's run a database knows it's kind of always a good thing because if you use less memory you can keep more for your buffer cache, which makes your performance better. But we also support things like distributed index builds. And so in general for many, many use cases. For the most demanding use cases, uh, we have a big advantage with scan. We also have support HNSW and have taken some of our improvements in SCAN and also made it available in hnsw. And the reason we've done that is

Speaker B: you've contributed it back to the libraries or is that a product?

Speaker C: I don't know what we've contributed back, but we certainly have made. We are very happy to contribute this to hmsw. I don't want to say something that's inaccurate. I'm not entirely sure if you've contributed or not.

Speaker B: Totally fair.

Speaker C: The interesting observation from us here is vector search feels a little bit like what we'd call an, uh, ensemble problem. There are different domains where there are different systems that are better. There will be probably some kinds of systems where some kind of regimes where HNSW is fine. And maybe it's a simpler approach. But what we tend to see is in the most demanding workloads, when you have high scale, you really need something like scan. But we see value in both and so we want to make sure both really work well. But I think there's a whole set of things that is more than just vector search. I think a lot of people were very focused on, hey, I want to get vector search. As you said, I have the simple stack, I get go. What we realize is what gets more interesting when people go beyond vector search. Rarely do I see people asking queries which are only a vector search system. They are more typically asking queries which involve multiple predicates. It might be vector search and another predicate on my regular table, right? Just a relational predicate. Classic example. I have a catalog and I have price. Price is a value that is in my table. And I want to ask a question which combines the two. We call this filtered vector search. And in filtered vector search, my query may have two predicates. A semantic search predicate which is on the vector index and a predicate on price as an example. Now how do you know which one to probe first? This is a classic problem in dealing with vector search. If my problem space is simple and I only have to go probe a vector, then sure, I go ask, check the vector index, get the answers. But in practice, I think what we see is this challenge that people want to ask more complicated questions. If you go probe the vector index first, maybe you get 20 results and then you apply the rest of your other predicates and none of them may be satisfied with other predicates because I say price less than $50, I get nothing, right? And then I go probe my vector index again and say, well, get me the next 20. And then I go check those next 20 and I still don't satisfy. I have to keep going down this path, right? So based on the selectivity, maybe I'm, um, better off first. Probing the non vector index and finding the set of results and then applying my nearest neighbor algorithm without even going and probing the vector index. But again, I don't know that. Suppose I probe the non vector index. Suppose I do pre filtering. What I just described was post filtering. But now suppose I instead do pre filtering and I probe the non vector index. Maybe I get a million records and then I can't go and run nearest neighbor on a million records. I have to go. That would be a bad idea. That's why you built a vector search and so no one else really managed to address this problem. In AlloyDB, we built this really amazing filtered vector search, uh, system where we are able to probe multiple indexes on the fly and figure out which is the right order in which to probe things.

Speaker B: Interesting. How does it do that?

Speaker C: I think this is an interesting point. One of the key techniques here is when you have multiple indexes and you have a query and they're all in the same system, we can actually probe both of them at the same time.

Speaker B: Okay.

Speaker C: We try to figure out quickly which is the right strategy and change it on the fly.

Speaker B: So it's a divide and conquer.

Speaker C: Yeah, it's an adaptive technique where we are trying a couple of things. It's not quite divide and conquer. You're trying a couple of things and trying to figure out which is a better fit. And we are adapting the right approach based on what your actual situation is.

Speaker B: Okay.

Speaker C: It's an interesting piece which is worth thinking about because you described one stack which startups use. There's another complete stack which is people say, oh, I'll go run a custom separate vector index, not in postgres. And that's also a path that people go. If you're doing a pure play vector search on just a corpus of text, data, whatever, that isn't changing. Maybe that's a reasonable approach. But I think again, a few milliseconds after people come up with this, queries become more complicated. As I said, developers are insanely inventive and creative people. They will find ways to do ask more complicated questions right away or AI will do it for you. Right.

Speaker B: Users are very creative too.

Speaker C: Right. So people will want to ask questions that straddle these words. Comes back to what I said. What has changed in a big way? People don't want to just look at unstructured data. People want to look at structured and unstructured data together. This all comes together. Right. So when you're asking this, I actually think it's a really poor idea to Go build a, ah, completely separate vector system because then you don't have a choice. You have to stitch these systems together at the application level and that's incredibly painful because who's going to do this pre filtering or post filtering? And unfortunately the pure play vector systems don't have a good solution here. And so when you're having multiple indexes under the control of a single system, you can do these kinds of very inventive, creative techniques that deliver tremendous value to customers.

Speaker B: Very cool. Okay.

Speaker C: And in addition to all of that, one of the uh, additional things that we are doing is we are also combining high speed vector retrieval with full text search on operational data. So that gets hybrid searches now getting interesting. So your search is not just vector and non relational, but also full text and all of these things are really coming together.

Speaker B: Wow, what a world. It's a long way from select where that's true. So let's move on to MCP servers. So you all just released, I think it's called Toolbox for Databases, MCP Toolbox for MCP Toolboxes. And I thought that was amazing. Uh, it's open source basically MCP server on top of your databases, so you don't have to roll it yourself, which is fantastic. If I'm a dev, I'm going to take the thing that Google created and assume that they did it pretty well. And you've got those manage MCP servers for Alloy Cloud, SQL, Spanner, et cetera, et cetera. So for, you know, I think most people, most audience members here are engineers on the application level. What are the possibilities here? Like what are your teams at Google doing day to day with these?

Speaker C: So, uh, you know, just to be clear, my teams at Google are building databases and building infrastructure, so they're not necessarily actually using TCP as much, but there is an area where we are and this is for our user interfaces. So we are doing some really interesting work on something we call genui or Generative ui. And here if you look at Google Cloud's managed databases, we're a humble application too. We store data in Spanner, the version of Spanner that we use inside about. You use your Google Cloud, you create instances and databases and that information is stored in the metadata system. And it used to be that anytime you built a new feature, you had to build a lot of complicated UI to help make that feature be available. One of the things that we are now doing is generating UI on the fly. And the way we're able to do that is by going and connecting to the MCP service because each of these, if you think about the ui, it's a humble application that use the uh, underlying API servers. And now what we figured out to do is based on what users are asking, we're able to generate UI on the fly by connecting to these MCP servers. So this is an example of something that my teams are doing right and we think it's really exciting because it's not just about saving time. It's about creating these artisanly crafted user experiences based on what someone wants. We can deliver something that is really awesome for them. So I think that is really interesting. Now from an actual customer's perspective, I think there's, you know, as you said, there's both. You can use Toolbox, you can use our managed MCP services. I think you'll see different kinds of use cases. The best thing about our managed MCP services is that it's uh, got, it's enterprise grade, it's got governance, it's got all the bells and whistles. And so you know, a lot of customers will absolutely use it, will gravitate to it. And I think it's great. I think it's also true that there's a set of developers who are on the bleeding edge. They will be needing more and that's why we started building MCP Toolbox to really learn what developers need and they uh, need a whole bunch of things. For example they need custom authentication mechanisms. They may be running in their own on premises environment. We're not using Google Cloud. And so our problem statement when we set out to build MCP Toolbox was how do you make it easy for developers to connect to databases irrespective of where they are? As I said, part of the agentic data cloud mission is openness. So we want to solve for people no matter where they are, they can be on their data center and other cloud. We want to make it really easy to, as I said before, activate operational databases in agentic applications. Now when they are in the Google Cloud environment, we also want it to be a very easy environment. And that's where you have managed MCP services, right? And so things like the Genui application that my team has built is a great example of using those managed MCP services. But it could be various other things. I think classic examples on the control planes. I am a uh, SWE who is relying on a bunch of AI agents and these AI agents need to go create databases, run, deploy applications for all of that. These managed MCP is perfect because it just directly connects to the control plane and so on and so forth. But there are also things like custom tools that we have where custom tools that people often are using in the world of MCP where they're not just issuing execute SQL where they may be doing something like search for a flight and that might be a custom tool someone might write and that tool ends up going and runs a specific query, select star from flight stable, things like that. And so for scenarios like that, McPToolbox I think is great. I think what you'll see in general is each of these pieces of functionality that we are learning by working with customers in MCP Toolbox. If it's valuable, it'll also make it to managed mcp. Right. And so one way of thinking about this, it's open source. We want to be where people are doing things. We want to learn from our customers, from developers and based on what we are learning that influences the roadmap of managed MCP. Both are valuable.

Speaker B: Very cool. The GenUI stuff, is that something that's also. Is that internal to Google? Is that something that is widely available?

Speaker C: I think we have some version of it for observability in our consoles. We already have it available like I don't think it's called that. I might have talked out of turn and used an internal project code name. I don't think we give it a name. It's just part of the user experience in our database. Uh, console. Yeah, that certain kinds of things we are having.

Speaker B: The reason I ask is it's a very interesting. So you know we had that conversation earlier about metadata in the context of data. Right. Like the MCP server can help expose that and make sense out of it. And to be able to kind of, I guess on the fly create a UI is a really, really interesting thing.

Speaker C: Powerful.

Speaker B: Maybe that could be a follow up or something like that. But if those two things paired, the average application developer would have quite a pair there to say like inspect the data and show something based on what we found.

Speaker D: Correct.

Speaker C: I think our own observation was if you looked at our UI infrastructure, we had a bunch of widgets that did various kinds of things. And so if you were. What we were pairing up was the managed MCP services for the underlying systems and the ability packaging up those UI widgets also in some kind of MCP tool. Now you have an AI model that's able to say I want to combine these things and put them together. That's an example. But you're absolutely right. Ah, you know what we did. Any customer can do exactly that kind of work. I think the little bit of the trickiness always comes back to well, what is read, what is write, how ready are you to go and let agents go write onto the operational database.

Speaker B: Just to correct myself, I searched there. I had heard of GENUI before and I wasn't sure. So that is an architectural pattern. If you look it up like I would encourage audience members to look it up at least I think it's just an audio um, pattern. Yes. And there's different implementations of it. There's an ecosystem is fascinating and I think paired with that MCP toolbox something very interesting. So.

Speaker A: All right.

Speaker B: Okay. So an LLM with a live connection to your production database. It's great horror story waiting to happen. How do you, you with all this knowledge of database, how do you think about how to control the blast radius for something like this? We just led into this about talking about being careful with rights. What do you think is non negotiable before anybody puts an agent towards prod. And like not obvious stuff like least privilege and things like that, but the stuff that really kind of keeps you up at night and that you're thinking about and that you want people to know to avoid maybe some anonymizing horror stories from clients or customers or something like that.

Speaker C: I'll uh, talk about two or three different things. One of them I think is a particularly interesting challenge. When you're trying to. If you think what you want to do is have an LLM or an agent, generate a SQL query on the fly and go against your operational database as a classic thing, hey, wouldn't that be an obvious win? Here's an interesting challenge. If you're connecting to an analytics system, your Persona is maybe a business analyst or a data scientist. The analytics systems. Forget AI today. If a business analyst is connecting to your analytics system, they're connecting as with their credentials. And there is access control typically built into the analytics system itself. These business analysts also typically have wider access to data. The nature of these kinds of BI queries are uh, aggregate queries. It's a very different world for operational databases. In fact it didn't used to be that different. In the early 90s when you had client server applications, when you had clients which would take clients that would connect to the database. But with the web with three tier architecture, maybe late 90s, that changed fundamentally. So for an operational database, the end user's credentials are not actually part of the operational database schema. Databases have users and roles and groups and privileges, but the end user's information is not there. And I think one reason is because with the web the number of end users went from hundreds to thousands, millions, hundreds of millions. So you can't really manage the data that way. And so with the web with three tier applications, you have the application connecting to the database as a service principle and figuring out what an individual logged in user can actually access using where clauses in SQL queries that are scattered in the application. That's the state of the world. If you want to have let's say an end user and by the way, this could be an internal user or it could be an external user. Let's say you are in a um, car rental company. You have, I don't know, 2000 branch offices locations and each of them has a manager who can ask questions about the system. Now obviously security is important. They're allowed only to ask questions, maybe about cars in their store, not about something else. Or maybe they can, or maybe they can't. You can't just let the uh, agent go ask questions on behalf of any user when that agent effectively has a service principal access to all of the data. So you have to solve this problem. There's just no solution, no way out. We have a solution. We've built something called parameterized secure views. And this builds on some really awesome poster schoolness. And now we're bringing it to all our database portfolio. Postgres has something called secure views. So you can define a secure view and that has a very interesting property called a security barrier. And with a security barrier it makes sure that you cannot engage in an information theoretical attack to extract information. The basic idea is when you have this kind of an attack is to say write a query which will crash the system. You write a query with uh, divide by zero with a where clause. And if you don't have a security barrier, the postgres optimizer will be too smart, will push this predicate deep into the system. And if you don't find anything or you find something, you may end up not getting a result or it'll crash the system or you'll get some error. And that error will tell you lack of information is something that's valuable for you, right? It'll actually tell you that. And so postgres security barriers prevent that from happening because it will make sure no predicates can be pushed inside the table. Now a parameterized secure view takes us to the next level where you can apply a parameter. Now the kind of parameter that you might apply in the where clause here is essentially the same check for Authentication the uh, authorization authorized access which I mentioned is there in three tier web applications and where clauses and SQL queries scattered to the application. But we take that essentially from the application logic and you define that in your ddl uh, for this parameterized secure views. So now you have your PSVs defined for your schema and when the agent calls, the agent is part of some orchestration system. There's a logged in user, the orchestration ends up calling the LLM and getting the SQL query. And you can attack the LLM, you can convince the LLM, spoof it, you can generate whatever query you want, but when that query gets sent it only has access. It's a special service principle for the agent. It only has access to the PSVs, to the parameterized security so it doesn't have access to the underlying tables that is easy to put in. And we take that logged in user's credential and have it as a side channel. It's bound to the underlying parameter so the query can have whatever it wants but the view is on the fly only restricted to the user's credential. So it's a very important piece, critical piece of infrastructure. Without it there's no way to get the kind of security you need for agentic applications.

Speaker B: So that I uh, don't know if we call it role based access but that user based access is stored alongside the data or managed alongside the data I guess maybe is the right.

Speaker C: Effectively what we're saying is don't change. You don't need to put roles inside the database, but you can take what was written as a query in the application and put it into the ddl. Now you can let the LLM do whatever the heck it wants.

Speaker B: I see.

Speaker C: We can still guarantee that you don't access. One of the papers I read when I started my PhD program in Berkeley was a classic paper from 1975 called the End to end argument in system design. It's a fascinating paper. It basically says something like if you have any kind of distributed system and whether you want to do encryption or security, you need to solve this at the edges of the system on the ends, you cannot solve it in the pipes. And that's a really interesting design primitive and that's really the same primitive, the end to end argument is you need to have security right at the level of the data because we are living in a non deterministic world where agents and other things can do anything. So I think this is one of the most important pieces in this whole topic of hey, LLM with access to production databases. There's another interesting topic here, which is isolation. It's very similar to the set of problems with analytic systems. Analytic queries on your transactional database. When you go run your analytics, if you run batch scans on your transactional database, you can impact your transactional database, which is one of the reasons why people offload sometimes data from the transactional database. And so we've done a lot of work over the years, done isolation and figured out how to solve this problem. Talking, uh, about horror stories. I was talking to a customer in a bank, uh, about these things like PSVs, and the customer said, what are you talking about? We just spent years making sure batch scans can't run against your operational databases. Do you want me to run agents now on it? Have you gone out of your mind?

Speaker B: Right.

Speaker C: It's a totally valid question. Right. You have agents and agent swarms that are asking questions. But I think the same lessons apply. Just like we learned how to isolate transactional databases, we need to be able to isolate agentic applications. I think some of the things, it can be worse because it's not easy to control the agents. Agents can run bad queries, agents can run malicious queries. So I think the lessons that we've built, we've taken from building transactional analytical systems actually apply to this world. And then other things. I think we need to have the right observability. You need to have the observability that tell you even little things. Can you look at your postgres database and say, give me the list of queries that came from an agent versus from the application. You need to build those kinds of guardrails around, uh, this.

Speaker B: Yeah, it's almost like a little bit of real time threat detection for what's happening to your data.

Speaker C: Exactly.

Speaker B: That's fascinating, the comparison against how. Because I mean, I've never even really, you know, I come from an era where I always just had transactions and it wasn't always that way, was it? Right. Like. And they had to learn that. Wow, that's fascinating. Okay, let's close it out. I got two closers for you. And I try to make the closers kind of something that folks can reflect on their own roles. So you have said in the past that Google engineers can use AI as heavily as they want, but whoever commits to code owns it. Said that something like 3/4 of new code is now AI generated at Google. How is that actually playing out on your teams? And I think for your database teams, like what is the database engineer of. Let's say a year from now, two years from now, spend their day doing. What do you think?

Speaker C: Look, honestly, I don't know what uh, will happen three months from now, but me either.

Speaker B: I was hoping you could tell me.

Speaker C: Certainly I think things have changed enough that uh, if people had priors from six months back, they should at least revisit what is possible and what is not. So a lot more is possible. I think these, you have to be careful numbers because they vary so much based on kind of what we're talking about. My gut sense is if you're talking about something like the distributed consensus protocol, that's Paxos technology. That's the heart of Spanner. My gut is that that's actually probably still quite hard for an AI agent to directly go and change in a big way. And we'd be very, very careful about it. But when we say AI is code is generated, it means so many different things from refactoring code all the way to maybe code commit. Where in the extreme. So on the one side it's just simple refactoring of code and the other extreme is I have a whole piece of PR with a, uh, self contained unit of code where the person who built it did not even enter an ide, right? Did not enter Emacs or vi. So that is, I think one extreme. The other extreme is I'm in the ide, I'm just doing routine refactoring. And there's a whole continuum of steps between these. And so I think what you'll see right now today is a lot of variation, that there'll be areas where I think you'll see a lot more success and areas where you see less success. What we work with, our teams, I think this is probably useful for most people because of a lot of variance. I think it's very important to build the right harnesses and skills for each work group, each whatever group of engineers working on some coherent whole. And so like everything in the world of AI and agents, I think the key is evals. You need to have a really good objective way of knowing is this thing mostly working or is it not working? And so I think it's very important to continuously measure and figure out what the reality is. And another thing I think that is particularly important is the space for experimentation. I think it's really valuable to have pick a project, pick something which you go and say, I'm going to focus on pushing the boundaries of what I can get with AI. And when you hit the obstacles and the roadblocks which you will. I think the engineer's imperative, and the right imperative normally would be, uh, hit a bottleneck. I'm just going to drop down to the way I normally do it. Go solve the problem. Because that's what we're asking, right? Solve the business problem. But I think we need to have some set of efforts where we say, when you hit the bottleneck, fix the bottleneck, don't go around it and accept that it'll take longer to deliver. So I think these are some of the things that we do which I think are probably more, uh, useful in general.

Speaker B: All right, last one. What is the one piece of advice you want our audience to take away from today? I know I'm going to be thinking about data level authorization thing, but what do you want folks to walk away with today?

Speaker C: You know, we've spent the last 25 years learning how to build deterministic, scalable systems. Being deterministic, being predictable is such a big part of what, how we've learned to build systems. We, uh, take it as an article of faith. I think we are living in a fundamentally different era. And in this era we, uh, we need, as systems people, as thinkers, as implementers, as practitioners, we need to be ready to deal with the world where data is messy, where it's not deterministic anymore. And in some sense, I think most people who are engaged in this exercise have to go through what is this, stages of grief, bargaining all the way to acceptance. And they're somewhere in that stage where your first people start fighting about, how do I make it deterministic, how do I make this AI thing deterministic? I think that's not a successful path, and that's not the right path. And I think, I think most people

Speaker B: hit it and they hit it fast. Yeah, correct.

Speaker C: I think we have to embrace the chaos. And that means putting ourselves in this kind of weird spot. Right. It's not how we've trained ourselves as an industry for. We're talking probably two generations of software engineers who've learned how to build things in this way. And so we have to accept that we are in a world of chaos and live with that chaos. And as part of that, I think evolves. Just what I said a few minutes before. How we operate in software engineering applies to the kinds of systems we build. And I want to tie this back to where you started. You talked about what has changed. I think the fundamentally big thing that's changed for my area databases is that we're dealing with structured and unstructured data together that we are talking about. We're trafficking not in exact results, but the most relevant results. And so being able to have evals to understand the quality and the business outcomes, I think is a very big part of how you can embrace the chaos and actually make sense of it.

Speaker B: Yeah, that's something that I'm learning, too, is there's no longer a right or wrong answer. There's a spectrum of relevance. I think that that's.

Speaker C: Yeah, that's right. And we are all somewhere in that.

Speaker B: We're all just floating in the chaos of relevancy. This was fascinating. I really enjoyed this conversation. It fulfilled all of my database nerd dreams. So thank you for being here.

Speaker C: Thank you for the opportunity. I, uh, always love geeking out.

Speaker A: Sam.