Database Management and Developer Collaboration with G2 Krishnamoorthy

Hey guys, thanks for the throw. We're here with G two, who's the vice president of database services for AWS, and we're talking about how to organize all these different databases and formats there are out there because you can't build an application on one database anymore. G two, welcome to show.

Yeah, Michael, thank you for actually this opportunity to connect with you. Uh, I love to actually geek out with you on what's happening in AWS databases. I think people gotten used to the idea that there would might be one or two different databases that they might have to manage, but now we live in a world where, I don't know, there could be half a dozen.

It all depends on what the applications are and the use cases, and AI is making that even more complex. How should we approach the management of that? How can we make that so mere mortals who are, uh, DBAs or anybody else can get their arms around this?

Yeah, that's a great question. So, uh, the way I think about databases is, uh, you know, it's a, like, it's like data structures, right? So there is no one data structure you would use as a developer to represent your data.

You wanna pick the data structure that works well for your access pattern. So it's the same thing with databases. Uh, you might actually just model your information in a manner that is actually just most, uh, flexible and most performant for your application.

And you wanna make sure that, uh, you have the database services that is, um, dealing with that, like in a data model very efficiently. So, uh, if you are actually thinking, like, if you are actually doing some, uh, some sort of, um, analysis of connections between actually, uh, between people, then a graph database actually makes a lot of sense. Uh, if you're actually just using like, you know, J documents as your core data model, then you want to have something like, um, uh, document db, which actually just understands documents in a native manner.

And of course you have relational, which is, uh, the granddaddy of all of the databases. And then you have key value, which is giving you, uh, like great control over the performance of individual operations, like, uh, DynamoDB. So we wanna meet customers or builders where they are.

We let them actually just pick the, the data model that actually works best for them, and then we provide them with a range of database services that does that. Well. Now, one of the things you call out is that like, how do you like the effort that typically takes to actually run a large scale, uh, data system, actually just stay resilient, stay current, um, and like, one of the big areas of our focus is that how do we make that effortless?

How do we take away that toil that comes with, uh, managing a relational database or actually managing it over current database, or scaling it, or dealing with actually just, um, like, um, varying access patterns and keeping it efficient. So we wanna make that really easy for our customers so that they can focus on creating value for their users. One of the things I keep running into is this, I guess, for lack of a better phrase, almost religious debate, but there are some folks who have a database who will say, we'll add support for multiple types to that, and therefore you don't need a separate database to go do all that capability.

And then there are those who are saying that, well, for performance, scalability or whatever other issue it might be, you need a database that specifically is optimized to run that data type. Is there a right answer here, or is this kind of just, you know, us going back and forth with each other? But it all depends on the use case.

Um, so it's a, it's a really great question. So, um, so I think like, you know, the, I wouldn't say that like, hey, there is a one size fits all, um, uh, on this one. Like, and this is where I think we actually just really like in a look at, um, what, what works best for our customers, what their needs are.

And we have actually done, like, you know, a combination of things like, for example, we said, okay, we will, a graph is actually sufficiently different, uh, as a capability, we wanna actually just optimize around it. So we built essentially a purpose built database, Neptune for graph. Uh, but when it came to like, you know, vectors, uh, that was there, then we realized that the, like vector is actually just a, a core capability that, uh, you wanna bring to pretty much all your applications.

So making vectors as, uh, as a data type or an index type, and then bringing it to relational, bringing it to, uh, your document, bringing it to your caches, that is actually simpler for customers to adopt. So we are actually just taking this approach where like, let's look at essentially the specific, uh, application need or capability need, and then figure out the best path for it. Do we build that purpose-built database, uh, around it, or do we actually bring it as a feature in the different databases that we already have?

And of course, AI is kind of changing the whole data landscape these days, but how, I mean, I think people understand that there's more data and it has to be in the right place at the right time, but I'm not quite clear if people understand how to go about doing that. I mean, there's databases and then there's data engineering. How do I meld all this together in a way that's cohesive?

So, uh, that's a great question. So, um, so the way I think about it is that this, uh, product generative AI is really transformative because it, uh, it enables customers to actually interact, uh, with their applications in a truly novel way. Uh, like I think back to like maybe, um, 20 years or maybe 25 years now, where suddenly like search box became essentially just a part of every application.

So it's, uh, easy for you to actually just search for your information on in a form. And I anticipate that every, like, you know, application that customers were interacting with, uh, it'll have a chat assistance. It'll actually just take natural language prompts and enable customers to like, you know, retrieve information or actually drive actions.

Um, so like, you know, there will be AI agents. So the way we think about actually just, uh, enhancing databases for this is that how do we help our customers easily build these experiences into their applications by using capabilities? So one of the ways, um, like we, we did that is by actually adding vector capabilities into the databases so that it's easy for you to actually just, um, um, index your, like into your data, put that next to your, uh, structured information already.

So it simplifies adding these capabilities. Uh, as another way we are actually doing this is that we added the zero ETL capability so that you, it's easy for you to actually bring your data in your applications into your analytical and AI systems so that you can do machine learning, do generative ai, like, you know, just, uh, uh, capabilities on it so that like we are taking away the, the oil that may exist in terms of, uh, putting your data at work. So like, we anticipate that like all of the places where users are interacting, they would wanna actually now interact with natural language.

So how do we build the underlying capabilities to enable that? And going beyond chat assistance, we expect that like, you know, more applications are gonna build agent experiences so that you can hand off a task to accomplish. An example of this is that, like there was a tool that I use, uh, to like, you know, onboard new hires today, I have to work through a set of steps, uh, in that tool to actually set up the embark plan, the new hire plan, and tomorrow, um, pretty soon I can actually just make that into a task for an agent that that application has, so that it'll take essentially the set of steps, it'll know essentially what typical like a, uh, onboarding would look like, and it'll actually put that together on my behalf and driving a lot of productivity for me as an end user for that application.

How should these teams be structured? I mean, historically we had DBAs and then we had the saw the rise of data engineers, um, but they're AI specialists now, and there's data security people. I mean, it almost seems like it takes a village to do anything.

So is there some way to think about the organization of these teams that maybe we should kinda all collectively have at the same time? In, in some ways, I think we have gone through a period where there are more and more specialization. So like, uh, you have, uh, developers who are actually building the database applications, and then that data is actually made available for like, you know, for analytics and, uh, machine learning purposes.

Like there is a data engineers who is curating that one, and then you have ML engineers. Um, so, but what I'm seeing is that with the generative AI, uh, capabilities, it really, um, like lowers the level of expertise that is needed or a vast range of, uh, typical scenarios. So now, uh, it is possible with the, with the, like a generative AI assistance and these, uh, platforms that are actually just, that allows you to actually do, um, like more tools like the new SageMaker platform, it really allows you to do from self-service ai, all the way to building generative AI applications.

So the combination of this is enabling, um, seeing people to wear multiple hats. So I anticipate that going, like as we go forward, uh, you know, this notion of a like full stack developer equivalent in like data and AI is gonna become more and more prevalent where the person building the applications, they have the underlying capability, they can use zero ETL to make their data available, uh, for analytics and ai, and they're able to use the generative AI assistant in something like the new SageMaker platform to prepare the data, uh, be able to actually build machine learning models, or actually build generative AI applications like experiences and put it back into the, into the application. So I think the assistance that capability is gonna enable, um, the same builder to do a lot more of the roles that today might require actually specialist.

So In that light, I mean, as long as I can remember, everybody keeps talking about, you know, we're gonna move beyond sql, but SQL stays with us and is the lingua franca for, to accessing data, but now we have all these agents that are gonna help us to access data. So what would be the relationship between, uh, SQL and these AI agents? And I know you guys have been working on some distributed SQL technologies.

So are these two things going hand in hand or do they replace each other, or how, how should we think about this? Yeah, that's a, that's a really great question. So let, let me touch on the, like, you know, the distributed SQL capability that, uh, that we worked on.

Um, so we are really excited about it. We have actually services like, um, like DynamoDB that gives you, like, gives you actually really high performance, um, like reads and writes at any scale. So, uh, and they are, but they actually just, uh, reduce the, like, you know, the, it actually does that on a reduced set of surfaces and capabilities in terms of, uh, like, you know, the, uh, transactional semantics, the ability to do joins.

So it actually has a, a, a smaller surface area, and then you get this amazing scale at amazing performance. Um, and then on the other, the, on the other end of the spectrum, we have like, you know, something like Aurora, which gives you the full, like, you know, that capability of something like, uh, a fairly mature SQL engine that is Postgres. Uh, but there, like, you know, you have to, the application needs to actually just, uh, sh their app, like their, uh, their workload in such a way that you can take advantage of something like, uh, the Aurora, uh, limitless database capability.

Now, what we wanted to do with, uh, like, you know, dsql is that how do we bring the best of both worlds? How do we actually allow, uh, the rich, uh, like, you know, the, uh, processing capabilities of a SQL database, uh, and then, uh, the, the transactional capabilities, uh, be able to run it multi-region and be it able to run it in a completely serverless manner, um, so that it's a lot less effort for someone to build a SQL application that is really actually just, uh, scaling up and down with your database can run synchronously and be consistent across multiple regions. So we were able to actually just take all of the lessons that we learned from like Lambda S3, Aurora and Dymo db, and then put it together in the dsql, which, um, like for a distributed sql, it's the fastest reason, right?

It's, uh, four to six times faster than the alternatives that are actually out there, um, for this capability. Now, how this actually just fits into, um, the, uh, the agentic world is that like, you know, the, from a, like the agents, they really want the, like a, an ability to actually interact with the broad range of systems, um, so that they can actually take actions on behalf of their users. So, um, it's very important that we actually allow, uh, these agents to interact with, um, SQL based systems.

That is actually, a lot of the data is actually just in SQL based systems. Uh, and then we are seeing that like there are some, uh, protocols emerging as, um, broadly adopted, like a model context protocol. This was actually initially proposed by like, anthropic is now becoming more of an ad hoc standard.

So, uh, last year, uh, we actually just, uh, launched this capability called, um, a structured knowledge basis. Uh, this is actually part of Bedrock, uh, that was actually just enabling something like, um, um, like, uh, JDBC, like a database connectivity type interface. So it, we called it the QDBC or structured knowledge basis.

So if I'm a, uh, as a database developer who's familiar with JDBC or RD bbc, I have a similar API interaction that I can do to my database. So we anticipate that this world, there'll be like, you know, uh, multiple protocols that would de emerge, like, you know, model context protocol is one of them, and we will actually support it, but we will actually try to bring these, um, the access capabilities to like, you know, the other protocols that may be familiar with, uh, like, you know, the database users like JDBC or ODBC, and we'll see actually just what the customer responses. The structured knowledge basis has been very popular.

It enables customers to actually easily add like, uh, the, uh, prompts based interactions with their system. And, uh, we actually are building the model, uh, product protocol capabilities. And this is a very new space.

So we anticipate that the access patterns and the technologies that is actually just, uh, would be rapidly emerging. And then our goal is to actually just make sure that, uh, the, the patterns that are actually, uh, that are getting popular is something that we would actually just support as, um, in the AWS database services to make sure that builders, no matter actually just what, uh, they are actually just preferring to actually work, build these capabilities. They have easy access to the data that is AWS database services for them.

And what's your best advice to folks about how to bring this all together? Because I mean, for as long as I can remember, we always had some tension between developers and the DBAs, but it seems like all this is coming together in some cohesive way. So how do I get everybody on board or on the same page?

Yeah, that's a, that's a really great question. So, um, so I think about the space in, in two ways. Uh, one is, uh, there is, there is a need for some experimentation.

So these are like really capable technologies, but in the end, they need to fit in the context of the user experience you are delivering for, uh, your users. So some level of experimentation in terms of what, like, you know, how you would introduce these capabilities to make your users actually just productive. That is, uh, something that is really important.

And then the second is that, you know, one of the friction that always existed between the developer and the DBA is because, um, you know, the, you know, the kind of queries that you would write or the kind of load you may place on the database, uh, might vary. And then like the DBA is responsible for keeping the database actually just functioning and healthy. Now by adopting something like, um, the am like the, uh, Aurora distributor sql, um, it has the ability to actually scale to unpredictable workload.

It's actually running each of the queries in its own isolated container, which means that it cannot actually just, there is no noisy neighbor challenges that you might face. So the combination of actually this, uh, effortless scaling and, uh, like, you know, easy management that you would get with something like Aurora Dsql and with the experimentation that you would be doing, then you are able to actually just move, move pretty like, you know, fast and move with confidence in bringing these, uh, capabilities to your users. So like the combination of actually just an effortless database and experimentation is actually what is needed to actually succeed with these new capabilities.

All right, folks, you heard it here. And hey, there's this primordial soup of stuff out there. It's sql, the cloud, dynamic resources, AI agents, and somebody just needs a catalyst to bring it all together.

Hey, G two, thanks for being on the show. Thank you, Michael. And back to you guys in the studio.