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.

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.

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.

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.

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.

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.

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.

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.

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.