I Thought "Vector DB" Was a New Tech to Learn — Turns Out I'd Already Used It
Lately, I keep seeing the term “vector database” in tech articles.
At first I thought, “great, another new technology I have to catch up on.” But once I looked into it, I realized it was very close to the vector search I’d already used with PostgreSQL when I built a RAG system before.
Sure, there are differences between dedicated vector databases and PostgreSQL extensions. But at least conceptually, if you’ve used something like pgvector for RAG, the idea is quite easy to grasp.
What Is Vector Search?
Vector search converts data like text or images into arrays of numbers, and uses the “closeness” between those arrays to retrieve results.
A regular LIKE search just checks whether a string contains certain characters.
For example, if you search for “dog,” it only matches data that literally contains the word “dog.”
Vector search, on the other hand, looks at semantic closeness rather than the literal string.
When you search for “dog,” it might surface semantically related items like “golden retriever,” “pet,” or “walk.”
In other words, it’s a technique that searches by context and meaning, not by exact or partial string matches.
The Setup I Used for RAG
I first used this mechanism when building a RAG system to let an LLM reference custom data.
The flow looks roughly like this:
- Split internal documents and business data into chunks
- Convert each chunk into a vector using embeddings
- Store the vectors in something like PostgreSQL
- Convert the user’s question into a vector too
- Retrieve data close to the question via vector search
- Pass the retrieved info to the LLM to generate a response
That “find information close to the question” step is exactly vector search.
At the time, I didn’t really think of it as “using a vector DB” — I just thought of it as running searches on PostgreSQL with pgvector.
But what I was actually doing is very close to the vector databases people talk about these days.
PostgreSQL + pgvector vs. Dedicated Vector DBs
When doing vector search in PostgreSQL, pgvector is the go-to option.
It’s a PostgreSQL extension that stores vectors and runs similarity searches. The big advantage is that you can hold your usual business data and vector data inside the same PostgreSQL instance.
For example, you can filter by regular columns like user ID, category, publish status, or update date first, and then run a vector search on top of that — that kind of usage fits naturally.
Dedicated vector databases like Pinecone, Milvus, and Chroma, on the other hand, are designed from the ground up for vector search and AI applications.
When you need to handle large volumes of vectors, prioritize search performance, scale out, or use AI-oriented search features, a dedicated DB can be a better fit.
Roughly speaking, here’s how the trade-offs break down:
- PostgreSQL + pgvector: when you want to embed it in an existing system, handle it alongside RDB data, or build a small-to-medium RAG.
- Dedicated vector DB: when you want to search massive data fast, build an AI platform centered on vector search, or prioritize scale.
You Don’t Have to Treat It as “Something Entirely New”
Looking at the word “vector database” alone, it can seem like a brand new category of technology.
But if you’ve built RAG on PostgreSQL, you’ve already touched the basic ideas.
What you actually need to learn isn’t vector search itself, but design decisions like:
- How much data are you dealing with?
- Do you want to manage it alongside an existing RDB?
- How much search speed or scale do you need?
- Do you want operations to stay within PostgreSQL, or split out to a dedicated service?
If you’re feeling pressure to “learn vector DBs,” the shortest path is probably to first build a small RAG with PostgreSQL + pgvector.
The points where you get stuck — speed, scale, operations — are exactly the problems dedicated vector DBs are built to solve.
Meeting the problem before learning the name tends to give you a much sharper picture of what the technology actually is.