What's New In Data
A podcast by Striim (pronounced 'Stream') that covers the latest trends and news in data, cloud computing, data streaming, and analytics.
What's New In Data
Beyond Migration: How Microsoft and Striim Are Modernizing the Future of Databases Together
Modernizing databases in practice involves more than just moving data—it requires rethinking how systems, developers, and AI interact. In this episode, Shireesh Thota, Corporate Vice President of Azure Databases at Microsoft, joins Alok Pareek, co-founder and Executive Vice President of Product Development at Striim, to discuss the evolution of operational databases, the rise of real-time data movement, and what it really takes to modernize at scale.
Together, they discuss how Microsoft’s Unlimited Database Migration Program, powered by Striim, enables organizations to migrate heterogeneous sources—from SQL Server and Oracle to Postgres and beyond—into Azure with speed and precision, creating a modern data foundation ready for the next generation of intelligent applications.
What's New In Data is a data thought leadership series hosted by John Kutay who leads data and products at Striim. What's New In Data hosts industry practitioners to discuss latest trends, common patterns for real world data patterns, and analytics success stories.
So first, uh Sharish, I'd love for you to uh tell the listeners about yourself.
SPEAKER_01:Yeah, thank you. Sure. So um, you know, I'm corporate vice president for Azure databases. So what it means is that I have the remit to uh to manage all operational all TP databases for Microsoft. This includes on-premises instances like SQL Server, obviously. Um we have IaaS offerings for SQL Server and you know a couple other databases, but primarily the pass offerings in Azure SQL, Azure Customers DB, which is a very differentiated non-relational database, and then the OS databases, both Azure Postgres as well as Azure MySQL. And we've recently shipped it, uh shipped the database into Fabric as well. So SaaS, so all the way from on-premises uh to IaaS to pass to SaaS. All anything related to operational databases is kind of under my remit. And you know, if you want me to talk a little bit about the carrier, then I could just go in on a just a few bits here. Um it's it's been a long journey through the evolution of databases, I would say. Uh I started out working on SQL Server primarily. Uh I, you know, that's kind of really where I learned the fundamentals of OTP systems. Uh I worked on various aspects of SQL Server, shipped a bunch of releases back in the day. Uh, you know, it also helped me like learn the craft of building software. It was sort of my formation years. Uh and then I moved on to being one of the founding members of Cosmos DB. Uh I that was a complete shift in mindset, you know, going from a single node, high reliability systems, to kind of thinking about globally distributed, elastic kind of databases. And it's also non-relational, so there's no schema there. Um and and it kind of taught the uh distributed systems uh consistency challenges, uh, scalability, internet scale, user-facing applications, and it's kind of a different muscle. Uh along the way, I also took a single uh small detour uh to join Single Store. It's a great company, uh, which basically was focusing on real-time analytics, you know, sort of really challenging the transactional analytical boundaries with a very novel architecture. Um and that experience was valuable because it kind of forced me to think about like speed agility, leading closer to customers and deeply thinking about performance at scale and such things. And now I have the you know the privilege of uh effectively leading uh the database portfolio that I was mentioning a minute ago. Um and I I think in a way, you know, I find myself privileged and and grateful that I got a chance to uh to experience different kinds of these experiences across the board from SQL to Cosmos to you know single store and then back to all. And then now I'm focusing quite a bit on all these databases as well as open source and Postgres in particular. And you know, it kind of really puts all of these things into the context of Azure's broader mission. So so yeah, that's kind of like my uh the the the through line in my journey is that you know I've kind of really been drawn to the challenge of like developers, enterprises, systems, etc. So that's kind of really who I am. And uh yeah, I I enjoy what I do.
SPEAKER_02:Yeah. Incredible here, just the the uh both depth in what you've gone into database systems as an engineer and also the breadth of you know the different types of systems you've worked on, uh, which is I think incredibly valuable, especially as especially as these workloads are evolving so much and the requirements are are now being completely transformed by AI. We'll get into that. Aloka, you know, this is your second time on the show, and you know, you also have a very deep uh database background. Uh, would love to hear about that as well.
SPEAKER_00:Yeah, thanks, John. And uh Sharish, yeah, very impressed. You know, uh I think the journey is kind of remarkably uh parallel, I would say, right? The formation years and the foundation years, I got to be part of the Oracle database and uh kind of grew up there, um, got to got to work on a lot of interesting features. This is my second time, John, on your show. Uh so uh hopefully you'll invite me again and we'll make this one of those Saturday Night Live. I'm hoping to get a robe from you as well. Uh you know, SNL5 or maybe JK5 or something like that. And hopefully Sharish will be back as well. Um yeah, so you know, um like like you know, I said, uh I started off in the Oracle database. Um uh and and I've taken an interesting journey all the way till till uh Stream where I am right now. Uh so I'm uh one of the co-founders in Stream. I run all of the product areas here, uh right from engineering to uh product management to product support, uh documentation, all of the product aspects come under me. So I really enjoy doing that. Um and then um also it's a it's a it's a it's a great place to be. Um, you know, on one hand, we are working with some of the leading global large uh enterprise customers. Um so one day, you know, I find myself in a conversation, you know, with some of the largest banks in the world, uh, try to look at some AI use cases. And the next day I'm uh arguing with one of my engineers that um the amount of you know, just debugging stuff in the in the stream server log is excessive and I don't really like it, and we need to do something about that. So um, but just going back to the database, spend a lot of time in in recovery, John. Um uh I think at the time that I joined, I found that to be one of the hardest areas. You know, uh oftentimes uh in support, I would look at the most challenging things, and uh, you know, people would take a backup and they would restore it and the database won't open. And um, you know, oftentimes these support engineers would be like patching file headers and fixing you know checksums and stuff like that. There's like all kinds of strange utilities they had to do block edits, which are at the in this day and age, like highly uh not secure. But at that time they used to do that. So that's what kind of fascinated me towards uh towards recovery. Had a good fortune of uh uh getting involved in some of the redo generation layers. Uh so I used to own LogWriter for a long time. And it's been fascinating, you know, what uh sort of that one piece of code has uh how it has shaped kind of my own thinking, because we went all the way from kind of logging uh for backup recovery purposes to physical replication purposes, to high availability purposes, to heterogeneous integration purposes, and now to kind of you know streaming intelligence uh purposes. So it's been fantastic. Um and I got to spend some time at a company called Golden Gate, uh um which was acquired by Oracle. Uh so uh got my hands dirty in not just sort of the replication technology, but also in data integration, data quality, those those pieces. Um, and then um have been busy with uh with Stream uh for the last decade, uh, where we're trying to build a unified platform that brings together uh you know real-time integration, real-time replication, and real-time streaming uh for analytics and AI reasons. So it's been it's been fascinating and excited to be on the show.
SPEAKER_02:Also, just great to hear how we've evolved from using logs for redo and recovery purposes on a on a single database. And if you if you take that further, you can use it for heterogeneous replication where you know you can take those database logs and and use it to replicate data to multiple different types of databases. Obviously, lots of challenges there uh that that you work through. And then can also be applied for uh you know distributed uh compute uh use cases and a lot of the the address a lot of the requirements for the modern uh cloud analytics and now AI use cases, which we'll we'll get into why uh replication is critical for for uh model context protocol specifically. Uh so excited to get into that. Uh but both of you, you know, you you you know, you uh the the great part about you know speaking with both of you is that the amount of experience in databases and different types of databases. And I wanted to ask this first question. Uh Sharish, if you want to take the first one. Um, you know, when you think about the right database for the job in 2025, knowing all the challenges that are sort of ahead of us now with the known unknowns and the unknown unknowns that are sort of creeping in the background, I think you see a lot of consensus towards like using popular open source databases like Postgres, but there's also other great offerings. So I want to ask you, you know, how do you advise teams to pick the right database for the job?
SPEAKER_01:This is a great question. And I, you know, you can think of it in two different ways. On one end, you definitely want to have unification. You don't want to have too much of fragmentation, you want to have fewer choices and just invest in it to get it uh right. And then on the other hand, you want to think about best to breed and what exactly is the right tool for the right job, um, that approach. We may have taken it a little too far uh in the DBMS market, where you, you know, if you think about Stack Overflow, there are around 400 databases or something like that. Um, I don't know if the world needs 400 databases, uh, to be frank. Now, and you you mentioned Postgres. Postgres is definitely having a real moment. Um, you know, in 2025, it's the honestly, it is the default answer for a huge range of apps. Developers love it, the ecosystem is thriving. Um, and cloud providers, Azure included, of course, you know, we've made it easier to spin up Postgres uh sooner and easier to manage, easier to upgrade, and all that. Um, so if you're building a SaaS app prototyping quickly and need a uh reliable transactional store with a vibrant sort of ecosystem in Postgres, like in the form of extensions, um, just use Postgres does have some uh meaning to it. Um, you get good stuff, SQL standards, like different kinds of data types, you know, all the latest and the greatest indexing, including vector indexing these days. Um great community that keeps it moving forward. All the hyperscalers believe in it. So um so I buy that argument. Having said that, though, I will have a lot of caveats. Um we are, you know, obviously uh definitely want to be very clear that Microsoft believes in it. We are investing deeply. In fact, you know, amongst the hyperscalers, uh, we are uh we're one of the, in fact, the top committer into the Postgres source code. Um we've been committing quite a bit. We've been adding a lot of features in Postgres 17, we added a lot, 18, you know, we've done quite a bit. Um, and we'll continue to do that. Um, but back to your point about the you know, the right uh database for the right job, um, there are limits in terms of any engine design. Like, you know, there's nobody, no database engine can be really designed in a way that it can capture all the workloads. And it's always been the case, it will be the case for a long time. Database design is a non-trivial exercise, so you do have to make some choices. So whenever you make those choices, you'd have uh some gaps. Um, you know, there are databases like SQL Server for instance. Uh SQL Server is designed to be a general purpose, amazing relational database. So you could do uh through and through relational transactional systems, but you could also do SMP kind of workloads in SQL very well. Um, on the other hand, you know, there have been lots of other scenarios where you have things such as um mission critical, like you know, there's been an in-memory for some time, column store for some time. There are lots of advanced security integration challenges, uh, analytics integrations, et cetera. And these are some other places where SQL really shines very well. It's optimized for compliance, high availability, uh advanced security features, like we have you know, all this encrypted for a while, uh I'm just as an example. There are lots of other Q related improvements in SQL, which are really world-class. Um, so you know, it's not necessarily just that Postgres is the only answer. Uh, looking at the workload and deciding is important. Uh, and there are also limits in terms of how far a relational database can go. You know, for that matter, if you are looking for something that has uh a world-class RPO RTO characteristics, if you want something internet scale, user-facing, then Cosmos DB is a great choice. You know, it handles multi-region rights for sort of like RTO zero characteristics. It has single-digit millisecond latency guarantees with a four nines HLA guarantees in a single region, five nines with multi-region uh lets you tune your consistency. And there are many apps. Um, of course, you know, one of the most prolific apps of the day, uh, ChatGPT, uses Cosmos DB for that very reason. Um you know, Postgres wouldn't be able to do that kind of work to it. It's not just designed for that, right? So there's that. Then the final piece that I would say is that um, you know, this is a is an important category that was quite the rage a few years ago, vector databases, right? Uh and my view, uh my team's view has always been that we don't need a separate specialized engines to do uh vector databases. You should be able to sort of evolve it in conjunction with your operational systems. And Postgres is a great example. It has strong vector extensions, um, and you know, it covers most of all the rag scenarios, graph rag scenarios, you without having to move the data from a transactional system to another kind of a system. So um, yeah, dedicated vector databases will have their place in terms of some extreme scale or extreme design point, some exotic sort of scenario. So I'm pretty sure there is always a scenario. Um, I don't want to say that there isn't any, but for the vast majority of the enterprises, um, the complexity outweighs the benefits. And so, you know, keeping them all together in one place and having fewer choices uh is is is a is a good good way to go about, but but I also don't want to subscribe to the um to the dogma of like you know it has to be only one uh or none. Um so both points are extreme, uh, but I don't think you know there's a place for 400 different databases either.
SPEAKER_02:Uh and and fast forward to that question, you know, how is AI changing your your business, your business and in terms of you know, uh looking at the entire database landscape and and and offerings, uh including examples of, you know, you mentioned Chat GPT running on Cosmos DB, but you know, other examples of how you're applying like the roadmap of AI innovation to databases.
SPEAKER_01:In a big way, you know, a huge, huge way. So obviously, um a few patterns that have emerged, and there's a lot of frothiness in this space, clearly. So like dust has to settle down a little bit, but there's clarity. Uh there's clarity on a certain aspects, and there are a few things that are still evolving. Um, the way I think about it is that one of the best the best ways, simplest ways that I explain it to my teams is that there are, you know, there are vitamins and there are painkillers in this space. Uh you absolutely need rag pattern because a lot of the enterprise system of record information will be stored in operational databases. And that's never going to change, uh, right. And LLMs are not going to be trained on those kinds of data points because those are by design confidential and private and secured, which essentially kind of comes back to the whole challenge of how do you really get the entire value of LLMs, uh semantic searches. Well, you have to marry the foundational knowledge of the training with that of some of the system of record uh sort of engagements that you typically go through operational systems, uh, and even analytic systems or whatever databases effectively. So rag pattern is real, it's here to stay, and we'd have to do everything we can to really support it. The way people search data in databases is changing. Um, so natural d vector indexing and trying to uh if we were to design like clause uh in the modern era, it wouldn't be like a regex-based like clause, right? We would have done something like semantic like clause, but we ended up with cosine similarities and you know a very interesting looking uh syntax. Nonetheless, uh the the search by meaning, not search by regex or exact predicates, et cetera, that's going to take off and it's already happening. We are seeing that. And it has some really interesting implications in terms of how people think about searching their data, attaching it to their AI apps and all that stuff. Uh, and in particular, if you think about some of the major problems that databases always had, um, and this is kind of really where, so far, what I've said, I kind of think of them as vitamins, the painkillers. And you know, it's very important to think about the painkillers as well. The core cohort of databases, uh, either DBAs, develop data developers, people who spend all their time day to day managing these enterprise, really big applications, they really need to understand the database schema, need to understand the performance, they need to keep on tuning it. Uh, they cannot really uh, you know, they you can't design a database and forget about it, right? Um, so how can AI really help them in their day-to-day jobs? A very classic example that's something that you know we are very focused on at Microsoft, is uh help them chat with their query plans, right? Not just do something simple on the periphery, but go deeper and help them like solve their pain. It's not just a vitamin, it's a painkiller, right? Um, you may have query plans that are very deep, very complex. Uh, how do you really enable them to go chat with them without having to go through all these graphic trees? You need to keep, you know, there are many queries which the tree itself is really hard to navigate. Um, could you make it easy for them to in a natural language chat with these uh and go deeper depending on their expertise, depending on their problem? We are not far away from a point where the data the these developers, DBAs can come in and ask the question, hey, why is my database slow today? And it can give a simple answer, like, hey, you're missing an index or some, you know, your queries have changed and this this needs to happen. Or it can go all the way, like, hey, I see these wait stats and like you know, these deadlocks are happening here, or maybe something's really happening. Um, your write patterns have changed. You go really, really deep, or it could say that, you know, maybe it's time for us to look at your query plans for these queries. Uh, some things have changed here. Let's go look into it. You could go deeper and deeper, and it can be like a conversation, doesn't have to really require some really deep expertise. So, those are a few examples, and I haven't gone touched on some many other things that you could do. You could rewrite queries to be more efficient, you could do a lot of things. Um, you could certainly, you know, the simple example is natural language to query language, where people want to just give you a prompt and then get a uh get get get just a full SQL query. Those things are real. And and it's not just about the engine query, et cetera. It could be uh cost governance, it could be sort of resiliency governance, it could be security management, et cetera. So yeah, it's truly pervasive. It definitely captures all these scenarios. Um, and you know, on on the other hand, I also want to point out again, as as you were referring to, um, some of the biggest workloads of the of the day. Uh ChatGPT, of course, it's it's massive, it keeps growing significantly. Uh they all rely on our databases. In particular, ChatGPT uses Cosmos DB, all the user-facing applications of ChatGPT. Every time you you interact, any message uh operationally it goes through Cosmos DB, all the user-facing apps. We also use Postgres SQL in that space. Um it it that's sort of like the user-facing thing. I haven't even touched on how we do our development and how we think about using AI. Um, but you know, suffice it to say that it has dramatically changed in the past uh several months.
SPEAKER_02:Yeah, absolutely. It's it's it's changing very fast. Like that's and then that's usually the main takeaway from every uh episode that you know we have folks talk about AI is just the the rate at of of change is just remarkable and something we didn't see in the the 2000s or 2010s. Uh Alok, I wanted to ask you a similar question. Obviously, you know, we we talked about uh vector databases a few years ago, you know, stream, we you know, we're focusing on database replication and data streaming. Uh, and obviously vector databases came up when there was like a hype cycle for it. And you had a similar view, which is sort of like this is more like an index type rather than you know a full class of databases that we needed to support. So, and and now a few years later, we've seen that play out where you know vector extensions for the mainstream databases seem to be getting the the lion share of a of adoption there. But I also want to ask you because you know, you by working in change data capture, getting into the logs of the databases when you truly know how the database works, so you have a unique perspective on you know how to choose the right database or the right job in 2025 and beyond, you know, given all the AI transformation we're seeing.
SPEAKER_00:Yeah, um, I mean it's a great question. Uh, and I think Shirish kind of covered it uh, you know, fairly in detail, right? I I do think that, you know, one size kind of doesn't fit all. Um, you know, and and that's something in the database community, you know, we've published multiple papers on that and debated it uh far and wide. I I personally uh still believe that to be very true. You know, there are some cases, uh, John, where it makes sense to kind of invest the energy and the effort and the resources to address a very specific workload, right? But then, you know, the other aspect of it is treating that as more of a general workload for which there is an engine. So I think databases, you know, have come a long way. And I do think at this stage, take a vast look at, you know, maybe largely from the customers that we interact with, how do they think about it? I think that's kind of an interesting question. On one hand, they have like sort of as their legacy workloads, right? And they're sort of invested in that. Um, and so on one hand, I think what happens is because of that legacy investment and some of the engine choices and the feature choices that have been made maybe 20, 30 years ago, they're not able to change and evolve that very fast, right? So that's kind of like one thing that I see. So that begs the question that what do I do if I really want something fast? I want, you know, some new uh type of uh MFA, or I want to introduce some new security uh level uh feature, which otherwise wasn't thought through in the original design and so forth. So um I do see them sort of then saying, hey, how can I actually introduce these newer services and newer workloads, newer applications, but I don't have to be sort of limited to the choice that I made a while ago, right? So that introduces kind of this next aspect of my choices, um, which says, oh, maybe I can actually now uh go in and you know take a look at the best of breed for the stuff that I'm doing. And we and I'm seeing I think that a lot, right? So I think just to just to kind of uh add on to Sharish's point, like you know, you may think that, hey, this specific workload is best suited on Cosmos DB on Azure, right? So I'm going to actually go in and for a lot of this uh data, and we have seen this in some you know manufacturing areas and so forth, right? They're like I the this this is just like sheer petabytes of data, and I want to like just you know push this um in a scalable way. Um so we so we are we are seeing kind of that as the second part of it. And then there's hey, I'm a new uh kind of startup, I'm a new young uh company, and so what are my choices? Um and that's where I think cost becomes also an interesting part. And I do see that many of them will naturally gravitate towards flexibility, open source, uh relying on the community for support. And that's where you know choices like Postgres make a lot of sense. And I and at stream ourselves, when we had to make that choice, right? Right, you know, uh very earlier on, we said, well, you know, let's go uh and we looked at JavaDB uh and we looked at Postgres, right? And we started off uh and then as we evolved, you know, then customers kind of came in and said, Well, look, I'm already running, you know, one standard potentially for my mission critical workloads. Uh, could you guys also support that? Right. So then we started moving into kind of you know supporting additional RDBMS engines, uh, but we started off with Postgres. That was kind of the main point, right? I don't think there's like a one size fits all uh at all. Um I am seeing a lot of uh shift, I think, in terms of the movement towards newer types of engines, especially uh on the cloud side. I think this attitude that I'm going to manage kind of like you know my own schemas and my own tables and worry about the space management, worry about kind of the backup restore part of it. I think that is is becoming somewhat kind of outdated. I think I do see even very, very strict customers in the financial arena and so forth now changing their eight, nine years ago, they were like, no, we'll we'll never get to the cloud. And now, you know, you would almost uh that's a joke, right? I mean, I think you'd probably not be in your role very long if you have that kind of an attitude. And I think so that that is a strong shift. So we are seeing a lot of workloads sort of now, you know, either migrate or or or split uh across sort of like the legacy and the newer types of systems. So I think again, the no no magic bullet here, but I do think it really depends on sort of what journey are you in at the time that are you inheriting a workload or are you creating a workload from scratch? To you know, what are the cost choices that come into play? Um, and then finally, you know, you know, is this are the existing systems not adequate where I need to go invent my own, right? I think so those are, and which are in the minority at this point, I would say.
SPEAKER_02:So that was a long-winded answer, but you know, John, hopefully I address, you know, you know, absolutely, and you know, having the the broad kind of reactive view of what's what's happening right now and and and what changes we're gonna make to um to to to support all the dynamic shifts in the market, but also kind of tying it back to okay, you know, databases have been around for decades and they work the way they do for a reason. I mean, it's incredibly valuable to have that uh that perspective on top of that. Uh so I think that's that's that's always gonna be valuable for uh for executives and and engineering leaders to apply that in their in their thinking when they do choose, when they do architect their next generation uh applications. So speaking of next generation patterns, I'm I'm I'm gonna ask about model context protocol, uh specifically for databases, just to define it quickly, model context protocols, a really a simple wrapper for LLMs to interact with APIs for uh for either interacting with applications or retrieval from uh warehouses or databases. Sharish, I wanted to ask you uh what for MCP for databases specifically, what value and patterns are you seeing from early AI applications that are using it?
SPEAKER_01:Yeah, I so I do think that MCP has um real potential to become the missing bridge between the large language models and enterprise databases. There are certain ways to get the large language models interoperate with enterprise databases, but it requires a very intended, intentional uh sort of access pattern from the user without MCP. Uh and there's just a lot of like sort of repetition in terms of the implementations. So you know the tension has always been how do you let an LLM understand your data structures, policies without actually giving away the keys to the world, right? Uh MCP solves that. And apart from all the work that you need to do, sort of every server needs to be implemented in a different way, uh in a unique way, in a bespoken fashion. MCP solves that by creating a standardized sort of like a policy aware layer between the model and the databases. Um and instead of like the model scraping schema or free forming SQL, uh, the server on the database side, in this case, can expose um what is safe and what is like sort of clear metadata information, could be schema fragments, curated tools, whatever. They can all be put together. Um and they can be most importantly, uh can be filtered by permissions, governance, and cost awareness. And that's important because the filter really can help you in a big way. Um if you kind of zone in on the security part, it's essential because the principle of least privilege can be applied to LLM database interaction. Um, and that can safely unlock the LLM-driven apps while keeping compliance and trust and those kinds of things. So, you know, some of the patterns that come up when I think about the AA apps using MCP uh with our databases. Uh so there are a lot of folks who are thinking about policy-aware introspection. Uh, models don't need to see the full catalog, don't even see it. They get a sort of business-friendly, least privileged kind of a view with sensitive fields, masked and like with row-level rules baked in so that the the applications models basically can take advantage of the data and databases safely. Um, there's also like a constrained execution. Uh, you don't want to just instead of running anything, the model can have uh higher level verbs that they can get um in terms of let's say, hey, get me some customer metrics or like explain this query or whatever. The MCP server can then translate it, validate, and force uh, how do you really, you know, just give the data that the model wants? Um, and filtering really is important. Um, yeah, and you know, finally, I would also say there's like auditable sessions. Um, access is like time boxed, read-only by default, every action is logged. So that's also important. But just generally the power of MCP is immense, but you need to be very careful in terms of uh how you're auditing it, what are the tools, etc. There have been lots of cases in the recent times where some of these LLM models, apps, et cetera, can go and do quite a lot of damage to your database. So you've got to be very careful about it. Um, but once you've taken care of that, then uh you know the design patterns in terms of like building a semantic layer, um all the easier ways that the models can give to LLMs, those are very powerful. Definitely. Definitely helps them for LLMs to be deeply database aware, understand all the details without without again compromising on safety or compliance. That's an important shift. Use the power carefully, but there's a lot of power here.
SPEAKER_02:Absolutely. And and Alok on your side, you know, what's really required to make model context protocol work for databases in a way that enterprises can deploy this, not only with the right scale to handle their workloads and also the right governance.
SPEAKER_00:Yeah. I mean, great question. And again, look, I think number one, uh it has significantly simplified how you're exposing, you know, all kinds of engines now. Um, you know, you don't have to sort of in a proprietary way redesign every single time you're kind of you know uh working with a newer type of uh of an application, uh APIs and uh and engines, right? So MCP is super useful for that. I think in terms of databases, I think some of the things that uh that Sharish mentioned, right? Um, around right from uh privileges and roles uh to kind of the access to the data itself, um, these are significant constructs that always seem to you know you have you you must address. Now I view this as just yet one more workload, right? Um like agents coming in and then over a protocol conversationally trying to just simplify what all of us really are trying to do at the end of the day, which is, you know, let's okay, you can think of it in queries and engines and query plans and optimizers, but fundamentally I'm trying to answer a few questions that currently are are interesting for me for let's say operational analytic reasons. So the conversational style is key, right? So I do think that that's the power here. Now, as you start having conversations, we've seen this in human conversations also. Some people are super interested, really good at probing uh and getting information out, and some of them are not so good, right? And so with the right kind of agent, you could leak information, you they could get into some of the you know uh sort of not so protected parts of your database and cause havoc and damage. So, one of the ways in which I think um just like a traditional workload, right? And you Shirish mentioned the word read-only, right? So that's why I kind of went down this path. We've seen in the past where there was uncontrolled um taxing of resources on a production system. And, you know, being a database uh person, you know, an easy way to address that is to say, well, why don't I actually try to have maybe a server farm where you know I could have the rights being routed in to one location, and then I have sort of a replica form. As long as the latency is good enough for the questions, uh, you know, it's it's great, right? So I think that's one of the ways in which one of the patterns that's emerging um or is to expose kind of a database engine you know over MCP. Um, and then uh so let me take that back, database engine you know, with some replicas, and then now having one of the replicas being exposed over MCP to an agent. So that's kind of your first go-to. And then if something really warrants kind of an actual transaction where it's not conversation, but I'm actually making a transaction, then I think there's a rerouting back to back to kind of the production system. So I think that is going to be one of the interesting patterns here. Time will tell whether we'll all move in that direction. But we saw that implemented very widely globally for some of the like most critical workloads. And agents kind of spawning more agents and having that kind of uncontrolled, that does put a lot of load onto the production system. So, how do we mitigate against that? Um, I think that's where kind of some of these new patterns are are going to uh to emerge. And at least and specifically at Stream, obviously, we're we're we're right in there, right? Where we are trying to say, hey, you know, we want to make the actual intelligence that's exposed by not just one engine, but by a combination of engines simpler. And that's sort of like where we think MCP can be used to take portions of a database and then cleanse parts of it for governance and et cetera, and then expose that via maybe another system. And that could be a low-cost system. It doesn't have to be the same cost as the original system. And now you can actually have an interaction over MCP with that system. And this is sort of some of the ways in which you can try to protect uh, you know, some of the challenges that Sharish talked about, as well as you know, try to broadly just solve like a distributed replication, distributed database problem, you know, over MCP. So that's kind of like those are some of the early thoughts in the in this area. Absolutely.
SPEAKER_02:And you see these patterns for real-world agent deployments. And it's so clear that the key to success there is in the agent implementation, giving, creating these deep agents that have autonomy to solve the business use case and have the right layer of indirection where you have the infrastructure to be uh set up to handle these deep agents and any subagents that are created in the process to solve these problems. So, you know, we talk about the popular use cases like customer support uh agents that can go query the transactional data, maybe make, you know, like you were saying, Oloc, actual transactions on the database itself. But doing that in a in a protected manner through read replicas, which minimizes latency and minimizes risk. Because you don't want the agent implementation to be concerned about governance, right? You want the governance to be solved outside of that and let the agents do what they're going to do, but have the right guardrails to effectively protect uh you know any any issues that could cause. So I do think this is one of those situations where the um the innovation is certainly new with uh with uh model context protocol, but the patterns are are very similar to having analytical read replicas, right? So uh the the actual infrastructure that teams are are gonna roll out here is very similar to what uh how database architects have addressed this in the past. Like you said, Alog, it's it's yet another workload. And how would you handle another workload? Well, uh, you know, there's there's there's ways to do this. Um so very exciting. I think there's I I think this is a much more nuanced takeaway for for the listeners. I know that when when Model Context Protocol first came out, you know, if you looked at the like the official docs for it, or at least one of the sort of docs on it, I think the suggestion was just to have a uh a read-only role for for your agents on on a on a production Postgres database. And people obviously ran into the obvious issues that can stem from that. Um, you have to be a little bit uh go a little uh deeper into that problem to solve it effectively. So I I I do think the listeners can can take away uh some some really actionable uh design patterns from from uh what you both shared. So thank you. I wanted to move on to uh to Postgres and and chat about that a bit more. It's it's always a very popular topic on on this show. Uh we've had several guests who've who've gone deep into uh uh really unique uh cloud scale Postgres implementations. Sharish, first I wanted to ask you, I think Postgres is a superpower's extensibility and the community behind it. You know, what are some of the big architectural bets you would like to see the community rally around in in Postgres going forward?
SPEAKER_01:Yeah, so you know, I totally agree that the power, superpower for Postgres is definitely extensibility. It's extensibility. And you could add new data types, new indexing methods, even runtimes. And that's why it's as popular as it is today for many developers. Um the shadow side of that is complexity, as you said, right? Uh it is definitely something you can end up with. Um you can easily end up with a patchwork of extensions in your workloads. Um, they may not really all interoperate in the way that you want it to be, uh, in the in the cleanest way. Uh, and that can make it harder for Postgres to scale in production. Um, so you know, to your question about what are the few things that the architecture best that I'd like to see the community rally around. And by the way, we as Microsoft are invested deeply. Uh, we ship many extensions ourselves. Um, but I I a couple of things that I really like to see. Firstly, I think it'd be good to see like a unified story for scale out. Um, we have, you know, we we have a few solutions uh uh and we invest in CITES, we really believe in it, et cetera. And we're trying to push it, make it easier for developers to shard, not just on the uh uh a role level or a table level, even schema level. So we have different kinds of abilities to short, but um having a native consistent way to scale a workload out uh would really make Postgres uh uh the vision of sort of being a default database or whatever. I mean, again, I don't believe in being a default database, but to the extent that developers want to keep it as a default for most scenarios, um, that idea of unified scale out, and I know different people have taken different uh paths here. Uh so that's like you know, that's really important, I would say. The second thing, back to extensions, I do think that you know, standardizing uh the packaging and lifecycling, I know there's this work that's happening here, but installing and upgrading extensions, it's a bit of wild west. Um if if there is a if there's a way that the community could converge on a model where extensions are like clearly versioned, certified, they pay all well, play all well together. Uh that'll help the community. It will definitely unlock confidence for enterprises. You know, you're looking at adopting Postgres. Um, it's one of the challenges, right? So you could really go solve that. Um then I would say, you know, the third one, I I think there's a lot of work on AI primitives in Postgres, but I would love to see like them done in the Postgres way in a native way. Uh and this is where like, you know, we are definitely leaning in in terms of bringing in some of the cool things like disk ANN. Um I know there's PG vector extensions, which is very popular. Uh, but things around vector search, embeddings, retrievals, etc. I think the community needs to spend a little bit more time on agreeing on standard operators, indexing strategies, governance, and how they really operate with the runtime capabilities outside. Um, there are a lot of you know competing sort of ways to do a few things, and it's not it needs to be deeply thought through. Uh, more love is needed there. Uh, I think those are a few things. Maybe, maybe finally, I would just add one more. Um I think operability as a first class concern uh is an important thing for Postgres. Uh, given the amount of engagement that it is seeing, uh, the workload isolation, resource governance, uh, those are the kinds of things that are really important when you are trying to deploy this in uh at scale, uh especially in cloud, the core and the extension ecosystem, they need to embrace this thing natively. Uh I think that'll really go a long way. It'll reduce the cognitive load for anybody running at scale. So Postgres has already won on extensibility. I don't think there's anything, there's nobody debating about it. Um, but I think the next frontier I would say is about coherence. It's about really making sure that you scale it up to the enterprise grid, think about operability deeply, and make AI like you know, first class instance and make the extensions more certifiable, extensible, and that kind of stuff. The community is just um it's it's a brilliant community. They care about all these pieces very well, deeply. Um, and you know, we are here at Microsoft certainly engaging with them, uh, contributing. We do have uh very deeply wetted, deeply embedded sort of uh contributors and commuters as part of our team. Uh you know, we are very engaged and we look forward to partnering with the community towards these goals.
SPEAKER_02:Absolutely. And that's one of the most powerful parts is you know, through community, you get standards and you have less uh you know duplicative problem solving between companies. Uh and Aloka, I wanted to ask you, you know, you're you're also working deeply with uh Postgres through through through stream and and database modernization and innovation projects. You know, what have you seen in terms of scale and adoption of uh Postgres for uh for particular enterprise use cases?
SPEAKER_00:From a horizontal perspective, um, I think we're seeing a lot of adoption of Postgres. Um and let me just clarify what I mean by horizontal, because I mean, with with specifically uh you guys, it can mean one thing if you're in the engine level versus sort of like a like a general level. What I mean by that is um broadly from uh from an adoption perspective, as folks are thinking about adopting AI and analytics and newer workloads, they are thinking of spitting up a lot of their existing um workloads and applications. So there's this whole journey to get to the cloud. Um, and what we are seeing is number one, the question that I get asked most often is hey, look, right now I'm running this on like a massive Oracle Rack cluster. Is Postgres, is it mature? Right? Is it going to be able to actually scale to these workloads that I'm running this very, very mission-critical application on, right? And awkward question for me because I don't want to take a stance. Uh ultimately I am um, but we are seeing that question come up more and more. Um and I do think that some of the very, very large enterprises are making that bet, especially with the with the hyperscalers, right? When especially when they have their own flavor of Postgres. Because then I think they do realize that, hey, if there's something is not uh up to what you know they they need in terms of SLAs, in terms of their their roadmap for the future, they can go in and hold somebody accountable for that, right? So that I think we're seeing a shift there. Now, in terms of the adoption of Postgres, I can tell you at Stream specifically, I mean, we've had massive implementations where we've done, you know, literally within a few weeks, thousands of actual uh migrations uh into Postgres from you know on-premise types of systems. And these are not sort of lift and shift migrations, mind you, right? These are actual what I call zero-downtime live type of uh migrations, oftentimes with bi-directional links being set up, because you don't want to give up on an existing on-premise system. You want to actually have a way to move over and pull the plug at your own leisure, if so to speak, right? You don't want to say, hey, I'm gonna keep my entire um partner community, user community hostage and you know, December 31st at midnight and hope for the best, right? That I think those days are a little bit tough to swallow nowadays. So we are seeing that adoption. The other piece that also we are seeing is sort of this from the cloud to maintaining, and this is largely cost reasons as well as some SLA concerns, where we are seeing a reverse flow of limited portions of that data into what I call like you know, managed systems in Postgres that customers are managing themselves. So that's where they could have a version that now they're maintaining, um, but they just want to have that for maybe let's say in a geographically distributed retail system, it could be per online store. There's a Postgres that's running. And so they do want the reverse flow also coming in. And if to that degree, I mean, this sort of should sound familiar to your audience, going back to maybe operational to data warehouses to data mart type of uh of a pattern. Now we're seeing sort of like this you know legacy to cloud to sort of like you know, back, which is sort of like this, it's not quite a data mart, but I would say it's a data product, right? Where a team wants to actually get portions of that data, but they don't want to necessarily hit just the the core system on the cloud. And that's where, again, from a scale perspective, literally I've seen single customers adopt you know 10,000 to 15,000 Postgres databases, um, you know, and and they're they're they're pushing data from the cloud-based systems onto these uh these uh self-managed Postgres uh systems. So I think I think it has a, and Postgres has come a long way, right? From uh I mean Sharish would know better, like I think from version nine till now 17, 18 coming up and so forth. I think right from, I mean, they've caught up on on partitioning and on replication, on security, on uh, you know, just uh just developer productivity, supporting basic operations like upserts and merges and all kinds of uh JSON, JSON B data types and the in the vector vector types. So I think they've made a lot of progress, but I do think I want to pick up on one point that Sharish made, which is on the mission critical part of it. I think customers do have have have concerns there right now, where the automated uh part of, for example, um maybe just moving over from a primary to cutting switching over to a standby and back, uh, or having like a cascading system where I do move to a standby, but then all the workloads that are were relying on the primary get adequate notification and it's seamless. I mean, and I personally deal with, for example, Postgres replication slots, right? So I was very happy to see failover slots, you know, so that at least you're you don't have to reinstantiate uh if you just go to a standby, you're able to take advantage of that. I was happy to see that there's support in these decoding layers for more than one gigabyte of uh of redo uh for if a transaction spans that. So I think I think we have come a long way. And um, as the future seems very bright, and customers are super interested in it. Kind of that's sort of my take on Postgres.
SPEAKER_02:I always think that's a very important perspective for uh engineers and leaders to hear, because I think there's there's sort of two sides of the coin of hey, you know, you can try Postgres either in a lab or if you're an early stage startup scaling incrementally, you know, over you know, over the span of a year. That's completely different from an enterprise migrating an existing production workload uh that touches thousands of employees and millions of customers with lots of revenue on the line and lots of business risk, and and then migrating to a completely new database there. So like the the risk calculus is is is completely different, but it's also very promising to hear that there's certainly adoption and examples of wins and maturity uh there. So I want to ask about modernization broadly, and and maybe Sharish, we can start with with you here. So for teams that are modernizing data applications on Azure specifically, what's your practical playbook for success?
SPEAKER_01:Yeah, it's a great question. You know, at Microsoft, we basically uh we we definitely uh have a lot of evidence and starting to see a developer story emerge around uh around you know the Azure AI and it comes down to unifying three levels that that I think used to be separate uh for a long time. Uh, there is a developer experience that we go after with Copilots and VS Core. There is the data foundation, which is where Fabric and Azure databases, Microsoft Fabric and Azure databases play. Um, and then there's an application runtime in between the developer experience and the data foundation, which is basically what we have with Foundry for agents and AI workflows. So that's sort of like the three-piece stack of Microsoft that we go with, and that's the the stack. Like there's a developer experience on top, application runtime, and then there is a data foundation. So that combination is powerful. Developers don't have to juggle like multiple tools anymore. They can just open the VS Code, use co-pilots to design prompts, queries, or really go deeper if you are a pro developer, or you could use like GitHub Spark for like, you know, just getting started with VibeApps. Um and then you you you get powerful extensions where you can see the governor, the data governed right there. You could push to production easily, uh, you could monitor, but you have all these key pieces from Foundry coming in to make that stack really, really helpful. Now, if you're a team modernizing data apps on Azure, specifically since that's your question, um, the playbook that I would generally use is like uh a couple of steps. The first step I would say is like think about the developer UX. You know, you you obviously tools, tools, tools. You gotta start there and you'll really make it easy. Uh, and in the world where there are so many tools to do a lot of these things, it's really important to standardize on a few things. I would suggest VS Code, GitHub, Copilot, Azure AI extensions, and such. You know, these are very well proven. Uh, the developers should test prompts, build workflows, debug database interactions in the IDEs, get confidence because it kind of really helps them. Um they have to get familiarized because it's a new era for everyone. You know, it's like honestly, 99% of the developers haven't uh ever built workflows in this way. Uh so you have to lower the barriers and build the momentum quickly. So betting on some of these tools like VS Code, GitHub Copilot, AI extensions in Azure, et cetera, really good starting point. The step two, I would say, is like you bake in your operational guardrails. Uh, and and this is like data in specific, I would say. Uh, this is where like fabric Azure databases with built-in governance, row-level security, workloadized, all those things, um, wrapping it with Azure policy, et cetera, comes really uh handy. Um every AI generated query, you gotta have a very clear path, you know, what is the MCP strategy or what is the governance strategy, what is the observability, et cetera. So those guardrails need to be very clearly defined, rate limiting, you know, from day one, for instance. So those those that is a step two, I would say. Then the step three, I would say, is that you've got to choose your workload wins uh that prove the point before you really go and scale. Um this is perhaps one of the most important mistakes that most of the customers do. Um, you wanna you wanna like really get something going, a clear pain point that you can go build and then establish your playbook. Uh we do see patterns like copilots for analytics teams that accelerate SQL and BN, Fabric, Agentic style apps in Foundry that automate things like customer support, IT ops, et cetera, with clear SLAs, um, high volume, cost-sensitive queries for databases. These are all a few workloads that you could get get going with, right? You sort of like win them, prove a point, uh, and then then scale about it. So I think the net effect that I'm trying to say here is that developers stay in their flow. Um, ops need to get the guardrails that they want. And then on the other hand, business leaders want to see a quick proof of performance, cost saving, reliability. You could totally achieve these three things that I touched on the developers, the ops, and the business leaders. Uh, so I think this is kind of really the playbook that I generally discuss with many of our customers. Uh, then you can go from experimentation to uh to true modernization on Azure um at a large scale. So we got all the tools, you know, we have all the things that you need at every step of the way. Um, but being very clear about the stack and then going these in in these orders can really simplify. I think that's a that's a good playbook and in my mind.
SPEAKER_02:Alok, I wanted to ask you specifically, you know, we we we worked with so many uh companies that look at the data foundations that Sharish mentioned in the in the modernization process. What's your recommendation and advice strategies to to leaders who are going through major modernization?
SPEAKER_00:I mean, I think from my perspective, I think the last point, right, about business leaders trying to do it piecemeal is very important. Because often I think that um, you know, they could take sort of like a like a, hey, let's just do this thing. And then if something doesn't work, then they start re-questioning and going back and saying, hey, was this the right choice or not? So, and I've seen multiple folks be successful, large uh companies that have literally 50 to 100,000 databases be successful in this is by identifying workloads that could take advantage uh of some of the capabilities, uh, let's say, um, on the cloud, either services or infrastructure, uh, storage, compute, uh, elasticity, scale. For and and so then the question is like, you know, what do what do we do with the data, right? So I think it's it's key to make sure that if you're trying to deliver a new contained workload in the cloud, you identify sort of like, hey, what is that workload, number one? And and second, what is the data that you're going to to need? And that's where uh at least my conversation start, right? That we're giving a lot of choice to these to these uh to these businesses to say, look, you could actually take subsets of this data and safely go in and try out uh and test out the the newer uh service, the new platform, the new infrastructure, storage system, compute, whatever, however, what whatever choices you made, but still allow your workloads to run there and see whether they meet your requirements and your SLAs or not. And I think that is what the modernization journey looks like, you know, to me, right? Because I would recommend that. That, you know, oftentimes if you do a lift and shift, I think it works for test and dev type of workloads, it may work fine, but for production, it's a little risky. And shutting down a business in sort of like 24 by seven global economies is no longer an option. So, what that looks like is to have a sort of a proper testing methodology towards getting there. And and I think loosely to be very specific, you could just think of this as either database or platform modernization or application modernization, and then having a path to that by saying I'm going to actually keep maybe concurrent systems, and then that gives me that choice. Uh, so I think that should be a key part of this. Um, along the way, I think there what we do see in modernization is a tool set that's needed because rarely do we see people say, okay, I'm running a workload, I'm just going to go lift and shift and run it somewhere else. They do want to take advantage along the same time to say, hey, all these choices we made 15, 20 years ago, maybe there was not um you know instant alerting available at that time, uh, you know, based on some trigger. Um, I do want to address that in my newer system. So along the way, do I want to actually now revisit uh some of the design choices for potentially my schemas? Um do I want to um, you know, go in and denormalize certain things or normalize certain things along the way, right? So now you're introducing sort of like the the requirements for a tool set that allows you to address this in more of a comprehensive manner rather than, hey, you know, leave it up to individual developers to kind of go in and do that. So, number one, introducing those changes, number two, tracking the state of those changes and the metadata around that. So you're aware that, hey, there's two multiple systems involved, but they are running with different types of configurations, but somebody knows about it and that's queryable. So that's kind of like one part of the modernization uh that kind of comes in uh here as well. So I think those are two key pieces. And it gives you, at least from from the from the stream side, I'll tell you that we have as we've revisited this uh the modernization journey, we've also seen customers say, Well, look, I am actually doing a lot of you know what I call instant dynamic alerting, dynamic decisioning by through polls, right? And so there's this ability to introduce that in the path, especially if this is going to be a multi-year journey, right? So then if you sort of put that in the path, in the in the pipeline, that's where you sort of add this whole modernization intelligence uh to the whole system, where you're saying you're getting into now some of the interesting concepts like the difference between historical deep analytics versus streaming real-time analytics, um, doing alerting based on push-based events as opposed to poll-based events. So that's also part of modernization because that's if you take a look at the consumers today, right? Um, if you talk to anybody who's under 20, um, they don't quite understand this concept of getting an email the next day and they almost laugh at it, right? And we laugh at it too. And that's what it is, because you're seeing uh, you know, some devices where people are dynamically saying, oh, let's change this route, order this, get my food delivered by the time I'm there, my Uber is there. That is the mindset. And so I think there's a great opportunity to modernize if you also are trying to say, let's take advantage of these newer types of consumer-oriented aspects within my modernization, modernization journey. So long-winded thing. So I would say that there are four phases here. There's sort of like the, hey, I just want to adopt the cloud and I want to just like migrate to the cloud. Then there's, hey, I want to along the way re-platform certain things, right? Redesign certain things. Then there's the third piece, which is, hey, can I revisit some of the choices I'm making in terms of, you know, where am I doing my analytics? And the fourth one, obviously, is like, hey, the readiness towards, hey, the AI workload uh in the cloud. So what's needed for that? And I didn't touch on that earlier, but an example of that would be if I have a lot of unstructured document I've collected over the last 30 years as a healthcare organization, maybe it's per a perfect time to actually create vector embeddings and stick them into the newer system so that the AI services can take advantage of that through semantic searches and so forth through rack patterns. And I think that is what the modernization journey should look like, those four pieces, in my view.
SPEAKER_02:I know we mentioned vector indexes a couple of times. It is a lot more powerful than people give it credit for. It is almost magical. I mean, my anecdotal experiences it's it's always been sort of this magical thing that allows you to interface with. With data in ways you didn't imagine possible. You know, I know it's it's comparable to to search and you know uh uh I like and and you know regex-based matching, but you know, it can really be powerful when you uh lean into its its capabilities uh for for classification and summarization, sentiment analysis, things along those lines. So like and I think it is good advice, like you know, whether you're you know an enterprise that's taking this 20-year-old militarized on-prem database that can't connect to anything and just runs its workload. Now you're moving it to the cloud, you know, as you're going through that journey, yes, think like what's the art of the possible here? Because now this now this database can scale horizontally. And I have, you know, uh VS Code and copilot and all these amazing developer tools to do so much more with the rich operational data that this database is handling in real time, right, through uh through embeddings or streaming analytics or AI agents with MCP. And it's good to kind of get ahead of that in the in the both in the migration process and the modernization design and what the future looks like. Uh, because uh the the the main thing you get there is is just speed of execution and getting the ROI of the modernization so much faster rather than just saying, hey, we were doing this on-prem, now we're doing it in the cloud, and you know, almost like an apples apples comparison. Um, you know, it's it's it's it's really uh a lot more powerful than a lot of companies can can imagine, in in addition to getting a much better developer experience and internal velocity. So definitely uh uh great advice there. And then, you know, for for for companies that are already in the cloud, you know, uh I I still see this sort of you know uh segregation between like the operational database workloads and then the analytical AI workloads. And I think this this it was really great talking to both of you about this because they really have to be converged. I mean, when I I think the magic is really when you combine the operational workloads with the AI, and we're just scraping the surface of of agents. And I and Sharish, like you said as well, uh MCP is sort of the bridge between these AI agents, these deep agents that have autonomy and can solve problems with tools, uh, and get them to interact with the with the rich operational data, whether it's the customer data, the user-facing application, uh, and and and get the full value there. Because that's that's how companies go from having, you know, the uh and Alokio elaborated on this too, like the you know, the uh the the modern experiences that people expect, uh, you know, whether it's it's a chat interface, because you know, chat is taking over user experience in in so many applications. Taking your your you know, your legacy application, which might have been built in 2018, uh just like five, six years ago, and turning it into an AI native application. I think that's where engineering leaders, executives really have to look at combining the database with the AI.
SPEAKER_00:Yeah, and maybe John, I'll add one quick thing, which was you know, we were working on some some interesting stuff uh that has to do with governance and validation and so forth. Um, and this this is my personal request to Sharish also so we can actually think about. So, one of the things is then imagine that these systems are SQL and Postgres and Cosmos DB, right? And there are there are subsets of data that are that are supposed to be identical. So, one of the interesting things is you know, we have this validation capability now that we're adding to say, go in and compare these things. But I don't want to stop there, right? I want, you know, uh Sharish, you to expose some uh you know, engine or MCP, but I can also say, hey, these things don't look the same. Were you doing some uh were you responsible for replication between these systems? Uh and if so, can you tell me about these keys? Like when was the last time you had visibility about this stuff, right? So this is truly now taking sort of like this isolated transactional view within the context of one system to conversationally sort of going across these multiple agents and truly trying to answer these kinds of questions, which are super interesting for forensics and troubleshooting and debugging and all of these things that you know our engineers spent so much time on today. Absolutely. Yeah, so that's I think that's what I'm really excited about. The about that.
SPEAKER_01:Yeah, no, especially on the cyber tech, for instance. You know, these kinds of questions really matter a lot.
SPEAKER_00:Yeah, yeah, absolutely.
SPEAKER_01:Cybersecurity, I meant to say. Yeah.
SPEAKER_02:Sri Stota, Alok Parik, thank you so much for joining this episode of What's New in Data. I think it's extremely valuable uh for all the listeners today. So thank you for generously sharing all your insights and experience and and and what you're seeing uh through the work you're both embarking on right now, working with all these very innovative, uh scaled-out companies uh launching their next generation applications. So thank you so much for joining.
SPEAKER_01:Oh, thank you. Thank you, John. Thank you, Alok, for giving me this opportunity to join you guys today today. I I really enjoyed going deeper, talking about many of these technical aspects. Uh, it's an exciting time, and uh and I'm um once again thank thankful for giving me this opportunity to talk to you all.
SPEAKER_00:Yeah, and and thank you, John, again, for having me. And Sharish, it was a pleasure. Thank you. And I look forward to uh multiple future conversations with both of you guys. Thanks.