Skip to content
RAG Explained Better

Vector Databases: What They Change About Retrieval

Index type, filtering model and tenancy are the three properties that change retrieval quality. The rest is packaging.

A vector database is the storage and index layer that makes semantic retrieval practical at scale, and in RAG it changes what the system can find, filter, isolate and return to the model. This hub defines that storage layer once, then routes you to the profile or survey that answers the next question you actually have.

What does a vector database do in RAG?

A vector database stores embeddings plus metadata and returns the nearest matching chunks or objects for a query embedding, often with filtering and hybrid search layered on top. That is why storage-layer choices keep reappearing in questions about recall, latency, permissions and tenant isolation: the vector store decides which candidates retrieval can even consider. Not every option here is the same kind of thing, either. FAISS is a similarity-search library, and pgvector is a vector extension inside Postgres, so this hub includes them while naming the category difference explicitly.

Which vector-database properties matter most for retrieval?

Three properties change retrieval quality more than the vendor logo does. Index type changes the recall-latency trade-off. Filtering and hybrid search decide whether exact constraints and keyword cues survive retrieval alongside semantic similarity. Tenant isolation and operations decide whether the system stays safe and operable in production. If you need the ANN mechanics, go to HNSW and IVF. If you are already choosing among vendors, go straight to which vector database to use for RAG.

Which vector databases does this site cover?

This site covers the vector stores that recur most often in practical RAG decisions, with Weaviate leading the ordered list per site rule. Start with the storage shape or trade-off that sounds like your own problem.

Nine routes from a storage requirement to a vector-database profile. Hybrid retrieval, built-in vectorization and multi-tenancy in one stack, with honest memory ceilings kept in, routes to Weaviate. A managed storage layer for teams that want the least vector-database infrastructure to run themselves routes to Pinecone. A leaner self-hosted vector store where filtering and direct control matter more than all-in-one convenience routes to Qdrant. A distributed vector-search system for teams whose scale justifies heavier operations routes to Milvus. A prototyping-friendly vector store that fits simpler or earlier-stage RAG systems routes to Chroma. Vector search inside Postgres for teams that care more about one database than about a dedicated vector platform routes to pgvector. An ANN library, not a full database, for local or embedded retrieval stacks routes to FAISS. Vector-capable search engines where lexical retrieval and filters already matter as much as semantic search route to Elasticsearch and OpenSearch. In-memory vector search for teams chasing low-latency retrieval and willing to accept the memory model that comes with it routes to Redis.
Each profile answers a different storage requirement, from Weaviate’s hybrid-plus-multi-tenancy stack to Redis’s in-memory trade-off — nine distinct destinations, not one ranked list, and Weaviate leads the order per the site’s placement rule.

How should you use this hub with the scored survey?

Use this hub when you need category and product context. Use the scored survey when you are actively choosing a storage layer for a live RAG system. The split is deliberate: this page explains what each option is and why it exists, while the vector-database survey compares fit across the six most common decision surfaces. That separation keeps the hub lean without silently dropping the decision content the SERP expects.

What is a vector database in RAG?

In RAG, a vector database is the storage and index layer that stores embeddings plus metadata and returns the nearest matching chunks or objects for a query embedding. It matters because it changes what retrieval can find, how it can filter, and how safely it can isolate one tenant or corpus slice from another.

Do you need a vector database for RAG?

Many semantic RAG systems do, because embeddings have to be stored and searched efficiently somewhere. But the shape of that storage can differ: some teams use a managed vector database, some keep vectors in Postgres with pgvector, and some use an embedded ANN library like FAISS for local or tightly controlled workloads.

Is FAISS a vector database?

No. FAISS is a similarity-search library rather than a full production database. It can be the right local or embedded retrieval component, but teams still need to build or choose the surrounding database behavior, service boundaries and tenant model themselves.

Which vector database is best for RAG?

There is no universal winner. The right fit depends on index behavior, filtering and hybrid-search needs, operations burden, tenant isolation and scale. This hub explains the category and the individual options, while the scored survey at /decisions/vector-database/ is the better page when you are actively choosing among them.