What Is a Vector DB — Explained by a Non-Math Developer

The short answer: a vector DB is built for “find something similar”

A traditional database answers WHERE name = 'apple' — it finds exact matches. A vector DB does the opposite: it finds things that are semantically similar to a given input. It’s solving a fundamentally different problem, which is exactly why RDB instincts don’t transfer well.

Why it exists

Unstructured data — text, images, documents — has no built-in way to compare “similarity” as numbers. So it first has to be converted into a vector (an array of numbers). That conversion step is called embedding.

• Structured input (text, numbers, dates, images, documents) → embedding model → vector
• The closer two vectors are (by cosine similarity, etc.), the more similar their meaning

A vector DB stores these vectors and quickly finds the ones closest to a new query vector.

The actual workflow (8 steps)

Here’s roughly what using a vector DB inside a RAG (Retrieval-Augmented Generation) pipeline looks like in practice:

1. Install — set up a vector DB such as ChromaDB, locally or on a server
2. Connect a client — connect to the DB from code
3. Create a collection — the rough equivalent of a “table” in a relational DB
4. Load data — prepare the raw text/documents to embed
5. Load a model — load an embedding model that turns text into vectors
6. Insert data — store the embedded vectors in the collection
7. Search — embed the query the same way, then look up the nearest stored vectors
8. Result — use the original text linked to those nearby vectors to generate an answer

Going deeper

I’m currently working through RAG Essential as a structured reference — a 20-chapter, 97-section tutorial covering Python, LangChain, LlamaIndex, ChromaDB, FAISS, Pinecone, Qdrant, the OpenAI API, RAGAS, LangGraph, and FastAPI. Good for digging into any of the 8 steps above chapter by chapter.

Why write this as a “beginner explanation” at all

An expert’s explanation already has the importance of a concept baked in, so it’s easy to skip over why it matters in the first place. Someone who just started learning, on the other hand, tends to explain the original problem before jumping to the technical solution. This blog leans into that: it’s a record of things learned, written down in my own words.