AWS Is Building Its Databases for AI Agents
AI agents now use more enterprise data than ever. Alan Shimel talks with G2 Krishnamoorthy, VP of AWS Database Services, about how AWS databases are changing for this agentic world. They cover the new DuckDB integration in Aurora PostgreSQL, MCP servers and serverless scale.
The breadth of AWS databases
Krishnamoorthy began his career on SQL Server and Azure data services at Microsoft. Later, he worked on backend infrastructure at Meta before he joined Amazon. Today his team runs a wide range of AWS databases. For example, Aurora and RDS handle relational work, and DynamoDB delivers key-value speed at any scale. Meanwhile, DocumentDB, Neptune and ElastiCache cover documents, graphs and in-memory data. The goal is simple: give builders the right tool for each task.
DuckDB inside Aurora PostgreSQL
Open engines like Postgres give customers portability. At the same time, AWS competes on scale, security and price performance. To link operational and analytical data, AWS now runs DuckDB inside Aurora PostgreSQL. As a result, an app can query Iceberg or Parquet files directly. Customers no longer need to copy that data back into the database.
Making AWS databases agent-ready
Agents now build more apps and more analytics. So AWS launched MCP servers that let agents query data across AWS databases through the Model Context Protocol. In addition, serverless options fit agent workloads, which tend to be spiky and short-lived. Price performance also matters, because every token can drive more database activity.
An AI-ready data foundation for AWS databases
Looking toward re:Invent and 2027, Krishnamoorthy says data is the real differentiator. After all, everyone can use the same frontier models. Therefore, AWS is focused on an open data foundation. It brings together Iceberg, a shared catalog and AWS Context, so agents can understand how enterprise data fits together.
AWS databases keep evolving as agentic AI takes hold. Explore more DevOps and cloud videos and the latest Techstrong TV interviews.
For more information please visit aws.amazon.com
Transcript
Hey everyone. Welcome back here to Techstrong TV. We've got a first time guest on here, I'm really happy to have him come on.
We were talking off camera. It's starting to look a lot like Christmas, which means re:Invent's right around the corner here, and we're getting ready for it. Of course, we'll be there, actually, not just Techstrong, but our whole Futurum team will be at AWS re:Invent.
It's the place to be on that week after Thanksgiving, right? It's become the place. So I want to introduce you to G2 Krishnamoorthy.
Krishnamoorthy. I hope I got it. I corrected myself, but- Yes, you did ...
G2, is that it? Yeah. So, right.
All right. So we had an interesting conversation off camera about how you became known as G2. Suffice to say, it was a name given to you in college at the dorm, and it's kind of stuck.
But actually, that's a great handle, right? G2. G2 is the VP of AWS Database Services at AWS, and we're going to jump more into that in a second.
But G2, so I started you here at college and you got the handle G2. But give us an idea of your journey from there to here. Yeah.
Thank you, Alan, really appreciate actually just having me on your show. Yeah, so out of college, I joined Microsoft, worked in the SQL Server and SQL Azure, and the big data and machine learning services on Azure. I spent some time in Meta, worked on their backend infrastructure, so storage, analytics, and AI.
And about four and a half years ago, I joined Amazon and have been working in the analytics and databases ADI in Amazon. So super excited to be here. Absolutely.
And I think you're being modest, but thank you, and we appreciate you. So let's talk a little bit about AWS Database Services. There was a time in my career where if you had a database, you might have the IBM or the Microsoft or an Oracle, but a database was a database was a database, right?
It was all relational, object. They had object-orientated. But we've, in the last, I don't know, 5 to 10 years, we've really seen an explosion in the kind of databases that are available to people.
And a lot of them are kind of one-trick ponies, that they do one thing really, really well. And if that's the thing you want, that's the tool for it. Others are still jack of all trade kind of thing, general purpose databases.
When you're AWS, though, you want to give the customers what they want. Talk to us a little bit about the breadth and width of AWS Database Services. Yeah, that's a great question.
So as you know, we have the broadest and deepest portfolio of database services in the cloud, and for the reasons that you actually outlined, which is that you want to make sure that if I'm a builder, I have the best tool for my task. I'm an engineer myself, you want to make sure that you have the right data structures that is actually just giving you the best cost and performance for the task that you have. That's how we have actually just evolved all of these database capability.
Relational is a great general purpose database, and we have many engines. So we actually support the relational database services and Aurora that helps customers actually run their workload. But Amazon was actually just built on key value because it actually gives you the amazing scale.
So, we have Dynamo that gives you the single millidigit performance at any scale. A lot of developers, they like to think about represent their data as a document. So MongoDB came along, and then we have the ability to, just so we have Amazon DocumentDB that just understands data like documents as their applications does.
And then, of course, we have Neptune for graph, and we have the in-memory database, which is ElastiCache that gives you the value key interface. So our goal is that we want to give our builders the best tools to get their application built, easy to build, and easy to operate, and then end scale. Yep.
I think an important thing to note, too, about today's database market is so many of these types of databases are really based on open source projects. Mm-hmm. And so you look at Aurora, PostgreSQL, it's built on Postgres.
Mm-hmm. You look at some of the other databases that you mentioned. And so it allows a company like Amazon to take this open source project and build a product line around it, right?
And that to me is really the power and beauty of open source is it lifts all boats on this rising tide. And then allows each company, each competitor in market, to go forth where they want to go with it and make it their own, so to speak, right? So the Postgres that you get with Aurora is not the vanilla one you're going to download from the project page, obviously.
And that's open source, right? That's the power of open source. Now, you guys recently did a, I don't know if it's a new release, but announced some new capabilities around Aurora, and why don't we start with that and we'll go from there.
Yeah. So as you called out, I think the Postgres databases have really broad builder option. It's actually, particularly Postgres, is actually just shown amazing amount of innovation in the community.
And from our point of view, we really like open standards and open engines because that enables customers to have the portability, right? So they can actually build it against Postgres, and then they can actually run it anywhere they can. And it actually also allows us to differentiate in ways that customers really care about in terms of scale, in terms of security, in terms of price performance.
So those are the capabilities that we want to win by differentiating in fundamentals. So that actually it's a great match for us on this. Now, as we think about our customers, unlocking the value from data through analytics, through AI, it's a huge concern for customers.
So this requires us to actually work with, make it easy for you to bring your operational data into an analytical environment. So this is why we built zero ETL. But when you go, like I worked in an ad company, you probably remember from this.
So typically what happens is that you have a campaign management app where you kind of just set up your creatives, select your audience. That's a database app. It actually just runs in there.
But the actual campaign activity, the clicks, they go to a click stream, like a Kafka, that actually gets processed in an analytical environment. So that would put the data into Parquet files or Iceberg files. But you need to close the loop.
You need to make sure that how your campaign performance is made accessible to your campaign management application. Previously, you would have had to lift that Iceberg files or Parquet files and put that into Postgres. What we did was we made Postgres to directly query that data by using the power of DuckDB.
So this is a great partnership. We actually run DuckDB in process in the Aurora Postgres, and that lets you stream that data about the campaign performance right from the Postgres query. So this is a dramatic simplification of this use case for our Aurora Postgres customers.
Excellent. Now- DuckDB Mm-hmm. Talk a little bit about this, because I'll admit I'm not as familiar with DuckDB.
I'm going to assume our audience is not either. So DuckDB is an amazing open source project, again, widely adopted, and their goal is to actually really make SQL analytics really accessible. It's an amazing team.
I'm really glad, the DuckDB team, I'm really excited that they actually joined AWS, and we actually get to work with them even more closely. We were actually working with them before. So the idea here is that their mission is to actually make analytics and democratize it.
So they build this embeddable engine that we are using with Postgres and Aurora, but it can be actually just embedded in all different environment. It can be actually embedded into your Jupyter Notebook. It can be embedded into other application.
So that makes it easy for you to actually query open data lake formats. It's really fast and very lightweight, so it actually gives you great price performance as well. The simple, fast, easy access to analytical data, that's actually an engine that is built for the agentic world.
Absolutely. Well, there, you mentioned it. Let's go into that.
In today's world, I had this discussion the other day with someone. We need to build our interfaces. We need to build our applications.
Even some of the articles that we write here at Techstrong across our various properties, for an agentic audience as much as we do for a human audience. Right. Yeah Because more and more, it's the agents reading the articles and summarizing them.
It's the agents accessing the data or putting data in. And now I'm not just talking about Aurora, I'm talking about the breadth of AWS databases. How are you making them agentic-friendly, if that's a word, where we could have sort of agent-to-agent or agent MCP to database, whatever type of access without necessarily having a human in the middle there?
Yeah. That's a great question. So you're absolutely right.
If I look at it, there's more and more of the applications that are actually built by agents, more and more of the analytics, they are actually built by agents. So as we are thinking about building the infrastructure, then we need to make sure that we are really optimizing it for agents, and maybe think about actually optimizing for agents first. Now, when you step back and look at it, we think about it in two work streams.
One is that in our operational databases, we have some of the most business-critical data. So how can we make it easy for our customers to make all of that data accessible for agentic innovation? So this is where, again, we adopted the NCP protocol.
So we launched a set of NCP server capabilities that helps customers easily enable querying of all of their database. Doesn't matter if it is Aurora or actually just Azure SQL or DynamoDB. All of that data is actually queryable through model context protocol.
So now you can actually just improve, add features, or build entirely new applications on your underlying data using agentic patterns. So that is one part. The second part is that we are realizing that agents, they have unique interaction patterns.
One, they need to scale fast because you can actually spin up a lot of agents. They are typically ephemeral because they are very spiky, potentially. So we need to make sure that our systems are actually just set up to scale for the agentic activity.
So this is where I think the serverless capabilities become really important because in serverless, actually just goes really hand-in-hand for patterns. You don't need to actually provision for peak. We have actually made it transparently scalable, and it is actually available through open accesses.
So we believe that this combination is going to be really important, and in the agentic world, it is very easy for you to actually just do a lot of analysis or actually just do a lot of transactions. So price performance is going to be very important. Just like tokenomics is actually a very important concern for customers.
These tokens actually generate database activity. How do we make sure that our systems are actually scalable and then they are actually delivering the right performance? This is actually the right price performance is going to be important for us.
Absolutely. G2, I want to return back to re:Invent, if we can. It is about a month and two weeks out, I bet.
Maybe three weeks. I know you can't tell us about announcements that are going to be made then, obviously. Mm-hmm.
But if you were looking in a crystal ball, any kind of guidance on beyond re:Invent, looking to 2027 even, what might be in store? Again, don't say anything that's going to get us all in trouble. Okay.
But what might be in store? Areas where you think we need to do better or we should be better, or we might see some new type of functionality? Yeah, I can say the following thing without actually just giving away any of the re:Invent scope, because some of it we have actually already talked about.
As you pointed out, I think getting value from agentic AI is actually really top of mind for all of our customers, right? And this is a place where we truly believe data is the differentiator, because everybody gets the same access to the same harnesses. They have access to the same frontier models.
And then what differentiates them is that AI-ready data foundation that helps them bring all of those agentic AI capabilities with their unique understanding of their customers and businesses. So a lot of the effort that we are actually doing is focused on it, like making it really easy to make all your operational data available for agentic innovation, right? And making the analysis and then the new insight that you may have actually created using agentic data processing, bringing that back into Aurora, which is what I talked about.
So here we embrace essentially an open data foundation where all of the data, we want to actually make it available through an open format like Iceberg. We want to make sure that all of your data is actually just available through a catalog. It's actually described.
And because agents really need to understand how data is related, now the semantic models is what you would have talked maybe a year or two ago. Now it is actually all part of the context. So the context is actually how the agent understands how the various data is related, and you want to be able to make it really easy for people to build their enterprise data context.
That is, covers all your data, but also learns from use, right? If you see that certain data is actually used in specific ways, then it's actually dynamically that is actually updating this context. So making sure that your entire data estate is easily available in open format, Iceberg, is together in the catalog, through data catalog, and then available through this product, AWS Context, so that now you have this amazing AI-ready data foundation that actually just pairs well with the breadth of operational database capability we have delivered.
So this is something that we talked about in New York Summit. We're going to deliver a new set of capabilities in this direction in re:Invent, and I think then this is going to be a big part of our focus in 2027 as well. I agree.
G2, we're over the 15 minutes, I apologize, but hey, thanks for stopping in here, giving us a little peek about what's coming down the road as well as what's recently been released, especially around Aurora and everything with DuckDB. I wish you lots of success, and maybe we'll see you in person in Vegas first week of December. Wonderful.
Thank you, Alan. Yeah, thank you, Alan. I'm looking forward to actually reconnecting with you.
Thank you. Absolutely. All right.
G2, let me say it one more time. Hopefully, I'll get it right. Krishnamoorthy, VP, AWS Database Services here on Techstrong TV.
We're going to take a break. We'll be back in a little bit.