Vector databases, without the mystery.
A vector database stores embeddings, the number lists that represent the meaning of a text, image or audio clip, and answers one question quickly: which stored items are closest to this one? That nearest-neighbour search is what powers semantic search, recommendations and the retrieval step of RAG.
- Stores
- Embeddings plus metadata and the source text
- Answers
- Nearest neighbours to a query vector
- Options
- pgvector, FAISS, Qdrant, Chroma, Weaviate, Pinecone, Milvus
- Often enough
- Postgres with pgvector
- 5production AI apps
- 14engineers led
- 200+students mentored
Questions students ask
The vector database questions that come up most, answered plainly.
What is a vector database?
A vector database is a store built around one operation: given a query vector, return the stored vectors nearest to it, fast, even when there are millions. Each stored vector is an embedding of something, a paragraph, a product, an image, along with metadata and usually the original text. Traditional databases index exact values; a vector database indexes similarity, which is what you need when the question is 'what means roughly the same as this?'
What is vector database in AI?
In AI systems it is the memory that language models look things up in. An embedding model turns your documents into vectors once; at query time the question is embedded the same way and the database returns the closest chunks, which are handed to the model. That is the retrieval half of retrieval-augmented generation. It also powers semantic search boxes, duplicate detection and recommendation feeds.
How vector databases work
Comparing a query against every stored vector is exact but slow at scale, so vector databases build approximate nearest-neighbour indexes. HNSW, the most common, is a layered graph where each vector links to its neighbours; a search hops across the graph towards the query and finds very close matches while touching a tiny fraction of the data. IVF and product quantisation trade a little accuracy for less memory. Similarity is usually cosine or dot product.
Two details matter in practice. First, metadata filtering: a real query is rarely 'nearest to this vector' alone, it is 'nearest among documents for this customer, in this language, after this date'. Good databases apply the filter inside the index walk; weak ones fetch a thousand neighbours and filter afterwards, which silently drops results. Second, index parameters: HNSW has settings for how many links each node keeps and how wide the search beam is, and raising them trades memory and latency for recall. Measure recall against an exact scan on a sample before you trust an approximate index in production. In RAG.NextUpgrad I check that number whenever the corpus grows, because an index tuned for ten thousand chunks behaves differently at a million.
Why vector database
Because meaning does not match on keywords. A user asking 'can I return a damaged parcel' should find the paragraph titled 'refunds for goods received in poor condition'. Keyword search misses it; a vector search finds it because the embeddings are close. For a few thousand items you can do this with a numpy array. Past that, you want an index, filtering by metadata, persistence and concurrent updates, which is what the database adds.
What is vector database in RAG?
It is the index the retriever queries. In RAG.NextUpgrad I keep a dense index of chunk embeddings for meaning and a BM25 index for exact terms, run both for every question, and fuse the results before re-ranking. The vector database does the dense half. Metadata filters matter here: restricting a search to one document, one customer or one date range is often what turns an almost-right answer into the right one.
What is vector database and embedding?
They are two halves of one idea. An embedding is a vector that an embedding model produces from text, where similar texts produce nearby vectors. A vector database stores those vectors and searches them. Without embeddings there is nothing to store; without a vector database the search is a slow full scan. Choose the embedding model first (it determines the vector size and quality), then the store.
What are vector databases used for?
- Retrieval for RAG assistants over documents, tickets and wikis.
- Semantic search where users phrase things their own way.
- Recommendations: items whose embeddings sit near what a user liked.
- Deduplication and clustering of near-identical records.
- Image and audio search, since those can be embedded too.
How to create vector database
Start with Postgres and the pgvector extension if you already run Postgres: add a vector column, insert embeddings, create an HNSW index, query with the distance operator. If you want a dedicated service, Qdrant runs in one Docker container and has a clean filter syntax; FAISS is a library for in-process indexes when you do not need a server. Keep the chunk text and metadata next to the vector so a search result is immediately usable.
How to query vector database
Embed the query with the same model you used for the documents; this matters, mixing models gives meaningless distances. Ask for the top k by cosine similarity, typically ten to fifty, with any metadata filters applied in the same query so the index can use them. Then re-rank the candidates with a cross-encoder and keep the top handful. Return the text, the score and the source so the application can cite it.
What is Pinecone vector database?
Pinecone is a hosted vector database: you send vectors over an API and it manages indexing, scaling and replication for you. It is convenient when you do not want to operate infrastructure. The trade-off is a dependency on a paid service and your data living outside your own database. For a student project or an early product I would reach for pgvector or Qdrant first and move only if scale demands it.
Which one to pick
A quick map of the common choices.
pgvector
You already run Postgres and want one database, transactions and joins. Enough for most products.
Qdrant or Weaviate
A dedicated server with rich filtering and good performance; one container to run.
FAISS or Chroma
In-process libraries for prototypes, notebooks and single-machine apps; no server to manage.
In the room
Where these systems get explained to students.


Read next
The pieces around the database.
Choosing a store for a real product?
I can look at your data, your scale and your stack and tell you which one, and why.

