A vector database stores data as embeddings, which are lists of numbers that capture meaning, and finds the stored items closest to a query by comparing those numbers instead of matching keywords. That is what lets a support bot find the right help article when the customer's words differ from the article's, and it is the retrieval layer behind most RAG systems. You do not always need a separate product for it: a vector extension in the database you already run is often enough, and a small knowledge base may need no vector search at all.
What is a vector database?
It is a database built around one question: which stored items are most similar to this one? Each record holds a vector, the original content it came from, and metadata such as source, date or access rights. A query is turned into a vector the same way, and the database returns the nearest records, usually filtered by that metadata.
The products describe themselves in similar terms. Weaviate calls itself "an open-source, AI vector database". Pinecone describes Pinecone Database as "a search engine for AI agents and applications, built for semantic search, knowledge retrieval, and long-term memory at scale". Chroma lists the core jobs plainly: "store embeddings with metadata, search with dense and sparse vectors, filter by metadata, and retrieve across text, images, and more". Qdrant is offered as Qdrant Open-Source or Cloud. The differences between them are in hosting, scaling and features, not in the basic idea.
What are embeddings, in plain words?
An embedding is a numerical fingerprint of meaning. OpenAI's documentation puts it precisely: "An embedding is a vector (list) of floating point numbers. The distance between two vectors measures their relatedness. Small distances suggest high relatedness and large distances suggest low relatedness."
So "Can I send back shoes I have worn once?" and an article titled "Returns policy for used items" share almost no words, but an embedding model places them close together, while "shoe size guide" lands further away. That is the whole trick, and it works for images and other content as well as text.
A few practical facts are worth knowing:
- Size. By default, OpenAI's embeddings are 1536 numbers long for text-embedding-3-small or 3072 for text-embedding-3-large, and you can request fewer dimensions to save storage.
- Cost. As of October 2026, OpenAI's guide estimates about 62,500 pages per dollar for text-embedding-3-small and 9,615 for text-embedding-3-large, assuming roughly 800 tokens per page. Embedding a typical company knowledge base costs very little; storing and searching it is the larger cost.
- Consistency. Queries and documents must be embedded with the same model. Change the model and you re-embed everything, because vectors from different models are not comparable.
How does a vector database work?
The flow is the same whichever product you use:
- Chunk. Split documents into passages small enough to be specific, such as a section of a policy or one help article.
- Embed. Run each passage through an embedding model to get its vector.
- Store. Save the vector with the passage text and its metadata.
- Index. Build a structure that makes nearest neighbor search fast.
- Query. Embed the user's question, find the nearest vectors, apply metadata filters, and return the top results.
- Rerank (optional). Score the top results again with a more precise model before using them.
"Nearest" needs a definition of distance. pgvector, for example, supports L2 distance, inner product, cosine distance, L1 distance, Hamming distance, and Jaccard distance. For its own embeddings, OpenAI's guide says: "We recommend cosine similarity. The choice of distance function typically doesn’t matter much."
What is approximate nearest neighbor search?
Exact search compares the query with every stored vector. That is perfectly accurate and fine for small collections, but slow at millions of vectors. pgvector's documentation states the trade-off clearly: by default it performs exact nearest neighbor search, which provides perfect recall, and adding an index switches to approximate search, which trades some recall for speed. It adds a warning worth repeating: "Unlike typical indexes, you will see different results for queries after adding an approximate index."
An approximate index you will meet almost everywhere is HNSW: pgvector supports it, and Elasticsearch uses it by default for byte and bit vectors. It comes from a paper by Yu. A. Malkov and D. A. Yashunin first posted in 2016. It describes approximate K-nearest neighbor search based on navigable small world graphs with controllable hierarchy: a stack of graph layers where the top layers have few, long links and the bottom layer has every item. A search starts at the top, takes big jumps toward the right region, then drops down a layer at a time for finer steps, much like driving on highways before local roads. The authors report that this layered search allows a logarithmic complexity scaling.
HNSW is not free. pgvector notes that an HNSW index has better query performance than IVFFlat (in terms of speed-recall tradeoff), but has slower build times and uses more memory. IVFFlat instead divides vectors into lists, and then searches a subset of those lists that are closest to the query vector, building faster and using less memory at some cost in query performance.
Vector database, pgvector or search engine: which do you need?
The question "is X a vector database?" comes up constantly, because vector search now exists in several kinds of software.
| Option | Examples | What it is | Fits when |
|---|---|---|---|
| Dedicated vector database | Pinecone, Qdrant, Weaviate, Chroma | A database designed around vector search, managed or self-hosted | Vector search is the core workload, at large scale or with heavy filtering |
| Vector extension | pgvector for Postgres | Vector columns and indexes inside your existing relational database | You already run Postgres and want vectors next to your other data |
| Search engine with vector fields | Elasticsearch | A search engine whose dense_vector field is primarily used for k-nearest neighbor (kNN) search | You already run search and want keyword and vector results together |
| Similarity search library | Faiss | A library for similarity search and clustering of dense vectors, not a database | You are building your own system and handle storage yourself |
pgvector's own tagline makes the case for the second row: "Store your vectors with the rest of your data." One database means one backup, one permission model and one place where a deleted document is actually deleted. Move to a dedicated product when scale, latency or filtering needs outgrow what your existing database does comfortably, not before.
What is hybrid search, and why does it matter?
Embeddings are good at meaning and weak at exact strings. Anthropic's engineering team writes that "embedding models excel at capturing semantic relationships, they can miss crucial exact matches", and recommends adding BM25, a keyword ranking method it describes as particularly effective for queries that include unique identifiers or technical terms. A customer asking about error code E-4021 or order 778-1093 needs the keyword side.
Hybrid search runs both and merges the results. In Anthropic's tests, its Contextual Retrieval method, which combines contextual embeddings with contextual BM25, could reduce the number of failed retrievals by 49% and, when combined with reranking, by 67%. Several of the products above support keyword or sparse search alongside vectors; Chroma, for instance, searches with dense and sparse vectors.
How does a vector database fit into RAG?
It is the "retrieval" in retrieval-augmented generation. When a user asks a question, the system searches the index, puts the best passages into the prompt, and the model answers from them. Our guide to RAG vs fine-tuning covers when that approach beats retraining a model. The quality of the answer can never be better than the quality of what was retrieved, which is why chunking, hybrid search and reranking matter more than which database you pick.
Two places this shows up often. Support bots answer from a help center indexed this way, as described in our guide to customer support automation. And company search over contracts, manuals and past projects relies on documents that were first extracted and cleaned, which is the job of intelligent document processing.
For internal search, store access rights as metadata and filter on them in every query, so nobody retrieves a passage from a document they could not open directly. Search across your own documents, with permissions respected, is one of the internal tools we build for teams that have outgrown shared drives.
When do you not need a vector database?
More often than vendors suggest. Anthropic's advice is direct: "If your knowledge base is smaller than 200,000 tokens (about 500 pages of material), you can just include the entire knowledge base in the prompt that you give the model, with no need for RAG or similar methods." Prompt caching makes that cheaper when the same content is sent repeatedly.
You also do not need one when the lookup is exact. "What is the status of order 1093?" is a database query, not a similarity search. And if your collection is modest and you already run Postgres, exact search with pgvector and no index at all gives perfect recall with nothing new to operate.
Frequently asked questions
Is Faiss a vector database?
No.
Faiss describes itself as a library for efficient similarity search and clustering of dense vectors.
It gives you fast indexes in memory, but storage, updates, metadata filtering, access control and backups are yours to build.
Many vector databases use similar algorithms underneath.
Is Elasticsearch a vector database?
It is a search engine that can also do vector search.
Its dense_vector field type stores vectors and is primarily used for k-nearest neighbor (kNN) search.
If you already run Elasticsearch for keyword search, adding vectors there is usually simpler than introducing a separate database.
How much storage do embeddings need?
A single-precision float takes 4 bytes, so one 1,536-dimension vector is 6,144 bytes before index overhead, and a million of them is about 6 GB.
Indexes such as HNSW add memory on top.
Requesting fewer dimensions, or using the half-precision and binary vector types pgvector supports, reduces this.
Can a vector database search images as well as text?
Yes, as long as an embedding model turns the images into vectors.
Chroma, for example, says it can retrieve across text, images, and more.
Text and images can share one index only if they were embedded by a model designed to place both in the same space.