Your AI Agents Don't Have A Postgres Problem (They Have A Setup Problem)

[00:00:00]Let's think about this. A Postgres couldn't handle AI agent. Somebody forgot to tell Open AI 800 million people use ChatGPT right now and the thing storing all their data is one Postgres database. One main database plus around 50 copies that handle the lookups serving millions of requests a second. So, when you see that line on the internet going around the one that says Postgres was never built for AI agents, I want to slow you down because I think it's half true. It's my opinion the half they skip is the half that costs you money. Okay, so quick ground level version for you. So, since most of you probably don't work in databases day-to-day, databases the back office of your software. It's where your orders and customers live sorted so you can pull them off very fast. And Postgres is one specific database and it's the popular ones out there. It's free and open source which means anyone can use it and look under the hood. And it's been around for decades. Banks run on it and so does Open AI. Now, an AI agent in plain English is software that does multi-step work on its own as you already know. It doesn't wait for you to click every button. So, when people say agents use a database, they mean the agent keeps saving and pulling back information the whole time it works. And as you probably know that every few months, I mean every few weeks from now, few days, the whole entire internet decides one tool is dead and a shiny new one comes out and it has to replace it or whatever, right? Right now it's Postgres. And the people saying it the loudest tend to be the ones selling the replacement, right? So, the claim sounds very technical. Here, I'm going to explain to you. So, it feels your old database was built for a humans. Agents are different. So, you need a database built for agents. My take on this is what the logic skips a step. [music] Um my personal opinion and the skipped step is where they can get you. Honestly, the one real thing that breaks is smaller than they make it sound. Every time software talks to Postgres in the back end, it opens a connection and Postgres hands that connection its own dedicated worker. We can think of it like a assigning a personal clerk to every single visitor who walks into your back office. So, there's one normal app opens a handful of connections and holds onto them. A few clerks, no problem. Now, point A's swarm of agents said it, they open connections fast in parallel, then drop them over and over and over again.

[00:02:20]The checks, the clerks pile up, they crowd the back office, and the whole thing slows down. So, what that basically means is the filing system isn't broken, it's the office that's sitting in it is now just crammed with clerks it was never stepped for. So, you put a connection puller in front of Postgres, and remember that personal clerk for every visitor? A puller turns that into a shared front desk. A few clerks now handle everyone in turn. So, 5,000 agents end up sharing maybe 50 workers. I hope that makes sense. And that is not an exotic open AI once one of these in front of their database, and it cut their connect time from 50 milliseconds to 5 milliseconds. And Andres Freund, one of their engineers who actually builds Postgres, measured what a single connection cost. He found it is tiny, under like 2 MB, and said memory wasn't even the limit that actually matters here. That scary story, the one where Postgres falls over the second agents show up, is mostly a setup problem wearing a costume. And now, I'm not going to pretend the new database companies invented nothing here. There's one trick here that didn't exist in plain Postgres, and I think it's worth understanding. It's called branching.

[00:03:33]Normally, your data and the computer running it are glued together. So, making a full copy is slow, and it can get very expensive. [music] The newer platforms, they um them, pull those two apart, separate it, and that lets them hand an agent a private copy of your whole database in under half a second.

[00:03:51]They use it, then throw it away. So, for agents, that's real. If you want every agent to run its own experiment in a sandbox and throw it away after branching, I think it can give you that really at a cheap cost. So, my take on this is I think this is very tangible actual product here, and it's a good one, my personal opinion. So, why don't we follow the money? Because that's where it gets obvious. In 2025, more than 1.25 billion dollars moved to buy Postgres companies. Databricks hit around a billion dollar for Neon. We probably use Neon a lot in our real life. And Snowflake paid around 250 million dollars for Crunchbase. I want you to sit with that for a second because the Postgres engine is free and open source, and anyone just can download it to use it today. Okay, then, what did they actually pay for? A billion and 2.5 billion dollars? They paid for the thing wrapped around it.

[00:04:43]The paper use billing and the instant copies, that's the part with the price tag. An agent needed is the label that just staple on it, right? While you keep looking at the engine. Vector search, by the way, is the bit of the tag that lets a database find things by meaning, which is what AI needs. A Postgres writer who goes by Vaughn says it's best here. "And bolting on vector search now gets the product stamped AI native." [music] The same movie we watched with cloud native.

[00:05:11]The label changes, the engine underneath does not. So, I think this can flips in two different spots. And I want you to know them before you go quote me on, you know, anything. So, if your agents really spin off and throw away thousands of databases at machine speed, I think plain Postgres on one always-on computer can hurt you. So, that's the case the serverless platforms are built for. The pay-only when you use it kind, like. And there, they are [music] in it. It also flips the other way. If your software runs steadily all day, a plain always-on computer is cheaper. So, the pay-per-use option also has to wake up when an agent calls. And that wake up has a short delay. Once you're using it more than about a third of the day, the modern option starts costing you much, much more. So, I think not copying the trend blindly will help you immensely. I mean, obviously you do you do your research though. Yeah, do your due diligence to make sure what I'm saying is accurate, you know. So, what you can do with it is put a connection puller in front of Postgres if you think you need one. The common free one is called PG Monitor.

[00:06:15]This kills most of the agents are monitoring my database paying on day one. So, and also don't buy anything labeled agent native [music] until it names one real difference under the hood. Instant copies and paper use count. Vector search does not. And you can figure out how much of the day your software is busy before you go pay for use. Busy in bursts, paper use wins.

[00:06:37]Busy all day, and always on computer is cheaper. If you're building agents, I think having them retrying on their own when they bump into each other. When two agents grab the same record, Postgres doesn't smooth it over. It just throws an error. So, this is where I land. This is all my personal opinion. Don't take this blindly. [music] Postgres wasn't built for agents the same way it wasn't built for the web or for like smartphones. It absorbed both without changing its core, the engine.

[00:07:06]And it's absorbing agents the same way right now. The work is real, yeah. I admit it. I admit that. It's just happening in the layer wrapped around the engine. I hope that makes sense. So, before you switch anything, why don't you figure out whether you got a Postgres problem or just a setup problem? And most of you, I swear to God, you have a setup problem. So, do it right the first time. Anyway, that's my personal read on this one. And if you want to see more of this, me talking about these kind of stuff, why don't you comment down below me >> [music] >> covering whatever you want because that is how our channel runs. You ask, I build, we all learn. See you in the next video.