Vector databases explained

Behind almost every “AI-powered search” and RAG feature sits the same quiet workhorse: similarity search over vectors. If you’re building anything that finds relevant content by meaning rather than exact keywords, you need to understand vectors — and, importantly, when you do and don’t need a dedicated database for them.

From text to vectors

An embedding is a list of numbers — a vector — that captures the meaning of a piece of text (or an image, or audio). An embedding model turns “cancel my subscription” and “how do I stop being billed” into vectors that sit close together, even though they share almost no words.

That closeness is the whole trick. Meaning becomes geometry: similar concepts land near each other in a high-dimensional space, and “find related content” becomes “find nearby vectors.”

How similarity search works

Once your content is stored as vectors, retrieval is straightforward in principle:

1. Embed the user’s query into a vector.
2. Find the stored vectors closest to it — typically by cosine similarity.
3. Return the content those nearest vectors belong to.

The challenge is doing step 2 fast when you have millions of vectors. Comparing against every one is too slow, so vector indexes use approximate nearest neighbor (ANN) algorithms that trade a tiny bit of accuracy for enormous speed.

Do you actually need a vector database?

This is the question that matters, and the honest answer is: usually not at first.

If you already run PostgreSQL — and with Supabase you do — the pgvector extension adds vector columns and ANN indexing right inside your existing database. That means:

• One system to operate, back up, and secure, not two.
• Joins between your vectors and your regular relational data in a single query — filter by tenant, date, or category and similarity together.
• No extra service to sync, pay for, or keep consistent.

For most products up to millions of vectors, pgvector is not a compromise — it’s the pragmatic right answer.

When a dedicated vector database earns its place

Graduate to a specialized vector store when you hit real limits:

• Very large scale — tens or hundreds of millions of vectors where purpose-built indexing and sharding matter.
• High query throughput that would compete with your transactional workload.
• Advanced retrieval features like sophisticated hybrid search or filtering that a dedicated engine handles better.

Even then, keep the metadata your app relies on in Postgres; let the vector store do only what it’s uniquely good at.

Getting retrieval quality right

The database is rarely the hard part — retrieval quality is. A few things move it more than your choice of engine:

• Match your embedding model to your domain, and use the same model for indexing and querying.
• Combine vector search with keyword search (hybrid) so exact terms like product names still land.
• Filter before or alongside similarity so results respect tenancy and permissions.
• Re-rank the top candidates to push the best context to the front.

Start simple with pgvector, measure retrieval quality on real queries, and scale the infrastructure only when the numbers demand it. If you’re building AI search or RAG and want it fast and accurate without over-engineering the stack, talk to us.

Originally published on the Pykero blog. We build web, mobile, SaaS, and AI products — let’s talk.