#355 AI's Impact on Databases with Shireesh Thota, CVP of Databases at Microsoft

If you just use an agent, it can easily hallucinate. The answer to solving that question, the simplest one, is to make sure that you really have the right context of the data. The one thing that massively changes is the ability to reason with data. We have basically invented this unified data platform. We call it Fabric. The opportunities got multiplied. You could gather a lot more insights.

The data stack is evolving again. Having a platform that works for both humans and agents is the latest challenge. So Today we're gonna find out what to build. In particular, we'll be looking at the Microsoft stack based on Azure and Fabric. And since tech is just a means to an end, I also want to know the implications for how data teams should be working.

Now, when you think about all these pieces of the stack, it's incredibly hard to get it all right, get it simplified to a point where you really can sleep well and not have to worry about the SLAs that you can promise.

Our guest is Shirish Thota, the Corporate VP of Databases at Microsoft. Shirish is responsible for product and engineering for Microsoft's Cosmos DB. As well as its offerings for open-source databases like Postgres and MySQL.

The traditional data projects are still there. The time to value needs to be significantly reduced. Maybe we have timed that, maybe we peaked a little too early, and I think we as an industry need to acknowledge and accept that.

Let's find out what's new in databases and the rest of the data stack. Hi, Sharish, welcome to the show.

Great to be here, Richie.

Yeah, great to have you here. So I want to kick off by talking about the data stack, and I'm curious, now we've got all these AI agents, has that changed what you need in a data stack?

Yeah, so there's definitely, you know, some things don't change and some things will change. And things that don't change in the data stack, you know, the fundamental resiliency, security, quality of data, et cetera, the things that we've been working on for decades, those don't change. And the ability for us to really go get to the source truth and just enhance the amount of data that you'd get to gather insights. There's a lot of tooling that's available now that would make it much, much easier. But at the end of the day, though, these are tools that basically can help you with your tasks. The one thing that massively changes is the ability to reason with data. If you have the right context, the amount of reasoning that you could put into the— naturally, when we went from ChatGPT to the next evolution of the reasoning aspect of it, and now to the agentic experiences, Data is going through the similar kind of journey where we had a little bit of, you know, you ask a very deterministic question, you have the right predicates and you just ask that question, you get the right answers. Now you could basically go and do reasoning on the data and you could apply agentic experiences as sort of the next ultimate evolution of it. And that's kind of really what Microsoft is doing, what we think of as a data stack. But at the end of the day, the fundamentals do remain the same. We went from modern data stack to a unified data platform as a paradigm. Fabric, for instance, is one of those things that basically made that happen. But that paradigm of going from modern data stack, actually before modern data stack, it was all fragmented. You'd have to go do your own bespoke architectures. We went from that place to modern data stack, but you still had to stitch a lot of services. You go from there to a unified data platform, which makes it easier by sort of pre-integrating all those things into a SaaS-like environment. And then now we are evolving further into unified intelligence layer on top of data because data kind of enables you. So while the fundamentals don't change, the data stack really is moving towards a point where it can help you reason with it and deeply sort of get to the insights and intelligence with all the latest, greatest tooling that's available. So that's, you know, in a sense, the changes that we will see more and more of.

Okay, lots of great points there. And I do love the idea of having more reasoning, allowing you to ask different kinds of questions about your data compared to sort of simple deterministic questions. Maybe we'll get into that later. But let's just maybe back a bit. So you mentioned the modern data stack and then it being simplified and becoming a unified data platform. Do you want to talk me through like what that shift was and what the different components are in each case?

Yeah, one of the biggest challenges that you'd see from across pretty much all of the data practitioners is that they'd have to deal with lots of different pieces. So when you're trying to achieve anything meaningful really in the data platform, in the data space, any data project, it's not the case that you just deal with an operational database one at a time, or it's not that you just with a data warehouse one at a time and you'd be done. That's rarely the case. You'd have to deal with data being born. Typically, it's born in operational database, OLTP system, system of records, and that kind of stuff. And then you'd have to take that data, do all kinds of manipulations, ETL pipelines, then bring it into an analytical stack. When you bring it into analytical stack, you need to marry that with various kinds of datasets. You may have to deal with real-time. You then have to deal with an analytical piece where you have to go, how do I store this? You know, is it a data lake? What formats? Open-source formats, proprietary formats? What engine do I have? You have different kinds of options. How do you serve the data back through that engine? And you have different kinds of, again, some kind of real-time analytical layers, operational layers that can help you serve that. And then finally, you are doing probably data science work and data engineering work. And then ultimately it'll all lead to some kind of BI where you have report all that stuff into a dashboard that is really useful for the business users. Now, when you think about all these pieces of the stack, it's incredibly hard to get it all right, get it simplified to a point where you really can sleep well and not have to worry about the SLAs that you can promise. But that was sort of the biggest challenge. So, unified data platforms are effectively trying to simplify that by having consistent experience across the board. One of the most important mechanisms to do that is to have a lake where all of the data is consistent. It's typically open source format, so you don't have to feel like you're locked into anything. It is really exactly one copy for anything, and you decouple the writers from the readers. Writers all can write into the common format into one lake. Readers will all be operationalizing on that stuff. They can, all the compute engines can be working on those, on the same data format, independent of who wrote it. So you're Now you're sort of like really going from a multiplication to addition. It's not M by N kinds of failure points. You have N plus N where M readers, N writers, you know, somebody's— but that's all possible when you have a lake that is basically open source format, consistent, and it's one copy, et cetera. But it's not just that, it's more than that. It is about stitching everything together so you have one security, it's one lineage governance kind of model. All the engines basically have same business model, so you could really mix embeds different kinds of capacity provisioning and all that stuff. So it goes deeper, and that's the reason why you need a unified data platform that understands all these pieces and not think of it as piecemeal. Typically, a SaaS experience works better than just sort of giving out all these tools and let the developers handle them. So that's kind of really the evolution here, and we are seeing good success with that.

I love that idea of the flow. I mean, if I've understood this correctly, it's basically like gather all your data from almost everywhere, shove it into a data lake, transform it into something that's usable for other people, and then you can serve your analytics to all the business users. So very simple flow. And it sounds like a lot of the architectural questions, like we've been trying to figure out like what should be in this stack for a couple of decades now. What are the sort of the problems that people are still trying to solve by evolving this technology?

A lot, you know, so obviously the traditional data projects are still there, right? The traditional data projects of trying to really create a place where you can gather insights immediately, as soon as the data is born, as soon as the stream is born. The challenge that whenever you have data that's been born in operational system, how much time does it take for me to really gather insights so that then I can complete the feedback loop? Perhaps you're building some kind of a small e-commerce retail system or something. I'll just take an example. There's a lot of flow coming in, there are a lot of eyeballs from the customers who are trying to do some shopping or whatever. You know, you go from that point to the point where you really have to go create pricing adjustments perhaps. And that requires you to really go do a lot of things and gather insights and then push it back to the pricing. Maybe you're having to intersect with the inventory supply chain and all those other pieces. How do you do all that stuff really efficiently, effectively? That's just the nature of one of those problems. Those kinds of problems are not going away. With the evolution of AI though, those problems got even more— the opportunities, I would say, not even problems, the opportunities got multiplied. You could gather a lot more insights. A lot more efficiently, you really can go to the point of researching on the data and deeply analyzing the data, which massively enhances your operational footprint. Just, you know, all up your application space, et cetera, can get much richer.

I love the way you simply rebranded problems to opportunities. It's a good mindset, I think, to have. Cause yeah, there's problems everywhere. It's like, nope, we got opportunities.

I love it. Yeah. No, I genuinely think that that is the case. 'Cause there are definitely more, you gotta do more work, you gotta embrace new technologies, but just the amount of opportunities that it opens up is just, some of them you couldn't have even thought about just a year ago.

Absolutely. And it does sound like a lot of the challenges around like integrating stuff and making sure that like all the data is in the right place that fits your business needs at the moment, and maybe your business needs change, so you then gotta shift around all the data once again, just do So yeah, it's kind of a never-ending task, but I guess again, opportunities for excitement. All right, so we talked a bit about the data stack in general. I'd love to get a bit of help with navigating Azure because you've got what, 200, 300 services or something now? I get confused about what's what. So maybe do you want to talk me through like what's available for data on Azure?

Yeah, so you know, that's exactly really the motivation for us. What you said is true to a good degree. Now as a hyperscaler, as a provider of technology, you know, we are a software factory effectively as a company where we have to really go serve the needs of not just the high-end enterprises, not just the sort of like, you know, hobbyist, mid-market, like anybody who's just coming up, etc. We have to serve the needs of the world. And that's kind of really our mission to empower everyone. And so, in the process, you'd have to go through different kinds of offers, different kinds of options for every different persona, every different opportunity that may exist, et cetera. So, but we realize that it is complex. So what we have today, in a very nutshell, I run databases and in the world of operational databases, we've been in the business of OLTP systems in on-premises for as long as 1989, right? We've announced SQL Server first version, you know, back in the day and we just announced a new version of it in 2025. We totally recognize that there are customers who are to run SQL Server in private data centers, in other clouds, whatnot, we offer that. But the best place to run that is in the cloud. And in the cloud, we offer IaaS where you could really bring your database, run it in a VM, it's good to go. We have PaaS offerings. In the PaaS offerings for databases, we have databases that are born in the cloud, like Cosmos DB, for example, which is a non-relational, elastic, great for geo-replication, great for RPO, RTO kind of engagements. Is born in the cloud, it's only in the cloud, it's a PaaS offering. We also have embraced open-source databases. So, we're very big on MySQL, but even more bullish and like we're contributing a lot more to Postgres. So, there's a lot of PaaS offerings there. SQL of course runs in PaaS as well in the form of Azure SQL. Now, for the rest of the stack, we have of course evolved from shipping Power BI as a standalone entity We had analysis services that kind of helps with the BI tasks, building cubes all the way from that to dashboards of Power BI. So we've started with that. We have basically a data factory that can help you do the pipelines of data transformations and migrations from one place of the data to the other, et cetera. But what we've noticed is that it really is not easy for developers and customers to really go reason with all the variety of data issues. And for all the reasons that I was explaining earlier about modern data stack and all the, integration challenges, we have basically invented this unified data platform. We call it Fabric. And so Fabric becomes now the one-stop shop for everything data in Microsoft. It basically has all the things that I talked about in terms of going from data integration, data science, data engineering, real-time analytics, analytics, Power BI. All of those pieces are all really stitched together and you have one security, one business model, It's one lake, which basically has the consistent data across the board. Most importantly, we've moved from unified analytics to unified data. The delta is bringing in operational databases also into Fabric. So you have the place where the data is born, the place where the insights are happening, everything is going through one lake, everything has one security model. It's truly integrated. So Fabric becomes a one-stop shop to answer your question. So we really have a very, elegant answer that arguably we didn't have a few years ago. So now we do. You really go to Fabric, think about it as set the tenancy and pick your workspace and you can go interoperate with various pieces.

Okay, wow. So in theory it sounds like things might be getting easier, but there's a lot of different things there. So you mentioned, so you talked about like SaaS and PaaS, so software as a service and platform as a service. You mentioned like a lot of different databases with different properties. So some of them have like the geo-replication, some of them were like super robust, some of them are models of a small dataset. Does Fabric take away all the needs for like deciding what infrastructure goes underneath or do you still have to make these decisions about like which database do I wanna run stuff? Like how do I decide like what should go inside the Fabric?

So I think we will get there eventually. There is definitely a need for many of the developers who really know what they want and we don't wanna take anything away from that, that need. There's a lot of power where the customer knows what they really want. What kind of a database do they need? What kind of application that they're building? If you— because there are some concrete and really hard trade-offs that you have to make when you're picking a NoSQL database versus a SQL database. You trade off asset guarantees to a certain degree because you want scale and high availability. You know, these are physics rules that you have to bend. In terms of giving you a high RPO, high RTO, then you need to really give up on some of the— how do you do unique constraints on a petabyte data? Because the data is sharded across multiple instances, so you're going to— the writes will slow down significantly. So there are some really hard trade-offs, again, tied to the speed of light problem at the end of the day. So you do need to make sure that, you know, our philosophy is that we don't want to really simplify We want to simplify, but not simplify to the point where it is so simpler that it is not useful. We want to not remove the power of that choice. What we want to simplify is the ability for you to, or the complexity of really integrating all these pieces, trying to think about different services in terms of what they have to offer, how do you provision them, how do you manage them? Do each service have a different kind of, uh, security posture? Do each service have a different kind of DR posture? How do you really do SLAs differently? How do you do business model differently? How do you provision capacity? All those kinds of challenges we want to remove because that's not really where your energy should go into. Your energy should go into the architectural trade-offs that you want where you want to, hey, this is a workload where I really want to have immense scale. This is a workload where I want all the richness of SQL and I want full asset guarantee because consistency is everything for this application. That change and that sort of trade-off, we don't want to get in the way there, right? So that's kind of really our philosophy. Now, as we go up, as we build more and more agent applications, agents and AI will certainly make those choices also easier because, you know, you're then talking to the agent in language, in English, instead of really going and making those decisions. So we'll get there, But ultimately, as a platform though, our goal is to simplify where we should be simplifying, but without removing any of the power of the platform that you as a developer, as a customer would absolutely need it.

Absolutely, yeah, I can certainly see how there's different users are gonna have different opinions on how much control they want. So if you're a software developer or you're a database admin, you're really gonna want that fine-grained control over what's your database doing? Whereas if you're a business user, then maybe less so. You don't care so much about the specific architecture. You just want it to work. You mentioned a lot of the sort of different types of database there. So you mentioned like you got the SQL database versus the NoSQL databases. Of course, vector databases are like the more recent sort of hot new thing. But a lot of databases should be incorporating a lot of these features. Is that a trend you've seen where rather than having distinct databases for specific purposes, you've got databases that encompass a lot of different things?

Yeah, you know, at the end of the day though, we basically have two kinds of databases. The databases that really care about asset operational kind of characteristics where you really want atomicity, consistency, isolation, durability, right? The asset properties that we've learned and we care about it deeply. That the— and those are generally relational databases. You have relational algebra, they really know how to model the data in a certain way, rows and columns, and they basically offer you an enormous power, very deep, very rich SQL. And so, there's a lot of, a class of databases that we really need that. Now, these kinds of databases are incredibly good and they started scaling as well and they're getting better and better. But there is a point where ultimately what we call these databases adopt to what we call as shared data architecture, meaning any amount of compute that you provision, they still need to have one data copy. They're sharing the same kind of view of the data. They're not partitioning the data. There is the other family of databases which are non-relational databases, quote unquote NoSQL databases, where they partition the data. So you have one piece of data with one node and/or set of nodes with replicas, another set of data with another set of computes, another. So you can keep sharding and keep horizontally scaling them as much as you want. You could go into petabytes really. And when you have those kinds of databases, you basically would get a lot of elasticity. You can position each of these shards in different geos. So you get a lot of geo-resiliency, geo-affinity, and lots of great benefits. The trade-off there, again, is that you wouldn't really get the same kind of atomicity, consistency, isolation guarantees that you'd get there. Now, both these paradigms are definitely generally, you know, moving in from right to left, left to right, the other way around. And they're going to meet at some point because you would see in relational world, there is a notion of scalability with disaggregated architectures. We are doing this with SQL Hyperscale. We have a new database called Postgres Horizon. They scale quite a bit. You can go from gigabytes to hundreds of terabytes easily. Compute can scale, but you still have one writer and one copy. In the non-relational databases, we are slowly adding ACID characteristics, but the The key difference is going to remain. So our thesis is that we think of our portfolio into 2x2 world where you have SQL databases and NoSQL databases. And then the other, that is the columns. In the rows, we have homegrown industry-leading kind of databases. We also have great, fantastic OSS databases. So in the relational world, we have SQL, SQL Server, that's what it is. In the NoSQL world, we have Cosmos DB. In the OSS space, we have both MySQL and Postgres. You know, we've added quite a lot of Postgres databases there. In fact, we have recently announced something called HorizonDB. And then on the OSS side for NoSQL, we also have something called DocumentDB. So when you have, you know, sort of the needs for SQL, NoSQL, homegrown, Microsoft first party, and then OSS. OSS is also first party. We've fully embraced Postgres, by the way. In fact, we contribute a lot more to Postgres than many of our peers. So, you know, this is sort of how our portfolio is. When you look at many of the prolific applications of today's world, namely things such as ChatGPT, for example, they rely on Cosmos DB for all the messages and they rely on Postgres for transactions. Many of Microsoft's large-scale mission-critical applications like SharePoint, Dynamics, they rely on SQL. So, you know, these trade-offs will remain, but Our portfolio is very sort of well-designed for this 2x2 matrix.

Okay, I like the idea of just splitting out the relational SQL stuff, non-relational NoSQL, and then I guess you've got your internal products versus the open source stuff. And actually, on that last point, it seems like there's been a bit of a shift in terms of mindset at Microsoft in terms of embracing open source over the last few years. I mean, you go back a couple of decades and that was just not a thing at all. Do you want to talk me through what's happened there?

Yeah, no, this is a great question and your observation is spot on. It is true that we have basically come around and we've embraced open source databases fully. If you look at what we've been doing with Fabric, our OneLake formats are all open source, right? This is Iceberg, Parquet, Delta Parquet. So we're just making sure that we are really fully embracing that kind of formats and anything that we are doing in terms of developer extensions, VS Code extensions, databases, they're all open source. The major one that I work with is Postgres. Postgres is obviously very well regarded and it has one of the strongest communities. I would say this is probably the number 2 biggest open source project after Linux, I would think, and the community is getting stronger and we are fully invested into Postgres to the point where we have a group of committers who we are nurturing who are encouraging them to commit code to Postgres upstream, and their goal is not to really help Microsoft Azure Postgres. The goal is to help Postgres Postgres. Obviously, everybody benefits. We will benefit too with that, but we are committed to advancing the art of Postgres, and thereby, you know, we're supporting, nurturing our committers. We're very, very deeply invested in that space. In fact, if you look at Postgres 16, 17, 18, the last 3, if you combine all that stuff and look at the amount of changes that we went in there, most amount of changes came from Microsoft. And that's a surprise to most of the community members. We have more committers, we commit most code to Postgres, and we will continue to do that as well. The reason is because we recognize that many of our customers want that flexibility. And, you know, our affinity is to help our customers succeed, not to a specific, one specific tech. We have points of views in terms of when to use what, but we embrace it, and Postgres is a great database. So, we definitely have been sort of embracing that. One other example that I want to point out is DocumentDB. When you look at NoSQL world, the amount of open-source efforts in the NoSQL world have significantly diminished. There was quite a bit in the early days. We used to have Cassandra, for instance. Mongo started as open source, but it's no more open source, and I think the effort in the NoSQL space has completely diminished. So, we've recognized that and we do have many customers who would say, hey, I wanna have the optionality to take this database elsewhere, run it somewhere else, you know, even though Azure is a great place to do it. So, to do that, we have invented DocumentDB. DocumentDB is a Mongo-compatible but a fully open-source NoSQL database. And so, we've donated it to Linux Foundation. We in fact partnering with many of our cloud friends out there, hyperscalers. So, you know, it's a true open source database and, you know, we just begun there. We look forward to really investing a lot more deeply in advancing it. Any of the new things that we are doing in terms of VS Code extensions, a lot of AI work that we are doing, that all gets open source quite a bit. So we've embraced it and whenever it makes sense for us to open source, we really lean towards doing that. Yeah, and it's become a theme.

Yeah, that's very interesting because I think in the early days of NoSQL, there were a lot of different open source projects. I mean, yeah, you mentioned Cassandra and Mongo used to be open source. And then, I mean, there's Redis and like, there were a ton of them. So it just seemed like maybe that's been, it's had less excitement in the last few years in terms of the open source progression for NoSQL. I'd love to go back to the thing you mentioned at the start. Which is about how you've got fancy reasoning generative AI that lets you ask more interesting questions of your data. Do you want to add a little color to that? Like, what are the sort of interesting questions that you can solve with these reasoning generative AIs?

I want to really set some context here, and context is a word that I'd use a lot more here in terms of getting there and solving and answering your question. Data is going to be as effective as it basically has the context around it. It, of course, is important to have clean data. It's a cliché to say that, but it's really important to understand that quality is a lot more important than quantity. Right? It's said multiple times, but it is true. The way to think about reasoning on data is that you have to annotate the purpose of that data, the context of the data, and there's more questions around the data. So imagine that you basically are given a set of tables. With some amount of information, and it basically sees a bunch of numbers on the left side, bunch of numbers on the right side. Of course, you know, you do have some schema, you have a little bit of context around it, just looking at the schema, but it's often not enough. You may have, like, you know, comments, you may have some text, some not very deeply prescriptive kind of names in the schema, and applications may use, like, entity frameworks or whatever that can really muddle up how schema looks, et cetera. So you may end up with a bunch of numbers that may look like, we don't know unless you have context whether these are Social Security numbers or these are credit card numbers. These are just numbers, you know, a bunch of numbers are floating around. That's just a simple example I'm taking. Often they generally get annotated with some degree of information, but as you go deeper and deeper, this information is not sufficient. So what ends up happening is that AI can really go and look at these things and try and infer a few things and can easily hallucinate, easily come up with a query that's not what you want. So your natural language to query language interpretation, you know, what you're trying to connect with the data, if you just use an agent, it can easily hallucinate. The answer to solving that question, the simplest one, is to make sure that you really have the right context of the data. You need to explain what is an entity, how are these entities related to each other, what is the hierarchy of information. And then you can define some measures of like, hey, when I ask these queries in my dashboard, this is how you really should measure them and come back with the right answer, etc. And different departments may have different kinds of interpretation. Even simple thing like asking for revenue from a dataset, product may have a different interpretation than finance. Finance may have a different interpretation than sales. Subtle differences. All those things need to be annotated. So that's sort of step 1. And, you know, we've done this in Power BI. We call this semantic modeling. So having the right data, quality data, clean data, step 1. Unifying every piece of data is important. That's step 1. Step 2 is to really build that semantic model. And then step 3 is that now that you have the nouns of the data, you need to put some verbs. You need to really have some kind of actions and policies that can really act on the data. You could create the policies of your day, of your company, of your organization as to, let's imagine that you're trying to model a fleet of cars or vehicles that you wanna manage. You could have information like, hey, a car is an entity, an operator is an entity, a trip is an entity. You could have some such definitions. You need to annotate them, explain what are the boundaries, what are the limits of those nouns and how they're related to each other, et cetera. That's all semantic modeling. And then on top of it, you can then now start building some kind of policies which says that, Anytime you see a truck's fuel level going below a certain level, you need to alert a nearby operator to go refuel it. Just a simple example there, right? That is a policy tied to an action. And if you could, you need a mechanism to define those things. We call that as an ontology. And that's sort of built on top of the semantic model. So that would be my third level, which is like you go from clean, curated, unified data in a lake effectively. You build a semantic model, then you build these policies and actions. Once you have that, then you can apply deep research agents, which can really research your data better and can come back with a lot more effective answers than simply just asking a Direct Lake or a direct database or a warehouse or whatever because they don't have the right context. You need to annotate that. That is work that needs to happen on top of it. We make it very easy with Fabric. We call this Fabric IQ. And that's exactly the approach that we have taken to go to the point of, you know, not just looking at the data, but getting to the point where you could really reason about it, deeply do some research on the data. And the good thing about is that the layer at the bottom is a unified data layer. So you could intersect the data from SQL databases, NoSQL databases, some streams, maybe even SharePoint data. You could even bring S3 buckets from other clouds. You could shortcut from there without even moving the data. You just need a virtualized pointer back to your buckets in S3. We don't mind that. So unified data layer is important. Building semantic models is important. Then you build ontology. So that's sort of like, these are the building blocks, the ingredients to get to that kind of deep reasoning.

This is fascinating. And I think you maybe just inadvertently solved like an argument that came onto my LinkedIn feed the other day. So I've seen quite a few companies who are sort of building out like a semantic layer software. It seems like one of the new sort of hot things. And as you mentioned, this is about like making sure that like every single team, if you're asked like, how many users do we have, you'll give the same answer rather than giving slightly different definitions. But a lot of people in there sort of data steward community seem to think that ontologies are a better thing than semantic layers and that semantic layers are a much simpler thing. It was a whole weird argument I didn't quite get, but it sounds like you might need both. Is that right?

I think so. And I think it's a little bit of like splitting hairs between the two. One could say that ontology is just a natural extension of a semantic model instead of thinking of them as completely different things. But it is the way you define the ontology is that it's very business-specific. You have the right rules and policies and actions that you could apply on the ontology. There are lots of industries who have embraced ontologies for a long time. If you look at supply chain, for instance, there's deep, deep vocabulary and grammar to how they think about lots of different pieces that I'm not an expert at. Every industry has those kinds of ontologies. You need to really apply those things on top of semantic information about the data or expand it one way or the other. It's like splitting hairs between these two things. The idea though is It's simple. It's about creating the right context on the data.

Okay.

I like that.

So making sure that everyone understands like what the data really means and you've not got different definitions of things you're doing.

Correct. And having something that the organization is aligned with, right?

Absolutely. That sounds incredibly useful. And so this brings us back to the original question, like, so once you've got all the kind of data in place, you've got the context for your agents, what kind of cool stuff can you do with them in the realms of data?

We've announced something called Database Hub just recently. I'll pick that as an example and I will walk you through what we are doing here. So obviously you could do a lot more with, with once you have these layers. But let me pick on Database Hub and Database Agents as an example. One of the problems that we see with a lot of our vendors is that a lot of our customers is that they generally don't have one environment, one database. You know, it's not like that, right? It's typically messy, it's heterogeneous. You're dealing with on-premises databases, IaaS, PaaS, various kinds of databases, different kinds of environments, and multiple types of databases. You want to have one view that basically helps you monitor, govern all those pieces. And then what we've done is basically built a hub, which kind of gives you all that view. On top of that, we've added agents to help you monitor vigorously and thoroughly, continuously, all the database state so that any performance issues that you may have can be highlighted, can be corrected, and sort of like, you know, work with the DBAs. And we're not replacing, but we're enhancing the experience and really helping the DBAs to go focus on the higher things. That's all possible because there's a richer telemetry that we gather. It's kind of like meta application of what I'm talking about, but it's really an important meta application because it's sort of We use the same kind of stack to give very rich information to our customers, DBAs, database developers, to go deal with security issues, compliance issues, and how each database is interacting, how an application is interacting with databases, because ultimately databases are here to serve the needs of applications. So that's an example where we have internally used it sort of like to benefit from the same stack. Externally, There are a lot of customers. You know, one of the coolest ones that we talked about in public is when you think about airline operations, there's a lot that's going on in running an airline operation. How do you really simplify all of that stuff? Simplification is hard, but making sure that everybody agrees on the same challenges, everybody's working on the same things, and really go deeper and deeper on, hey, what is that which is causing the delay? And how can you trace some of these backlogs, et cetera? So all those pieces can be created into an ontology. We are effectively helping them create a digital twin of the world first. It's a graph. And then on top of it, like, you marry it with the data, and then you can go really go reason about it. There's one thing that I do want to add here in the context of these examples is that we believe, obviously, that most of the work happens in your chat messages, in your emails, in your documents, et cetera. Colleagues at organizations, they interact with each other not through a database directly. They interact through, you know, a Teams channel, Slack messages, or whatever. And a lot of the information is actually captured there, and most of the operations are really happening there, right? So, what we've done in Microsoft is that we have all the stack, right? We have WorkIQ, just like how we have FabricIQ that I just explained. We have something called WorkIQ. And this Worker Queue basically is the same kind of idea. It's intelligence layer, contextual intelligence layer on top of your office-related engagement. So, all the productivity information that you may have in chats, email, SharePoint, all of that stuff, there is something called Microsoft Graph, which basically understands all these pieces. It really has very rich information. We marrying that with that of the Fabric business strata that we have. In fact, we also have something called Foundry IQ, which helps you bring in institutional knowledge. But all these pieces put together is the Microsoft IQ stack that is unique because you go from all the way from like having chats in your Teams to understanding your data, going back and forth. You can write, read, and different people write and read. And you, of course, need a data layer. But you're married with the interactions that are happening in the work layer. So we have many customers who are taking advantage of this full stack.

That sounds very cool having that kind of all these sort of things integrated with like your email, with your Slack, with your like your Teams or like whatever it is that you're using to communicate because you don't have to go away from your day-to-day like interaction with the people to think about data, at least in a lot of cases. Okay, all right. So related to this, we talked about how AI agents are dramatically changing the data work. Is SQL still worth learning at this point when agents can, or well, in fact generative AI in general can write SQL for you?

My personal recommendation is that absolutely. And this is one of those things where it's less the case about really not having to gain deep expertise about how, you know, could you really run Could you write a CTE expression yourself? It's less about that. It's more about trying to really understand what your data model is. It's trying to understand the fundamentals of how you gather insights. What is the efficient structure and what happens when you don't have the right efficient structures in place? Data modeling is incredibly important. SQL is an extension of that thing, right? If you don't have that ability, then you would end up just accepting whatever the agent may have recommended. And down the line, there will be tons of significant performance issues, etc. What AI can help you with is the ability to do that efficiently and scale you better. You don't have to deal with the grunt work of really figuring out what is the exact syntax of how do you write it, but you need to understand SQL. You really need to really figure out, is this generating exactly— is it converting the intent that I have? Is it converting the business model, business objectives that I have into the right data model? That conduit is not going away, right? But by having these tools, it liberates the DBAs and the database developers to focus on those things. And I think that's a significant value. So my recommendation is that please continue to learn SQL. SQL has been there for a long time and it'll be there for a lot more time because it's truly the language of data. And in many ways, it's been proven over and again that there's no better way to do that than SQL. There will be a point in time where, you know, just like how compilers abstract some of the information and then abstract, like you start writing, you're still coding, but you're writing it, you're coding at a higher level. You're not coding at machine assembly language, right? You're coding at a higher level managed language. So there will be abstractions that can help you get there. But the understanding of how do I optimize, how do I convert my business model into the data model, how do I really think of all the SQL data entity relationships, et cetera. And so SQL is very important in that context. So without that, I think we'll have a lot of challenges.

Absolutely. I mean, it's good to know that SQL is still worthwhile learning about, even if you can't get the machines to write it for you, but certainly understanding it. And it also sounds like you said data modeling is maybe even more important now. Do you want to talk us through like what are the basics of data modeling that you think everyone should know?

I mean, the usual basics are very important. The way to normalize schemas, the way to really understand what is the efficient way to convert your business model, your business objectives into the right data. A lot depends upon that because the speed of writes, the efficiency of queries, where do you index, where not to index, those things will define the performance. It'll also define the efficiencies and ultimately the consistency and sort of like the governance aspects, et cetera, will flow through that. Because if you don't have the right permissioning models, you put the same data in multiple different places, you may have missed some amount of sort of allocation of permissions, then it can lead to a major attack. And it's truly the fundamental piece of it. AI can help accelerate that. I'm not against it. Of course, you should really use AI tools. You should 100% do that. But you as a human need to be in the loop in terms of converting the business objectives into that, into that exercise. The goals of really trying to convert the business objective into your data is all data modeling in my mind.

I love that idea. Yeah, you're translating like, I've got a business problem, this needs to be represented in the data somehow, and this is an important thing for humans to think about. Okay, all right. And I guess more generally, how do you feel like the role of data professionals is changing with the introduction of powerful AI?

Yeah, so firstly, with the unified data platforms that we've been building, with all the databases coming into Fabric, with all the SaaS experiences that we are building, and also just sort of embracing all the greatest and the latest, including open source, we are trying to move to the point where we actually empower application developers to succeed without having to look under the hood. They want to be higher up the stack They want to spend all their time trying to think about how do I build my next generational application? How do I really bring value to my business? Not necessarily dealing with the nitty-gritties of every data layer. So that problem needs to be solved. And we are very committed to doing that thing. Whenever we talked about autonomous experiences for databases or data platforms, et cetera, you know, I think maybe we have timed that, maybe we peaked a little too early. The timing was probably a little off because anytime we had those kinds of ambitions, what ended up happening was that the results weren't that spectacular as the claims were in the past. And I think we as an industry need to acknowledge and accept that. I do think that it's not a reason for us to not go embrace it again because we have one of the most powerful tools the tech industry has ever had, humanity has ever had. And we have to go embrace that. I truly believe that this industry needs to embrace autonomous experiences at the data layer. We will, we're very deeply committed. What happens with that is that then you really liberate the app developers, the database developers, DBAs, and all these data professionals to go meet the needs of the apps much better and sort of like really scale better. Once we do that, then they can 10x their experiences. They're still the conduit between converting their sort of business objectives into the data layer. But these agentic experiences is the new sort of vocabulary, new medium with which they interact with the applications. Everybody wants to really have the SaaS experience. The time to value needs to be significantly reduced. They're really thinking about higher up the stack. And, you know, it's kind of really how somebody who owned a car in the early 20th century to what they do now. Like somebody who had to own a car in the early 20th century had to be an expert at how the car engine worked. Not anymore. I really don't even know, like, you know, sort of most any detail. And that sort of, it took 100 years to get there. With AI, I think it's going to be much, much shorter, but the data professional world, the application world are going to are gonna come together much more closely. I think the objectives are not changing. The mechanics are getting simplified significantly.

I love that analogy with the car. I'm just thinking, well, I can just about change the oil there, windscreen washer fluid, that's kind of it. Yeah, and the rest you don't need to touch most of the time unless you're a professional mechanic. And maybe it should be that way with databases. Like, there's only a limited number of people get very excited about, I wanna play around with database settings.

And it is hard. You know, I don't want to pretend that it is simple. Databases are complex, but cars are even, you know, equally complex. We got there.

Absolutely. Okay. And so I guess before we wrap up, I realized Cosmos DB is kind of your baby. So I've not really given you a chance to tell us about that. Talk me through what's Cosmos DB.

Well, thank you, Richie. Yeah, so I, you know, I've worked on Cosmos DB ever since we sort of formed the product, and it's been a long time. So Cosmos is one of those products where you— so firstly, it is a NoSQL database. It's a non-relational world. It has its trade-offs in terms of like making sure that you get enormous scale, great high availability. We are geo-distributed, so you basically can go from one region to any number of Azure regions, all number of Azure regions. And you can have a copy in all these regions. And you could do that both in a sync mode, async mode, meaning if you want to have a global strong, as soon as you write the data in one place, do you want that data to be replicated everywhere before you even acknowledge to the client? Or you could sort of in the background replicate it to the other regions. There are lots of different trade-offs to both these. We support both of them. So it is a scale system, and so it trades off a few of the asset query capabilities, but it is a phenomenal system for basically going from gigabytes to petabytes. I mentioned earlier that OpenAI's ChatGPT runs on Cosmos DB. In fact, many of the mission-critical applications inside Microsoft and Azure run on Cosmos DB, including Teams, which is one of the most prolific chat applications, professional chat applications. All the messaging goes through Cosmos DB. It's really great for a system of engagement. Whenever you're trying to have these interfaces, any e-commerce applications are trying to manage the shopping cart. For instance, Walmart uses Cosmos DB. So all these kinds of experiences are really designed for Cosmos. The fundamental value of Cosmos DB is that it basically lets you interact with the database with JSON, BSON as a primitive instead of sort of like, that's the rule basically instead of emitting, like inserting individual columns and having relational algebra, you're ingesting a full JSON. So as soon as a JSON object is born, you could just take it and put it into Cosmos DB. And by default, it indexes everything. So the data modeling exercise is very minimal. You do need to think about partitioning the data effectively. But once you do that decision, the connection between the point where the data is born, and typically most of the interwebs data is JSON data. So as soon as the data is born, it can go into the database. You can start querying right away. There's very little pipeline. There's very little ingestion challenges, conversions, etc. And most every popular application framework knows how to deal with JSON because JSON is that ubiquitous. And that makes it very easy for it to be sort of applicable anywhere. Headless APIs, HTTP APIs, they all work. Great with Node, Python, all of the new ecosystems that are there, great with.NET, Java, of course, you know, we got great drivers. But a lot of our innovation is about partitioning the data. Every piece of data is independent and it can scale multiple partitions, sharded data. This is what like, you know, systems like OpenAI do. They have petabytes of storage. So they need to make sure that we have shards. Each shard has, you know, independence in terms of of how there's a replica of sets that can manage and it's highly available. And then the other great thing about Cosmos DB is Geo-DR HA. And you have, we have two capabilities where one region can be active, the other regions can be passive, meaning the active region is the place where all the writes go and the other regions where all reads can go. The write region can also read, can also provide reads, but every other region is read. And if the write region is down, it basically automatically fails over to one of the read regions to become primary. Memory. So you don't have any downtime except the failover time. There is another mode called active-active where every region can take writes, not just reads. Every region is both writes and reads, of course. Wherever a write is there, reads happen. Now in that mode, you could be writing local to wherever you are. So let's say, you know, one of the writers is in the US West, the other writer is in Australia, let's imagine. They're both writing independently to their databases. And we are synchronizing and doing conflict resolutions. So there's a very complex and advanced mechanisms, makes it very easy for the developers to do those kinds of things. And most importantly, if a region is down, there's no failover there. The other region will automatically take the writes from the other, you know, your client can just directly talk to the other region, writes will flow. And this is important for applications who want RTO, meaning downtime, to be almost zero, like, basically there's no downtime at all because it doesn't matter even if your region is down, the writes will continue to flow. So these are a few modes, great for internet-scale, large-scale applications, great for getting started schema-less. You don't have to worry about upgrades of schemas, et cetera. So these are, you know, again, different trade-offs, but, you know, one of the most mission-critical ready databases out there.

Okay, so actually a lot of your earlier examples now suddenly clicking into place that makes sense. So this is all about, if you are an application developer and you don't necessarily want to worry so much about your databases, it needs to be like you got a relational database that just kind of works for your application. Is that a reasonable description of Cosmos?

Yeah, I mean, I think, you know, I would say the relational database and are very sort of distinct and they're great for what they do and they're getting really stronger every day. We're very committed to SQL, of course, you know, first and foremost, the SQL company, and we embrace Postgres. Databases, et cetera. They're getting their own sort of like thing, but it's all about, do you want functionally deep, rich query with deep, rich data modeling with the right normalizations, knows exactly how data consistency is managed, et cetera. And you have like enormous amount of SQL power. If you want that, then relational is great. If you want something that's like JSON in, JSON out, I don't want to know about the application upgrade problems, but I want really great schema. I'm okay to let go of SQL richness, then no, SQL is great. So you have different pros and cons there.

Yeah. Okay. So many choices.

I love all my databases.

No, it's amazing. And at this point, I mean, there are just hundreds of different databases, like whatever your use case, there's going to be a database for you somewhere, I think. So finally, I always want more people to learn from. Whose work are you most interested in right now?

You know, there are a lot of people that I'm very excited to follow them and I learn a lot from them. Fortunately, being at Microsoft, we We have lots of great leaders. I always look up to my own leaders in my own chain of leaders. Arun, Scott, and Satya, of course, you know, there's a lot of great work that they do. And I always look and like learn a lot whenever I meet them and talk to them or just listen to them. When I think about externally, Andrej Karpathy, incredible, incredible thinker, a systems thinker. You know, I think he's the one, like, I love the work that he's doing in the recent times with Auto Researcher, for example. Just phenomenal. Like he has this brilliant framing of Software 2.0, how he thinks of the evolution of programming and how he thinks about how to apply LLMs from ground up, first principles approach. I really love his thinking. I would also throw in one other example of community work that I'm always impressed and inspired by, which is Postgres community. It's not a person, but it's it's the organization, but I always look to what they are doing, how they are thinking about working together. It's a miracle when you have these people across the globe working together for one cause. They're not really getting paid to commit to Postgres, right? They all have their own jobs, of course, independently, but the fact that there is that kind of attention, that kind of care, that commitment to craft, that's always inspiring.

Okay. Yeah. Lots of great choices there. I mean, obviously Andrej Karpathy responsible for like he's just ridiculously prolific in terms of coming up with like cool new ideas. And yeah, and of course, the Postgres community is just absolutely amazing. I mean, that's why it's kind of one of the world's most popular databases right now. It's a purely community-driven effort. Wonderful. All right. Thank you so much for your time, Shirish.

It's a pleasure, Richie Cotton. Really thankful. Thank you. ¡Gracias!