Why Postgres Is Emerging as the Default Database for AI Applications

Hello, and welcome to the latest edition of the Techstrong AI Leadership Insights series. I'm your host, Mike Vizard today with Phillip Merrick, his Chief Product Officer for PG Edge. They are a provider of a distribution of Postgres, and we're having a little chat about, well, why is there so much Postgres showing up in all these different AI workloads?

'cause it was supposed to be a vector database driven world, and something different happened along the way to the forum. Philip, welcome the show. Great to be here, Mike.

Thank you so much. Uh, so you want me to jump in and, uh, maybe, uh, discuss that a little? Yeah.

Explain where we are, how we got here. I mean, uh, ultimately everybody kind of had it in their heads that this was gonna be anything but a relational database play, and yet every time we look around, there's another relational database. So how did that all come together and why is it Postgres?

Yeah, so it's not just any relational database. It's, it's Postgres. And I think you're quite right to point out how, uh, heavily, uh, Postgres is being used in AI applications, genetic AI, and, and other general AI applications.

So first of all, uh, if we sort of rewind a bit before the chat, GBT era Postgres was already winning in terms of being the, the most popular relational database among developers. Uh, certainly had taken the lead from things like MySQL and increasingly, uh, large organizations have been moving off. And, you know, even going back five and 10 years had started moving off proprietary databases such as Oracle and SQL Server in favor of Postgres.

So the momentum was already there. Uh, and the fact is developers love it because it's so easy to work with. It's also highly extensible.

Uh, and so when the AI revolution really kicked into gear, and, and particularly over the last 12 to 18 months with agents and AI app builders, uh, Postgres was already the, the default choice and the things that make it so attractive for developers make it equally attractive as a key part of, uh, an agent AI application and as a target database for the AI app builders, the AI code generators like Cursor and Rep and Claude Code and, and so on. It also seems to me like maybe this is one of the few times where developers, data scientists and database administrators are gonna agree on something, and this is important moment. 'cause historically developers would pick one database and then they'd build the app and bring it to production, and the database people would be like, we're not, not using that.

And they would spend a lot of time converting stuff from one database to another. So can we just skip that step now? Uh, well, uh, there's actually a variant of that, uh, that's, that's happening and it, it really sort of plays into the role that PG Edge is playing here, um, to, uh, talk, uh, talk my own book for a little bit, if I may.

Uh, so, so, uh, what we're seeing a lot of are, uh, applications in often cases, uh, created by citizen developers, if you will, or, you know, non coders, uh, created with the, the tools like rep lit and lovable and curse that I just referred to. Uh, and the target databases for those are, uh, Postgres platforms like Superb Base and Neon that are, are really solid implementation, the Postgres, but they run in, you know, neon's own cloud or super base's own cloud. And in a lot of large regulated enterprises, you can't go to production with that.

And so what's needed is Postgres infrastructure with AI tooling that will work with what the enterprise already has in place. So you've got your data infrastructure, uh, your, uh, either cloud or on-prem infrastructure. It's all compliant.

Uh, your security and compliance people are happy with it. Uh, apologies for the ring motion alert. I'll turn that off.

Um, they're all happy with it. Uh, so your, your AI apps, uh, like the other enterprise apps have to run on that compliant infrastructure. And that's what we do at PG Edge.

We provide a Postgres platform that you can use with, uh, those, uh, agent AI and, uh, app builder platforms and tools. Uh, but you've got flexible deployment. You can do it, uh, OnPrem or in the cloud, managed cloud, self-hosted cloud.

We support all those deployment models. Uh, we support, uh, the security and compliance tooling that you, uh, CISO and governance people and data governance people, uh, wanna work with. Uh, and so, uh, so we can sort of bridge that last mile from prototype to production.

Is there something fundamentally different about building an AI application as it pertains to the database that a traditional application? And is there something that people should be more aware of than they are today? Uh, that's a really great question.

So, so what's different when you're building an AI application? Well, generally when you're building most, uh, sort of traditional applications, you've, you've got this wonderful entity called a human end user. And so you are building and designing for that.

And you are also, uh, thinking in terms of security and governance, uh, with that human end user in in mind. Uh, but in the age of ai, you've still got those human users, but you are gonna have a whole lot of agents as agent users. And so how you think about that, how you architect for that, and how you manage security, uh, authentication and governance, all of that has to be, uh, uh, really thought about.

Uh, we, uh, are, uh, one of the few Postgres providers that has, uh, a fully functional and secure, uh, MCP server implementing the, uh, moral context protocol for connecting LLMs to, uh, databases, in this case pro Postgres. And we've taken a lot of care to build, uh, security authentication and governance into that, uh, MCP server, uh, so that you can have a, uh, suitable authentication and, uh, security scheme, uh, for, uh, for managing the agents. And so that, that's probably the, the biggest one.

Uh, but it's also, uh, a little bit of a mindset shift as well. Like, so, uh, you know, you've, I've got an agent running, uh, for me doing a whole bunch of stuff in background right now. And, you know, it's just looping along, like looking for things to do and, uh, uh, you know, your, your human users are not, are not generally, uh, uh, always looking for something to do with the application.

Uh, and so they may be not pounding it as much. So, so performance, uh, and the sort of performance that agents can, can hit your, uh, database with, you know, you've gotta think about that as well. Mm-hmm.

Are we maybe on the cusp of some sort of consolidation of our database platforms? And I'm asking this question 'cause you know, if I look around, the portfolio that's out there is everything from Oracle and MySQL and the relational side, throwing some stuff from Microsoft, and there's also, um, document databases from all kinds of folks out there, and then there's Postgres and, um, and then also there's these kind of vector databases that have shown up here, there and everywhere. Um, is there a moment in time here where we need to just kind of consolidate all that because, well, it's getting too hard to manage?

Oh, again, I might be biased, but I think Postgres is, is actually a major part of the answer to this. So if you look at what's happened with Postgres, because it is so extensible, uh, uh, developers and, you know, the Postgres open source, uh, project community themselves are able to extend Postgres for these new models. Uh, and you mentioned vector databases before.

Vector databases have, have almost been rendered irrelevant by the fact that they're a fantastic, uh, highly performant vector embedding extensions for Postgres. So Postgres has been extended to be a Vector database. There are other extensions that make it a document database.

Uh, and then when it comes to your legacy databases, Oracle MySQL, I think we call MySQL Legacy database at this point. Uh, they'll probably, uh, upset a few people, but, uh, I think it is, uh, uh, SQL Server, uh, those legacy databases, you can actually access those as if they're Postgres tables using a construct inside Postgres called Foreign data wrappers. Uh, so you can make your other databases look like Postgres as well.

And that then allows Postgres to be sort of like this, you know, central switching hub for access to, to all of your data from your agents, from your L lms. Mm-hmm. Um, Do you think that the way we manage data needs to change in the age of ai?

And I'm asking the question because we kind of manage data in isolation with a lot of silos, and maybe we don't even manage it at all. Some people say data management is an oxymoron, but when I go talk to other folks, there's this notion of maybe we're moving the metadata and more semantic approaches to managing data, and will that just change the way we think about databases, the platforms and everything else we do to figure out how to deal with all this data we're generating more of, which is happening every day by the second, right? Yeah.

Yeah, that's, that's another great question. So, uh, you know, I, I don't want to oversimplify things and just say, well, yeah, the answer is just put everything into Postgres or make everything accessible, the Postgres. Uh, although in some cases that's a, a pretty good answer.

Uh, yeah, I think the world's more complicated than that. Uh, and, you know, there is some level of effort in, uh, migrating data and, and, uh, uh, even, you know, making it all accessible from, from Postgres. So, uh, I, I think we're, you know, we're gonna be living with, uh, a pretty varied and heterogeneous, uh, landscape, uh, for a while.

But what AI does is it, it really makes it imperative to make sure all of your data is accessible in some sort of standard way. Uh, and so, you know, if if it's not through Postgres as your foundational layer, then it, you know, it's gonna have to be through, through something else. Uh, so, so that really does become an imperative.

It's like, well, you know, we need the models and the agents to be able to get to all of our data in a managed and governed fashion, uh, because otherwise we're just, you know, behind the eight ball, and we're not gonna get, we're not gonna get anything like the value out of the AI investment that we're making. You know, that's one of the issues right now is like, so much investment is going into ai. Well, you know, what do we need to do to make sure that we more than deliver on, on the, uh, on the value side?

Uh, so, uh, so, so making sure that the data's accessible in some sensible fashion for the models and the agents, uh, is one thing. Uh, and then, you know, the other is, is having, uh, a sensible governance strategy. So, you know, we, we've all, uh, you know, read and heard the stories of, uh, the, uh, you know, the executive, or in one case it was an executive at, uh, an AI company.

I think when, uh, they, uh, uh, were, um, uh, forgetting that, uh, absent the right controls, anything they put in into an LLM prompt, uh, can, uh, can then be used to, to further train the model. And, and so you've got a data egress and data leakage problem that way, uh, making sure that you've got your use of LLMs locked down. Uh, you've got enterprise, uh, uh, licenses and agreements in place that make sure that you're not gonna have data exfiltration.

Now, these are all the things that we've gotta think about regarding our data assets in the age of ai. Mm-hmm. Um, You know, you mentioned governance and data and ai, and we hear a lot about MCP, otherwise known as the model context protocol.

And I can't help but wonder, well, shouldn't that just be kinda deeply connected to the database, which will provide the governance capabilities that we need to make that data accessible to the AI agents? Or is that an oversimplification? Uh, well, right now I think, I think we can, uh, do the innovation around security and governance, uh, that we need, uh, in the model context, pro protocol server as an independent layer.

Uh, and being able to do that independent of the database, I think is, is really useful, uh, at this point in the development of things, uh, things very, very fast moving. Uh, the people who actually, uh, develop, uh, the, uh, the core databases, you know, uh, quite rightfully, uh, don't like to change those database engines, uh, and the, you know, the code that runs them, uh, particularly, uh, quickly. Uh, so, so having MCP and the MCP server as a, a layer where we can experiment, innovate, figure out how to get things right, then over time, you know, the database can slowly subsume some of that.

Uh, and, uh, you know, one thing that you, you know, want to do is, is figure out a good way of aligning, uh, say Postgres, uh, management of users and, uh, permissions, you know, align that with the security layer that you're implementing in the MCP server, uh, which, which can be independent. So you want to be able to align, align those pretty tightly in, in, uh, a lot of cases. So, so I think we'll see a lot of innovation in that.

But, uh, uh, as I say, you know, the, it's a good and proper thing that development of database engines themselves moves at a, a relatively slow pace. We, we want to do the innovation outside of that until things settle down a bit. Are you at all concerned that also in the age of AI, that maybe the amount of data that we're trying to store and manage will ultimately overwhelm our database systems?

Which, you know, the choice has always been scale up or scale out, and both those things have interesting challenges that go with it, but, um, do we need to, to think about data management, data storage differently? Uh, you're, you are full of great questions. Uh, so yeah, that's, uh, is as, as you were, uh, phrasing the question there, I was reminded of, uh, you know, a couple of our customers that we're spending quite a bit of time with we're, you know, they are hitting up against some Postgres limits in terms of, of database size and, and, uh, so forth.

And, and so we're working with them on, on navigating and, and pushing out those limits. Uh, so I think so long as we can innovate quickly enough, we, we might be okay, uh, while also using sensible strategies, um, you know, does everything have to go in the database? Um, uh, you know, if, if you've got, uh, a lot of, um, uh, static content, you know, it's perfectly adequate to keep that as, you know, and you, you, uh, don't need to do a lot of indexing of that, you know, keep that in flat files in S3 and things like that.

I, I, I think, you know, thinking about the, you know, not all data is, is equal, right? Not all data sources are equal. Not all, um, uh, actual TROs of data are equal.

Like, so, you know, what, what's the relative value of, of these pieces of data? Uh, what kind of access do you, do you really need? Um, uh, because, you know, maybe not everything has to, uh, has to go into the database.

You can also think about, uh, classes of storage. Uh, so things that are infrequently accessed, you know, uh, you know, you're not, you're not making that available on, uh, the most expensive SSD that, that, uh, you can get from Amazon or, or your hardware supplier. Mm-hmm.

Um, what's the one thing you see people doing with AI and data then just makes you shake your head a little bit and go, folks, I think we need to be a little bit smarter than that. Uh, oh, you mean, other than, uh, uh, letting, uh, uh, a million personal agents communicate on their own social network, uh, over the last weekend, yes. Ideas, what could go wrong?

Uh, uh, well, I don't know, next to that example is kind of hard to think of, uh, anything comparable. Uh, although that, that is obviously a very, very interesting experiment. Anybody who hasn't looked at, uh, malt book and the whole open claw thing should, uh, should at least take a look.

Um, and, and maybe very gingerly try it out for yourself. Uh, I've, uh, I've got open claw running on, uh, a server in a server cupboard here, uh, that, uh, you know, I can pull the plug on if I need to. And, you know, it's, it's an absolute burner of a machine, so, so not too worried about that.

Um, yeah, so I think the, the things we see people doing are, uh, uh, you know, not, not thinking through what, uh, an app is going to look like in production, in their environment. Uh, so, uh, and, and I think it's probably more than non-technical people prone to thinking this, but a, a lot of developers as well, like, you know, developers are, I think, quite prone to, you know, just getting something going with the tools that are like easiest for them to access and, and spin up. Uh, and the tools that are easiest to access and spin up, and the infrastructure that's easiest to spin up may not be, uh, suitable for production in, in your, uh, organization.

So, so, so, you know, I'd, I'd say that is, uh, you know, from a pro professional perspective and, and not looking at personal AI agents. So I'd, I'd say that's maybe the number one thing. All right, well, folks, you heard it here.

Hey, the way we manage data may need to change. 'cause we are entering an entirely new era. We may not have sorted it all out just yet, but there'll be a database somewhere.

And the question is, is how many of 'em do you really need? And how are you gonna scale these things? Hey, Philip, thanks for being on the show.

It has been an absolute pleasure. Thank you so much, Mike. All right.

ai Leadership Insight series. You can find this episode, others on our website. We invite you to check 'em all out.

Until then, we'll see you next time.