Spanner, Hybrid Cloud, and Data Sovereignty (Ep 74 with Sailesh Krishnamurthy @Google )

Added: 2026-06-03

[00:00:00]One of the most interesting announcements I I came across there was Spanner Omni because Spanner is this very as I understand this very highly optimized database and was highly optimized really for Google infrastructure. You took Spanner in another direction. So I'd love to have you talk about that.

[00:00:15]>> You're listening to it's About Data episode 74. Our guest today is Sash Krishna Murthy VP of engineering for operational databases at Google.

[00:00:27]All right, Sylles, welcome. It's great to have you here today to record PostG next.

[00:00:34]>> Yeah, we're just trying to catch up here. Sish, you're vice president of engineering for operational databases and there was really really quite a slew of announcements that came down, you know, at at Nex in Vegas. What that was like six weeks ago. God, just time just so fast. But anyway, so before we dive into that, can you give us a little bit just tell the audience a little bit about your background and where you're coming from?

[00:00:57]>> Uh, sure. Thank you so much, Tony and Mattton. Thank you for joining us in Vegas. I think you're right. We had a whole slew of announcements and u it it was fun to engage with all of you. So I' I've been in the database business for the last 28 years, almost my entire working career. I spoke uh in IBM in the mid '90s on uh DB2 did a bunch of different things past then worked on streaming databases. Uh I was at AWS prior to coming to Google where I was general manager for Aurora and managed my SQL databases and I've been on Google for almost the last seven years now.

[00:01:32]>> Right. Right. And basically what was really interesting what what came down was that when you started I mean like one of the most interesting announcements I I came across there was Spanner Omni because Spanner is this very as I understand this very highly optimized database and it was highly optimized really for Google infrastructure. It was a very unique creature. Um I mean now we're starting to see a lot of folks basically try and replicate that in their own ways but you took Spanner in another direction. So I'd love to have you talk about that.

[00:02:04]>> Yes. I think you know first uh Spanner has been transformational for Google right it's at the heart of almost all our critical systems inside Google whether it's ads or Gemini or search uh and and through the years there have been more and more uses when we took it to cloud we've used the same infrastructure so this the same spanner infrastructure that powers inside Google that's part of our cloud customers and and the last couple of years has quite transformative for Spanner's growth. We've seen for a bunch of different reasons for AI because we we uh really push the multimodel uh story for Spanner. We have things like graph full text search and vector search. It's all come together at the right time. And at the same time, I think there are a few trends that that we see in industry.

[00:02:54]One is uh the truth is customers are on more complex infrastructure footprints.

[00:03:01]Uh it's not that you're just only on one cloud. So they are they use multiple cloud vendors. Many of them run their own data centers especially with ongoing challenges in getting availability of whether it is TPUs or GPUs or computer storage. People are spreading their infrastructure around and then um as a result of that there are a lot of customers who will come to us and say hey we'd love to use Spanner we want to be close with Google Cloud but we also want to have the service available in other environments. Sometimes it's coming from a stress exit uh thinking right it's almost in theory if something really bad goes uh happens what is our option sometimes it's because they want a DR scenario they want to take the cloud spanner database and they want to have for business continuity the data replicated to some kind of an on- premises environment and in some situations it's uh they are running something really complex on multiple different clouds and they want to they they really love Spanner, they realize there are many challenges with just commodity open source databases that uh that really can't easily be solved. So they want the power of Spanner, but they want it available in multiple regions.

[00:04:17]And so we've had we've known about this for quite a few years. People have been coming and asking us sometimes it's inhibited their decision to use Spanner, right? it kind of stops them from using cloud spanner because they worry about what are these other scenarios and so about a couple years back we decided we really pushed hard on this and you know there are many many hard technical problems to be solved because if you think about a service like cloud spanner uh as you put it it's optimized for for Google scale it's optimized to run on our infrastructure but it's also a fairly complex system in the sense that it's not just here's a binary that you go run somewhere. We have a whole bunch of different services that are all running behind the cars orchestrating this amazing user experience. So we had to solve many fundamental problems. We had to solve engineering problems in terms of core infrastructure components that we get inside Google uh you know true time storage systems like Colossus >> uh and to find a way to run them outside. uh over here we had to solve packaging problems in terms of okay now if I don't have just these magical API endpoints in the cloud how will a customer organize and run this uh we don't want to have the customer to run the same set of services that we are running uh and so how can we package it so that they can more easily run it and and in you know in our own uh systems and teams we have to think through many different aspects of commercial considerations and what makes sense. So it's a complex set of things. We very excited that we uh announced it. Uh the reception interest has been is is is really great. We are very excited to see this go to the next step.

[00:06:02]>> So let me ask let me follow up on true time and commodity hardware because famously Google put out all these these blog posts about basically how to beat the cap theorem using very precisely synchronized clocks, right? And that's also using very specific Google hardware. How do you deal with the fact that you have all this c the all this different hardware running notoriously different clock systems and still get that kind of performance?

[00:06:26]>> Uh so so it turns out you know there's a lot of details right and I think this the best the best possible performance best possible experience will still be in the cloud.

[00:06:37]>> Uh especially when you're running very complex uh uh globally consistent configurations and things like that. Uh but Spanner is more than just time. It also provides this amazing scale out architecture. And so we've built something we call softwarebased true time that in many situations that that we think customers will will have this will be this will provide you know a very good user experience. There will be some corner cases where it will not be ideal. Uh and so we will work through them as we get to them. We've even had customers come and say, "Hey, what if we had some kind of the same hardware that you guys or we think you guys have in your data centers?" And we put it, will that work?

[00:07:22]And so our answer to all of this is, "Sure, we'll we'll look at we'll look at what you have. We'll find a way to work with you." Got it. Right.

[00:07:29]>> I I I think what what's really interesting about this is that when Spanner really would debut and again when I say it debuted it's kind of a false term because basically you've been Google had been using this you know internally for well at least like 15 years something like that it was plus or minus I mean long time wasn't a new database but that when you when you basically released it you know as a commercial offering on your cloud um at the time we looked at this as being This is kind of a freak. I mean like you know I mean you know we've talked about active active databases you know but more in in in in the realm of the theoretical like is this really you know feasible in the physical you know in the physical world and yet what we found the last few years is virtually everybody has come up with their own I mean yes originally you basically had you know some folks over at cockroach and yugabi tried to do that there's actually surprisingly cockroach has had some recent success on this but that actually be to my point that you've seen the others you've seen you basically AWS uh you've seen Oracle all you know all join all join in on this and so something must be happening so I want to look not so much at the technical side but why is this happening what's out there in the customer base that's really demanded you know you this type of basically very distributed transaction database as opposed to let's say your your traditional say primary secondary >> um I think a few things are going on um I'll I'll try draw two two broad planes.

[00:09:00]I'm not sure if it explains everything but at least I think two things I see uh one consumerf facing applications the kind of uh scale that demands are are growing there's more and more of these services on and uh solving I think the core problems I mean there are many different things that spanner gave spanner provided consistent replication across data centers but spanner also provided the ability even if you didn't go across data centers even if you are even only in a single region Spano provided the ability to transactionally shard your systems and scale out which I think is an incredibly common usage pattern that a lot of new people uh need uh irrespective of whether you wanted global consistency and you know all of that that piece of infrastructure. So one theme is in general uh the the explosion of large scale consumer workloads and so on. And so we see this even amongst our current Spanner customers, people who um you know people who build frontier AI models, people who uh are I like to call them token purveyors as opposed to token consumers and they have to store a lot of data at a lot of scale in a high throughput high QPS low latency fashion.

[00:10:16]And so for this class of customers, these are real problems. I think these are these are big problems. And so uh I think this is a trend that we are seeing. Second trend I think is around uh maybe call it SAS workloads. People who have a very large number of uh smaller customers and few very large customers uh as opposed to just pure consumer workloads. I think you see a lot more of that happening too. And common to both of these kinds of uh use cases, you have the challenges of of sharding. And so I think for for all of these kinds of sharding workloads, I think Spanner has turned out to be a you know great solution.

[00:10:56]>> But then there's the other piece that traditionally as you've been in the database business do for such a long time, a lot of the way operational databases grew was people buying applications or people migrating existing databases. So if you have an existing database that worked on a commercial database model or an open source database model uh the easiest the lowest friction path was hey can I just go to a similar kind of architecture I to database logical database design physical database design remains the same and if it worked kind of well in that world then it works reasonably well in this world I think what we're seeing as perhaps the meta theme is new workloads and I think the new workloads are getting really exciting especially for AI related use cases is I think there's a theme that we are seeing that where people thought you needed specialized kinds of storage. Great example for AI is people thought that they needed for a while thought they needed a specific vector uh uh storage custom vector vector storage system or they thought you had a custom you needed a custom graph storage system uh or full text storage system and that you know I think the industry went through a path where uh you had perhaps an explosion of these different database systems uh which in my opinion led to two problems.

[00:12:15]you had one architectural complexity because effectively if you have all of these different systems you are connecting data and setting up data pipelines and this is particularly interesting from the perspective of unstructured data which we talked about before the call database systems I think historically had you know I like to say one job don't lose your data provide exact results for the data you have a query you get exact results for the data but in this new world you have unstructured data and structured data coming together and now what becomes most important is not necessarily exact results but the best quality results.

[00:12:49]It's about ranking and relevance and now you have to combine your structured and your unstructured data and that I think is a particularly interesting problem.

[00:12:57]Now like I said people went down this path of multiple different bespoke systems you know connected through various data pipelines and that was architectural complexity but there was also application complexity because now you have to combine the data from your structured database and from your unstructured database. If if I can just give a simple example uh if you imagine I have to combine a vector store uh for let's say uh storing information about item descriptions in an online retailer of our we've partnered with target.com uh they they use uh alloy dbkai for their online catalog search and so that is an interesting system or classes of that kind of system where you may be asking queries on your unstructured data, but along with asking queries about your online catalog, you're often asking predicates in the same query. Uh maybe about price information, which is real-time information that is not perhaps in your vector database that actually sits in your operational database. And if you uh have bricks and mortar stores in additional to your online store, you might want to have a predicate combining that is talking about the inventory of those items. So when I construct a search in that website, if I ask for ask for something, I'm asking for a particular item, I want to look at based on the the best semantic fit uh with respect to the uh search term I have. I want to combine something like price and I also want to combine inventory. Uh that is a complex kind of complex query and if I have to stitch multiple systems at the application level, the application developer has to know which system do I probe first. Do I always probe the vector index first? It could turn out I could probe my vector index first and get 20 results and none of them satisfy my other predicates. So then what do I do? I have to go back to the vector index again. This is a nightmare. This is kind of multiple building applications.

[00:14:58]>> Our perspective is this data can live in these different systems. The indexes can be put together in your operational database and you can just have one query with multiple predicates. That's the path we are seeing the world go towards and that's where having a multimodel architecture where you're able to support vector indexing full text indexing and graph all together in a single system is particularly exciting.

[00:15:22]Yeah, I can tell you I mean from my perspective I've done a lot of big migrations including on big Google cloud and this new vector to capability is so exciting because I can look back at migrations we did and say you know had we had that capability back then we wouldn't have had to do an extraction from bigquery to spark to do this kind of calculation say but I I actually want to dig in on another issue here which is a crossover of business and technical and even political a bit and that is what are you hearing from your customers on data sovereignty and how are you responding to that? I know you're on the database side, but I'm sure you get a lot of these queries about how do we address data sovereignty questions for American customers, for European customers. Yeah.

[00:16:02]>> And especially it's really pertinent we have a distributed database. So it seems like that would be you know well set for this.

[00:16:08]>> Yes. The data sovereignty question is great. I think you know one way of thinking about it is it's just how you how you are organizing storage systems.

[00:16:17]So certainly uh sovereignty, reliability, availability, these all go together, right? So in Google Cloud we have this idea of what we think of as 345 reliability. If you want uh three 9s, you can run that in a zonal service.

[00:16:33]If you want four nines, you can run it in a regional service. But if you want five nines, the only way we know how to run it is in a multi-reional service.

[00:16:41]And that's I think it's a simple way to think about it. But in addition to zonal uh you know regional and multi-reional which are ways of looking at this from a you know your footprint and looking at it in terms of nines you have as you point out uh sovereignty requirements from a jurisdiction perspective and so you might want to say I want data to be stored uh only in a particular uh region uh for and and there are I think multiple pieces here. So I'll tease apart two separate problems. uh one is partitioning subsets of data of users in a large database where I want to have some number of users whose data is stored only in a given region other sets of users whose data is stored in another region. uh Spanner now supports uh geo partitioning something that we are uh that we have it's in in production you can you can partition your data in uh in in these different ways uh and at the same time logically from the application's perspective it is just one single uh single large table or collections of tables but the data can be partitioned we can guarantee based on a partitioning key we can guarantee uh the the storage in a given geographical location. So I think that's one uh interesting way to go address it. But we've got another kind of problem too.

[00:18:02]Uh and and of course there are many reasons reasons to do this kind of partitioning. Partly it's data sovereignty but partly also where people uh you want to have affinity where workloads come in. I have these large global workloads. The user logs into Asia they want to get their data faster and so it's a mix of both of them. But there's this other interesting sovereignty problem that comes up where you want to keep the data within the jurisdiction but you still want to have high availability. It's particularly important for banking customers. So there are many jurisdictions in the world where there are only a limited number of regions uh for each of the cloud service providers right. So you may have two regions in India for instance I think Australia, Canada, there's a bunch of jurisdictions where people want the holy grail. They want 59s of availability which as I said typically requires a multi-reional configuration but they also want to guarantee that the data remains in jurisdiction. This is a really hard problem to solve because in any most setups which try to give you that high you know 59s of availability they need to have at least three regions and if you can only have two regions in a given jurisdiction uh then you have you know an interesting challenge. So the way we've actually addressed it is we've built for Spanner and this is the CL cloud spanner uh uh a special two region multi-reion architecture where we are only restricting where we can guarantee that the user's data remains in two regions and we use a third region with only metadata that is no user information goes to the third third region the third region contains what we think of as control plane information so if I have a very large database partitioned by a bunch of different groups. Each group the data is stored in different replicas and effectively one of them one of the replicas is a leader and that information for a given group which uh replica is a leader is what is stored outside in an in maybe in a in a region outside the jurisdiction. So it's a particularly interesting way to address data sovereignty where you can combine very high availability and still guarantee that the user data remains in the jurisdiction. Right. Well, stylist, you know, I I know that we've only really scratched the surface here, but actually that's really what we do is we're here to start the conversation, but we'd love to have you back uh in the future basic, but we very much appreciate you taking the time and sharing with us today basically your insights on why you basically think the whole use case for Spanner has really kind of broken out.

[00:20:36]I >> appreciate it. Thank you so much for your time.

[00:20:38]>> Okay, take care.