Vector Database

Your Postgres is a stickler. Ask for email = "ada@x.com" and you get that row or you get nothing. Misspell the address and the database shrugs. It matches keys and strings. It does not match intent.

A vector database answers a different question: which stored chunks sit nearest this new one? You do not file by ID. You file by an embedding — the number-list that stands in for meaning — and you query by neighbors.

That is why "how do refunds work?" can find the paragraph that never uses the word refund. The words missed. The neighbors did not.

You still want a normal database. Orders, users, sessions, the row that must be exact — that is Postgres. The vector store is for the pile that will never have a clean primary key: help articles, transcripts, scraped PDFs, the forty markdown files you dumped in the repo at 1 a.m. You chunk them, embed them, and put the lists on a shelf that can be searched by feel.

The loop you will ship at a hackathon looks like this:

1. The user asks something in their own words.
2. You embed the question.
3. The vector store returns a handful of nearby chunks — not the whole library. The context window cannot hold the library.
4. Those chunks go into the prompt. The model writes. That whole move is RAG.

Nearest is a guess. Ask about a policy you never wrote and it will still return something — the least-wrong neighbors. Garbage that sits close is still garbage. When the agent cites a file and the answer feels slightly off, start here: it retrieved the closest page, not the right one.

What this unlocks

You stop stuffing the entire docs folder into one chat. You keep a real database for facts that must match, and a vector store for the messy prose. The product can "know" a folder without memorizing it.