Inside Google’s Database Infrastructure for the AI Era

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 exact. 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. Sailesh Krishnamurthy https://www.linkedin.com/in/saileshkrishnamurthy/ is a VP of Engineering at Google https://www.google.com/, and in this episode he joins Matt Merrill to discuss his background, how databases have evolved over the past fifty years, and where the field is heading as AI reshapes how data is queried, structured, and trusted. Sponsorship inquiries: [email protected] mailto:[email protected] The post Inside Google’s Database Infrastructure for the AI Era https://softwareengineeringdaily.com/podcasts/inside-googles-database-infrastructure-for-the-ai-era/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  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 exact. 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. Silek Krishna-Murthy is a VP of Engineering at Google, and in this episode, he joins Matt Merrill to discuss his background,

• 0:45Speaker 00

  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 backend development, cloud architecture, and distributed systems design. He currently architects and delivers software products and leads a team of engineers at Deft Agency. You can learn more about his work at code.theothermattm.com.

• 1:34Speaker 01

  All right. 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, Silek Krishna-Murthy. 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 incredible. 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.

• 2:00Speaker 02

  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. I worked at IBM, worked on DB2 and enterprise databases. And then I did something a little crazy. I decided I liked 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.

• 2:42Speaker 02

  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. And I was there for about five years, and I came to Google in 2019, and I've been there since.

• 3:00Speaker 01

  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?

• 3:11Speaker 02

  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 classic MySQL, managed MySQL, part of RDS and other systems.

• 3:25Speaker 01

  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?

• 3:33Speaker 02

  Database is probably the only thing I know at this point, but yes. I like to say I 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 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.

• 4:18Speaker 02

  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 want to do.

• 4:55Speaker 01

  Absolutely.

• 4:56Speaker 02

  If they had their brothers, they would like to modernize every single system, but sometimes you just can't.

• 5:01Speaker 01

  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.

• 5:10Speaker 02

  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.

• 5:16Speaker 01

  Oh, boy. Okay. Just a little thing. Just run the databases for Alphabet. Okay. Just so folks know, how long have you been at Google now?

• 5:24Speaker 02

  About seven years, basically.

• 5:26Speaker 01

  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 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?

• 5:46Speaker 02

  You know, there's, 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. And this stayed true for a remarkable amount of time, right? For all these 50 years of databases. In fact, it's interesting. The couple of years back, I was giving a talk at Berkeley, my alma mater. I think it was on May 5th or something in 2024. And I became curious. I wanted to, I was wondering when the original 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.

• 6:29Speaker 02

  And so it's easy to forget, but this remarkable industry, this 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.

• 7:11Speaker 02

  Try to build systems where you have declarative interfaces, where people can ask what they want, and the system focuses on producing it. System, make 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 the 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, right? So all of these are deeply connected.

• 7:53Speaker 02

  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.

• 8:38Speaker 02

  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 are innovators, and so they are demanding a lot more from these systems. There's been a lot of experimentation. There's been, you know, 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.

• 9:21Speaker 02

  And these set the tone for a whole industry 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're seeing is it's not just about producing exact results on exact data. What we're 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.

• 10:06Speaker 02

  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 to 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.

• 10:41Speaker 01

  As you started 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, but.

• 11:13Speaker 02

  I mean, there are 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.

• 11:32Speaker 01

  That's a good lead in to spanner. So if I'm being honest, I don't know much about spanner, because 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.

• 11:55Speaker 02

  First, I just want to preface that Postgres is amazing. I love Postgres.

• 11:58Speaker 01

  Me too.

• 11:58Speaker 02

  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, the evolutionary systems, people came at the problem space

• 12:42Speaker 02

  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 the big table, 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.

• 13:25Speaker 02

  In fact, the origin story for spanner goes in Google. The ad system used to run on sharded MySQL, because when, you know, it ran on MySQL, because it was so big, you had to shard it. And so that was a complicated process. And it's roughly to 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. And 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, you know, this was a hamster wheel that they had to get off. And at that point, Google leadership, again, as I mentioned before, the amazing things about Google was take those big bets, decided this cannot stand, we've got to do something better.

• 14:10Speaker 02

  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 to build spanner to solve this problem, that you wanted the functionality

• 14:55Speaker 02

  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 built spanner. Now, you asked a slightly different question, though. You asked, hey, what should I reach to, you know, when I was used as an every day developer? And I think if what you're trying to do is something that will run in a single node, you know, 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.

• 15:38Speaker 02

  Sometimes they need global resiliency, they need to have a 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 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'd say that's probably, we're just a little ahead of the times there. If you look at Postgres's 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.

• 16:20Speaker 02

  They are seeing this emergence, going back to inexact processing, structured and unstructured data coming together. That's the need for AI. And so in terms of that kind of functionality, I think you'll 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 spanner.

• 16:43Speaker 01

  Nice.

• 16:45Speaker 00

  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 at fingerprint.com.

• 17:26Speaker 03

  You're listening to Deepgram Flux TTS. Different voices, same model, all ready to speak.

• 17:32Speaker 04

  Flux TTS is a streaming text-to-speech model built for voice agents.

• 17:36Speaker 03

  Flux reads the room. It holds context across the conversation, turn after turn.

• 17:41Speaker 04

  With consistent tone, interruption handling.

• 17:43Speaker 05

  And plenty of personality.

• 17:45Speaker 03

  So your agents keep it flowing and customers can just keep talking.

• 17:49Speaker 04

  Try Deepgram Flux TTS free now until September 12. Visit deepgram.com/keeptalking. Terms apply.

• 17:56Speaker 06

  This episode of Software Engineering Daily is brought to you by WarpBuild. 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. WarpBuild makes GitHub Actions twice as fast at half the cost with a one-line change to your workflow. Linux, macOS, and Windows runners in WarpBuild's cloud or your own, enterprise-ready, SOC 2 Type 2 attested, and trusted by teams like Sky from Comcast, Bitcoin, and Brain Trust AI. Get started with $50 in free credits at warpbuild.com/sed.

• 18:34Speaker 01

  Okay, now that all makes sense. And then there's just released spanner Omni, which lets people run this on prem.

• 18:42Speaker 02

  That's great.

• 18:42Speaker 01

  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?

• 19:04Speaker 02

  The engineering work that went into building spanner Omni is really actually an inspiring story in its own, right? We've taken runs of this problem before, 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're 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 of 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

• 19:48Speaker 02

  are banks, 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 and some jurisdictions mandated that you need to run in a world where you also have the optionality to run in their data center. If for a stress exit scenario, one customer of mine who works at a bank was telling me when they were moving a traditional, you know, legacy system, and he was complaining to me about the regulator's position, he said, I know that I'm 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, whether it's a single

• 20:32Speaker 02

  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, right, it doesn't, why should I, everything is better, why?

• 20:47Speaker 01

  The regulations always have to catch up with tech, right?

• 20:50Speaker 02

  Yeah, so, right. To be fair, I think I can understand the regulator's positions. I think you'll see a lot of different positions 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

• 21:33Speaker 02

  that have happened here. One, it used to be that it was 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 a few weeks back,

• 22:17Speaker 02

  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, and in other clouds

• 22:59Speaker 02

  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, 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 to operate it, as you would imagine, there's lots and lots of different microservices, different piece parts, different things that we run separately. And, you know, 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, right? You could not expect

• 23:42Speaker 02

  people to so 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. 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. It may sound simple, but it was actually, as you might imagine, a really hard thing to do.

• 24:09Speaker 01

  Oh, the simplest things are often the hardest, right? So I think that's incredible.

• 24:14Speaker 02

  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 is so key to how we operate inside Google.

• 24:36Speaker 01

  What is that, like a raw storage item? I'm not familiar with it.

• 24:38Speaker 02

  It's a storage system, basically, right? It's a distributed storage system, and it's a zonal service, and the spanner depends on it. One of the reasons spanner and Big Table 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 everyone 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 keeps copies of data, and then they said copying the data back and forth when they have load. So we had to model how we deal with storage. And so there's a whole bunch of innovation and clever tricks that we came

• 25:19Speaker 02

  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, and having a globally replicated system, is to tame time. And so in order to make transactional semantics work, to make distributed transactions work, it's very important to be able to reason about time. And 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. And spanner's transaction semantics essentially depends on what the delta is. And we are able to impose things

• 26:04Speaker 02

  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 spanner 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. And so the state of the world in 2025, 2026

• 26:49Speaker 02

  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 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, you know, come to Jesus moment, right? 2012 is when spanner went production inside Google for the ad system.

• 27:27Speaker 02

  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 through time 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,

• 28:11Speaker 02

  it'll do just fine. That's the secret sauce.

• 28:14Speaker 01

  That makes a lot of sense. So basically what I'm hearing is, so especially with true time, 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.

• 28:34Speaker 02

  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 something like that. And 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 stop. 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 because the work my colleagues have done over the

• 29:15Speaker 02

  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 lapse researcher, leave aside my role as a Google employee, I think that's a good thing for the industry at large.

• 29:31Speaker 01

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

• 29:45Speaker 02

  Lot of C++ code, yes. A lot of it is primarily C++ code.

• 29:49Speaker 01

  All right. Cool. All right. Good old fashioned C++.

• 29:52Speaker 02

  Maybe AI will help us write it all in Rust or something. I don't know.

• 29:56Speaker 01

  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?

• 30:19Speaker 02

  It's a great question. It really gets to how to 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 just, you don't actually move the data, you just start querying it like a graph. It's amazing. It's really, really, really powerful.

• 30:51Speaker 01

  It was like a graph view.

• 30:53Speaker 02

  Essentially, 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're viewing it with a graph prism, maybe you ask questions differently. You ask questions around traversing the system. By the way, it's still declarative. Their 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 talk about algorithms in a second, some of them, infrastructure, right? You have ports and network switches and things like that. And

• 31:38Speaker 02

  you want to connect them. But a lot of use cases often come 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. Customer 360 is something that is very big. That's a very big graph use case. You have, you know, 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

• 32:20Speaker 02

  that. But tipping aside, I think the biggest interesting thing is you don't, you can ask more complex questions on the data in your transactional database without running a messy ETL pipeline. Look, 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. And 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 like a beast. But then what we started seeing was again, a

• 33:04Speaker 02

  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 a 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.

• 33:49Speaker 02

  If I have to keep moving the data of my operational system to another system and run it, scanners 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, you know, there are 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

• 34:30Speaker 02

  out what are those sets of related people, right? What are these communities? It's, what are the clustering things that you're trying to do? And once you detect these suspicious clusters, some of them may be suspicious, some of them may be not, you can now, 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 webpages, it's actually really very, very good at 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

• 35:13Speaker 02

  space. So I think this is a kind of a great, 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, DanaPay, it's an Indonesian digital payment solution. And 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 analytic system, but if I can

• 35:57Speaker 02

  flag and block the transaction, I can prevent financial losses and really, you know, 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 spanner deliver exactly that.

• 36:22Speaker 01

  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.

• 36:37Speaker 02

  Right, right. And yeah, it just makes it easier. I think SoundCloud, for instance, they're running graph algorithms and Batchmore for years. I mean, a lot of the 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 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'll find things that we didn't even anticipate.

• 37:04Speaker 01

  I think it's fascinating, something that 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.

• 37:24Speaker 02

  Indeed.

• 37:24Speaker 01

  So we'll 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?

• 38:02Speaker 02

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

• 38:12Speaker 01

  I think I remember that one. Yes.

• 38:15Speaker 02

  It's a very interesting question you're asking. And I think. And just to be very candid, I don't think we know everything that is going to change. It's changing very fast with AI. Having said that, there's an enormous amount of applications, bespoke applications of the self applications. 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 a 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,

• 38:58Speaker 02

  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 alloy DB 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.

• 39:43Speaker 02

  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 DB two, almost thirty 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. It seemed like a

• 40:21Speaker 01

  Extraneous.

• 40:22Speaker 02

  Theoretical thing or something.

• 40:24Speaker 01

  Yeah.

• 40:24Speaker 02

  Now that kind of stuff is actually interesting because it now tells you, you know, 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 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 on the schema? I'll give you a very simple example. If I have a table with a billing address and the shipping address, it'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 L L Ms to activate your operational databases, and I think before even think about new greenfield applications,

• 41:08Speaker 02

  this is, you know, the pressing need to light up those databases. You need to have the metadata on more than the metadata, 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 L L M 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 three letter airport codes? So again, this information about the data is super important. Now, I think so one stream is yes, schema and context.

• 41:51Speaker 02

  Schema is important, what's more important is context, right? I think that's the first thing. 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 Deep Mind with AI Studio, where you can go and say, when I'm billing an application in 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, the AI will decide. We are just actors on the stage, I guess.

• 42:34Speaker 02

  So in things like that, this is 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 is 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

• 43:19Speaker 02

  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 and API surface area. I think we're going to see a new world where applications are ephemeral workflows. The application asset doesn't exist. You know, maybe today, 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. Well, what would they have done in the past? Well, maybe they had to find a contract with large system integrator, paid a lot of money.

• 44:01Speaker 02

  We have got some results after six months, you know, whatever it is, right? But now in this new world, they're just going to ask the AI to go do something. So now, where is 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 world, you might call your bank and say, I want a fraud alert. I want one week in Vietnam, next week in Laos, the next week in Cambodia.

• 44:46Speaker 02

  Well, the bank's system is probably going to choke because people who designed the system didn't think about the world where you have setting twenty different fraud alerts. But I think in a new world, people are going to expect that. Expectations are different. So I think, you know, one of the interesting questions is should these schemas itself be more forward looking? Do they remain more flexible? I think maybe this is really the spirit of your question. Sorry, I came to it in a slightly long winded fashion.

• 45:11Speaker 01

  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.

• 45:18Speaker 02

  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 a database. And we've seen the horror stories already. Bad things happen if you don't think about security and trust really well. So in general, I think rights are going to be a complicated, challenging space because you're now going to try to have, think about how agentic applications or these ephemeral applications are going to do rights. How are they going to do schema changes? It's not fully clear to me what you need.

• 45:56Speaker 02

  For instance, even rights, 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, you know, actually make it right there. It may happen, you know, through some set of steps. So I think the entire way in which data has changed and schema has changed, I think it's 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, you know, maybe application may be reviled, but business logic lives in applications. And so we have to activate them.

• 46:35Speaker 01

  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 that the data model.

• 46:56Speaker 02

  That's right.

• 46:57Speaker 01

  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, so 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. What breaks when people try to do serious vector search on vanilla Postgres? And what did you have to change under the hood on Alloy DB to fix it?

• 47:36Speaker 02

  There's, I think, a few different parts to this. One, PG Vector is awesome, as you put it, right? I think it makes it very easy to use. And in fact, you know, there's a whole side thing about the Postgres ecosystem and extensions, which let the experimentation go and PG Vector took off. And so for many, many use cases, PG Vector with the H N S W algorithm works really well. Now, at Google, we've been working on vector search for, I guess, over fifteen 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.

• 48:15Speaker 02

  And it scales to over ten billion vectors, delivers very much more performance in terms of latency than just H N S W. And one of the things we did was we used Scan, which is a tree based algorithm and made that available inside Alloy DB. Now, we tried to make it look and feel like PG Vector. We also offer the vanilla PG Vector so that the applications shouldn't have to change and applications that work against PG Vector will also work against Scan. 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.

• 48:59Speaker 02

  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 alloy DB with Scan to really get faster performance. Like so in our tests, we can get six X faster vector queries than H N S W, PG Vector and standard Postgres. We use four X 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.

• 49:41Speaker 02

  We also have support H N S W and have taken some of our improvements in Scan and also made it available in H N S W. And the reason we've done that is.

• 49:50Speaker 01

  You've contributed it back to the libraries or is that that a product?

• 49:55Speaker 02

  I don't know what we've contributed back, but we certainly have made the, we are very happy to contribute this.

• 50:00Speaker 01

  Oh, yeah.

• 50:00Speaker 02

  H N S W. I don't want to say something that's inaccurate. I'm not entirely sure if you've contributed or not.

• 50:06Speaker 01

  Totally fair.

• 50:06Speaker 02

  The interesting observation from us here is vector search feels a little bit like what we'd call an 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 H N S W 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 going.

• 50:48Speaker 02

  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 relation 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.

• 51:34Speaker 02

  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 here, 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 twenty results and then you apply the rest of your other predicates. And none of them is maybe satisfied with the other predicates because I say price less than fifty dollars, I get nothing. Right? And then I go probe my vector index again and say, well, get me the next twenty. And then I go check those next twenty and I still don't satisfy. I have to keep going down this path, right?

• 52:17Speaker 02

  So based on the selectivity, maybe I'm 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 the vector search. And so no one else really managed to address this problem. In our I D B, we built this really amazing filtered vector search 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.

• 53:02Speaker 01

  Interesting. How does it do that?

• 53:05Speaker 02

  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.

• 53:17Speaker 01

  Okay.

• 53:17Speaker 02

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

• 53:22Speaker 01

  So it's a divide and conquer?

• 53:23Speaker 02

  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.

• 53:37Speaker 01

  Okay.

• 53:38Speaker 02

  Right? 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 postress.

• 53:51Speaker 01

  Yeah.

• 53:52Speaker 02

  And that's also a path that people go. If you are 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. Our A I will do it for you, right?

• 54:18Speaker 01

  Users are very creative too, you know?

• 54:20Speaker 02

  Too, right?

• 54:20Speaker 01

  Yeah.

• 54:21Speaker 02

  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 completely separate vector system because then you don't have a choice. You have to stitch these systems together at the application level, right? 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.

• 55:05Speaker 01

  Very cool. Okay.

• 55:07Speaker 02

  And in addition to all of that, one of the other additional things that we're doing is we're also combining high-speed vector retrieval with full text search on operational data. So that gets, hybrid search is 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.

• 55:27Speaker 01

  Wow, what a world. It's a long way from select where.

• 55:31Speaker 02

  That's true.

• 55:33Speaker 01

  So let's move on to M C P servers. So you all just released, I think it's called Toolbox for databases.

• 55:39Speaker 02

  M C P Toolbox for.

• 55:41Speaker 01

  M C P Toolboxes.

• 55:42Speaker 02

  Yeah.

• 55:43Speaker 01

  And I thought that was amazing. Uh, it's open source, basically M C P 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 managed M C P 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?

• 56:16Speaker 02

  So, you know, just to be clear, my teams at Google are building databases and building infrastructure. So they're not necessarily actually using M C P as much, but that is an area where we are. And this is for our user interfaces. So we're doing some really interesting work on something we call G N U I or generative U I. And here, if you look at Google Cloud's managed databases, we're a humble application too. And we have, we store data in Spanner, the version of Spanner that we use inside, right? About you use your Google Cloud, you create instances and databases. And that information is stored in the metadata system.

• 56:56Speaker 02

  And it used to be that any time you built a new feature, you had to build a lot of complicated, you know, U I to help that make that feature be available. One of the things that we are now doing is generating U I on the fly. And the way we're able to do that is by going and connecting to the M C P servers. Because each of these, if you think about the U I, it's a humble application that use the underlying A P I servers. And now what we figured out to do is based on what users are asking, we're able to generate U I on the fly by connecting to these M C P servers. So this is an example of something that my teams are doing, right? And I think it's really exciting because, you know, it's not just about saving time.

• 57:39Speaker 02

  It's about creating these artistically 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 M C P services. I think you'll see different kinds of use cases. The best thing about our managed M C P services is that it's got, it's enterprise clear, 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, I think it's great. I think it's also true that this set of developers who are on the bleeding edge, they will be needing more.

• 58:20Speaker 02

  And that's why we started building M C P Toolbox to really learn what developers need. And they need a whole bunch of things. For example, they need custom authentication mechanisms. They may be running in their own on-premises environment, they're not using Google Cloud. And so our problem statement when we set out to build M C P 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. And so we want to solve for people, no matter where they are, they can be on their data center and another cloud. We want to make it really easy to, as I said before, activate operational databases in Agentic applications.

• 59:03Speaker 02

  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 M C P services, right? And so things like the G N U I application that my team has built is a great example of using those managed M C P services. But it could be various other things. I think classic examples on the control planes. I'm a Sui who is relying on a bunch of A I agents. And these A I agents need to go create databases, run deploy applications. For all of that, these managed M C P is perfect because it just directly connects to control plane and so on and so forth.

• 59:41Speaker 02

  But there are also things like custom tools that we have where custom tools that people often are using in the world of M C P, uh, 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 flights table, things like that. And so for scenarios like that, M C P Toolbox, 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 M C P Toolbox. If it's valuable, it'll also make it to manage M C P. Right?

• 1:00:24Speaker 02

  And so one way of thinking about this is open source. We want to be what, 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 M C P. What are valuable?

• 1:00:39Speaker 01

  Very cool. The G N U I stuff, is that something that's also, is that internal to Google? Is that something that is widely available?

• 1:00:49Speaker 02

  I think we have some version of it for in observability in our consoles. We already have it available. I 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 it's just part of the user experience in our database console.

• 1:01:06Speaker 01

  Yeah.

• 1:01:06Speaker 02

  That certain kinds of things we are having.

• 1:01:08Speaker 01

  The reason I ask is it's a very interesting. So, you know, we had that conversation earlier about metadata and 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.

• 1:01:26Speaker 02

  Powerful.

• 1:01:27Speaker 01

  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.

• 1:01:39Speaker 02

  Correct. 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. 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 right?

• 1:02:23Speaker 02

  How ready are you to go and let agents go right on to the operational database?

• 1:02:29Speaker 01

  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 I would encourage audience members to look it up. At least I think it's just an audio pattern. Yes, and there's different implementations of it. There's an ecosystem. It's fascinating and I think paired with that MCP toolbox is something very interesting. So, all right. Okay, so

• 1:02:55Speaker 01

  an L L M with a live connection to your production database. It's a great horror story waiting to happen. How do 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 lease 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 anonymized horror stories from clients or customers or something like that.

• 1:03:32Speaker 02

  I'll talk about two or three different things. One of them, I think, is particularly interesting challenge when you're trying to, if you think what you want to do is have an L L M or an agent generate a SQL query on the fly and go against your operational database, right? As a classic thing, hey, wouldn't that be an obvious win? Here's an interesting challenge. If you have, if you're connecting to an analytic system, your persona is maybe a business analyst or a data scientist. The analytic systems, forget AI today. If a business analyst is connecting to your analytic system, they're connecting as with their credentials. And there is access control typically built into the analytic system itself.

• 1:04:16Speaker 02

  These business analysts also typically have wider access to data. The nature of these kinds of BI queries are aggregate queries. It's a very different world for operational databases. In fact, it didn't used to be that different in the early nineties when you had client server applications, when you had clients which would pick lines that would connect to the database. But with the web, with three tier architecture, maybe late nineties, 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.

• 1:04:56Speaker 02

  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 principal 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. You, let's say you are in a car rental company.

• 1:05:37Speaker 02

  You have, I don't know, 2,000 branch offices, locations, and each of them has a manager who can ask questions about the system. Now, obviously, security is important. They are allowed to only ask questions maybe about cars in their store, not about something else. Or maybe they can, or maybe they can't.

• 1:05:56Speaker 02

  You can't just let the 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 no solution, no way out. We have a solution. We've built something called parameterized secure views. And this builds on some really awesome Postgres coolness. 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.

• 1:06:38Speaker 02

  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 a divide by zero with a where clause. And if you don't have a security barrier, the Postgres optimizer will be too smart. It 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's security barriers prevent that from happening because it will make sure no predicates can be pushed inside the table. Now, parameterized secure view takes us to the next level where you can apply a parameter.

• 1:07:23Speaker 02

  Now, the kind of parameter that you might apply in the where clause here is essentially the same check for authentication. The authorization authorized access, which I mentioned, is there in three tier web applications in where clauses and SQL queries scattered to the application. But we take that essentially from the application logic and you define that in your D D L for this parameterized secure views. So now you have your P S Vs 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 L L M and getting the SQL query. And you can attack the L L M. You can convince the L L M spoof it. It can generate whatever query you want.

• 1:08:08Speaker 02

  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 P S Vs, to the parameterized secure views. 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.

• 1:08:46Speaker 01

  So that, I don't know if we call it role based access, but that user based access is

• 1:08:52Speaker 02

  Correct.

• 1:08:53Speaker 01

  stored alongside the data or managed alongside the data, I guess, maybe is the right.

• 1:08:57Speaker 02

  Effectively, what we're saying is, don't change, you don't need to put roles inside the database.

• 1:09:04Speaker 01

  Okay.

• 1:09:04Speaker 02

  But you can take what was written as a query in the application and put it into the D D L. Now you can let the L L M do whatever the heck it wants.

• 1:09:14Speaker 01

  I see.

• 1:09:15Speaker 02

  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 and 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, L L M

• 1:09:59Speaker 02

  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 bat 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. I talking about horror stories, I was talking to a, you know, customer in a bank about these things like P S Vs. And the customer said, what are you talking about? We just spent years making sure bat scans can't run against your operational databases.

• 1:10:43Speaker 02

  Do you want me to run agents now on it? Have you gone out of your mind, right?

• 1:10:48Speaker 02

  It's a totally valid question, right? You have agents and agent swamps 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 this.

• 1:11:33Speaker 01

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

• 1:11:38Speaker 02

  Exactly.

• 1:11:39Speaker 01

  That's fascinating, the comparison against how, cause 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 you 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 the code owns it. So that's something like three quarters 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,

• 1:12:21Speaker 01

  a year from now, two years from now, spend their day doing? What do you think?

• 1:12:26Speaker 02

  Look, honestly, I don't know what will happen three months from now, but.

• 1:12:29Speaker 01

  Me either. I was hoping you could tell me.

• 1:12:32Speaker 02

  Certainly, I think things have changed enough that if people had priors from six months back, they should at least leave us at 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 you'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, you know, 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

• 1:13:14Speaker 02

  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 self-contained unit of code where the person who built it did not even enter an ID, right? Did not enter Emacs or VI. So that is, I think, one extreme. The other extreme is I'm in the idea, I'm just doing routine refactoring. And there's a whole continuum of, 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.

• 1:13:57Speaker 02

  What we work with our teams, I think these are 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.

• 1:14:39Speaker 02

  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, the right imperative normally would be, I hit a bottleneck, I'm just going to drop down to the way I normally do it, go solve the problem because that's, 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 useful in general.

• 1:15:25Speaker 01

  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?

• 1:15:38Speaker 02

  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 take it as an article of faith. I think we are living in a fundamentally different era. And in this era, 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, you know, go through, you know, it's what was this, this stages of grief bargaining all the way to acceptance.

• 1:16:21Speaker 02

  And there are somewhere in that stage where, you know, 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.

• 1:16:36Speaker 01

  I think most people hit it and they hit it fast. Yeah.

• 1:16:40Speaker 02

  Correct. 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 evals, just what I said, you know, 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

• 1:17:22Speaker 02

  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.

• 1:17:44Speaker 01

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

• 1:17:52Speaker 02

  That's right. And we are all somewhere in that.

• 1:17:55Speaker 01

  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.

• 1:18:06Speaker 02

  Thank you for the opportunity. I always love geeking out.