Why I Chose PostgreSQL Instead of Making This Complicated

Every AI tutorial I'd looked at seemed to come with its own new database.

A vector database here. A hosted search service there. Some new framework that promised to handle the "AI part" for you, as long as you organized everything its way. Each one probably made sense for somebody. But reading about them, I kept getting the same feeling: I was about to add a lot of new moving parts to a project that already had plenty.

At this point I had a lot of text. Product details, support and policy pages, manuals, flaws and all. I needed somewhere to put it where a website agent could search it.

I already had a database I trusted.

What I already knew

This is where my day job finally started paying off in an obvious way.

I'd spent years working with web applications, servers and databases. Node.js and Express felt familiar. Databases felt familiar. I knew how to set them up, how to look inside them when something went wrong, and how to back them up so I didn't lose anything important.

I've been working with databases for more than 20 years, although PostgreSQL and I had only crossed paths on a couple of projects. It wasn't my usual go-to, but after two decades of working with databases, I figured I could handle another one.

The AI part of this project was new. Everything around it didn't have to be.

Then I found pgvector

The thing that made the decision easy was finding out about pgvector.

It's an extension for PostgreSQL that lets the database store and search vectors, the long lists of numbers that AI models use to represent the meaning of a piece of text. I didn't fully understand vectors yet (that's the next post), but I understood the important part right away: I didn't need a separate system to search by meaning. I could do it inside the same database I already knew how to run.

That meant one place for everything. The products, the pages, the manuals, the text chunks pulled out of them, and the vectors that would eventually let a website agent find the right one. One system to set up. One system to back up. One system to open up and inspect when an answer looked wrong.

That last one turned out to matter more than I realized at the time.

The whole thing, so far

By the end of April, the shape of the system looked something like this:

Python crawler          PDF manuals
        \                   /
         \                 /
       Node.js ingestion
   (import, clean up, chunk, embed)
               ↓
     PostgreSQL + pgvector
               ↓
         website agent

It's not fancy. That was the point.

Boring on purpose

I want to be careful here, because this isn't a post about how specialized tools are bad. They're not. If I were storing a billion documents, or had a team whose whole job was search, I'd probably be making a different decision.

But I wasn't. I was learning AI as I went, with a few hundred products, a website's worth of pages and a stack of manuals. For that, the boring option was good enough. And the boring option came with something the exciting ones didn't: I already understood it. When something broke, I'd be debugging the new part of the problem, not the new part and the database at the same time.

I kept choosing the boring option when the boring option was good enough.

That ended up being a pattern for the whole project, not just the database.

Not betting on one model either

The same thinking showed up in one other early decision.

I didn't want the website agent tied to a single AI model. Models change. Prices change. New ones come out, and sometimes a provider has a bad day. So instead of building the agent around one specific model, I kept the part that writes answers separate enough that the model behind it could be swapped.

At the time, that was mostly a hunch. Later, it turned into an actual model selector, and one day it was the reason the agent stayed up. But that's a story for later.

The next thing to understand

So now I had a plan for where everything would live. The text would go into PostgreSQL. The vectors would sit right next to it, thanks to pgvector.

There was just one problem. I'd chosen a database that could store vectors, and I still didn't really know what a vector was.

That was about to change, and it changed how I thought about search.