TL;DR: What is a vector database? It’s a database built to store embeddings, lists of numbers that capture the meaning of text, images or audio, and to quickly find the items whose vectors are closest to a query. That “nearest neighbor” search is what powers semantic search, recommendation engines and retrieval-augmented generation (RAG) for chatbots. Popular options include Pinecone, Milvus, Weaviate, Qdrant, Chroma and the pgvector extension for PostgreSQL. You don’t always need a dedicated one: for small projects, a library like FAISS or pgvector is often enough.
If you’ve read about AI chatbots answering questions from company documents, you’ve probably run into the question what is a vector database and why everyone building with AI seems to need one. This guide explains it in plain English: how vector databases work, how they differ from regular databases, the main products, and when you actually need one.

What is a vector database, in simple terms?
A regular database finds rows that exactly match what you ask for: a customer ID, a date range, a product name. A vector database finds things that are similar in meaning. Ask for “cheap flights to Paris” and it can return a document titled “budget travel to France,” even though the words barely overlap.
It does this by storing vectors, also called embeddings. An embedding model turns a piece of content into a long list of numbers, often hundreds or thousands of them. Content with similar meaning ends up with similar numbers, so it sits close together in that high-dimensional “space.” The database’s job is to answer one question very fast: which stored vectors are nearest to this new one?
How a vector database works
1. Turning content into embeddings
First, each document, image or product description is split into chunks and passed through an embedding model. The output vector is stored alongside the original text and any metadata, such as author, date or category.
2. Indexing for fast search
Comparing a query against millions of vectors one by one would be slow. So vector databases build special indexes for approximate nearest neighbor (ANN) search, which trade a tiny bit of accuracy for huge speed gains. A widely used method is HNSW (Hierarchical Navigable Small World), described in a 2016 research paper by Malkov and Yashunin, which builds a layered graph you can “hop” through to reach close matches quickly. Other approaches group vectors into clusters (IVF) or compress them (product quantization), techniques used in Meta’s open-source FAISS library.
3. Measuring similarity
“Closeness” is calculated with a distance metric. The common ones are:
- Cosine similarity: compares the angle between two vectors; popular for text.
- Dot product: similar to cosine but also sensitive to vector length.
- Euclidean (L2) distance: the straight-line distance between two points.
Which one to use usually depends on how your embedding model was trained; model documentation typically says.
4. Querying and filtering
At search time, the user’s query is embedded with the same model, the database finds the top matches, and it can filter them by metadata (“only documents from 2026,” “only English”). Many systems also support hybrid search, combining keyword matching with vector similarity for better results on names, codes and exact phrases.
Vector database vs traditional database
| Traditional (relational) database | Vector database | |
|---|---|---|
| Stores | Rows and columns of structured data | High-dimensional vectors plus metadata |
| Typical query | Exact match, filters, joins (SQL) | “Find the most similar items to this” |
| Results | Exact and deterministic | Ranked by similarity; usually approximate |
| Index types | B-trees, hash indexes | HNSW, IVF, product quantization |
| Best for | Transactions, records, reporting | Semantic search, RAG, recommendations |
The line is blurring. PostgreSQL can store and search vectors through the open-source pgvector extension, and many established databases and search engines have added vector search features.
What vector databases are used for
- RAG for chatbots. The most common use today. Before a large language model answers, the app retrieves the most relevant chunks from your documents and adds them to the prompt. Our guide to RAG in AI explains the full pipeline.
- Semantic search. Searching help centers, legal files or codebases by meaning rather than keywords.
- Recommendations. “Customers who liked this also liked” based on similarity between product or user vectors.
- Image and audio search. Finding visually similar photos or matching songs.
- Deduplication and anomaly detection. Spotting near-duplicate content or unusual records.
- Memory for AI agents. Letting AI agents recall past conversations or notes beyond their context window.
Popular vector databases and tools
Here are well-known options, described by type rather than ranked. Features and pricing change often, so check each project’s docs.
| Tool | Type | Good to know |
|---|---|---|
| Pinecone | Managed cloud service | Fully hosted; no servers to run |
| Milvus | Open source (managed version via Zilliz) | Designed for very large collections |
| Weaviate | Open source and cloud | Built-in hybrid search |
| Qdrant | Open source and cloud | Written in Rust; strong filtering |
| Chroma | Open source | Popular for prototypes and local apps |
| pgvector | PostgreSQL extension | Keep vectors next to your existing data |
| FAISS | Library, not a database | Fast similarity search in your own code |
Do you actually need a vector database?
Not always. A simple rule of thumb:
- A few thousand documents: an in-memory library (FAISS) or even a plain array with cosine similarity may be fine.
- Already on PostgreSQL: try pgvector first, so you don’t run another system.
- Millions of vectors, many users, heavy filtering: a dedicated or managed vector database starts to pay off.
Also remember a vector database is only as good as your embeddings and chunking. Poorly split documents or a weak embedding model will return poor matches no matter how fast the index is. And retrieval doesn’t eliminate AI hallucinations; it reduces them by giving the model better source material.
Bottom line
So, what is a vector database? It’s the search engine for meaning: it stores embeddings and finds the closest matches in milliseconds, which is why it sits at the heart of RAG chatbots, semantic search and recommendations. Start simple with pgvector or FAISS, measure your retrieval quality, and move to a dedicated vector database when scale or filtering demands it.



