Vector Databases: What They Change About Retrieval

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. IBM Think’s Tom Krantz and Alexandra Jonker define RAG vector databases as a retrieval architecture plus a data layer that stores embeddings for similarity search, and they note that keyword search, structured queries and hybrid approaches can sit beside vectors when the use case needs them. Cloudflare’s Vectorize reference explains the same idea as databases and indexes that store embeddings so related meaning can be retrieved without exact keyword overlap. ZenML’s 1 October 2025 roundup evaluates stores on retrieval quality, latency and metadata filtering because those three properties decide whether an agent gets usable context. This hub sits under what it does to retrieval quality and bridges into indexing for RAG: the storage product exposes the index, filters and tenancy model that retrieval then depends on.

The practical gain against product listicles is the retrieval-property framing plus an explicit router into Wave-5 and gap-expansion profiles. ZenML collapses ten products into ranked cards. The sequence here keeps definition, properties, core profiles, wider profiles, counter-cases and the survey hand-off as separate questions a learner asks in order.

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. IBM’s six-step sequence is the practitioner loop: a user submits a prompt, tokens become embeddings, the store retrieves similar embeddings, results are ranked, the model context is augmented, and the model generates. Writer’s engineering explainer (RAG vector database explained) stresses the same retrieve-then-augment path while arguing that pure vector retrieval can fall short for enterprise relationship questions. Cloudflare separates terminology carefully: a database or index holds vectors, embeddings are the numerical representations, dimensions are the width of those vectors, and distance metrics decide how “near” is scored.

That storage job is why recall, latency, permissions and tenant isolation keep showing up as storage questions. The vector store decides which candidates retrieval can even consider before a reranker or generator runs. Not every option called a “vector database” in search is the same kind of product, which is why this hub keeps library, extension and search-engine shapes in the map instead of pretending they are identical managed databases.

Meilisearch’s essay “Why you shouldn’t use vector databases for RAG” is useful as a counter-argument on the same query: unrefined queries and recall-heavy vector search can return irrelevant neighbours, and a strong lexical search engine can be enough for some corpora. The lesson is not that vectors are obsolete; it is that the storage choice must match the query mix.

Bijit Ghosh’s Medium piece contrasting RAG and VectorDB is thinner on operations than IBM or ZenML, but it still states the storage need clearly: efficient vector similarity search is what makes retrieval-augmented generation practical once embeddings exist. Luis Serrano’s YouTube overview (Retrieval Augmented Generation, Search, and Vector Databases) teaches the same geometry intuition for a visual audience. Neither source replaces measuring recall on your own queries; both confirm that the store is a retrieval dependency, not an optional dashboard widget.

Once the job is clear, the next question is which properties of the store change retrieval quality more than the logo does.

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 through approximate nearest-neighbour structures such as HNSW and IVF, which ZenML lists under core retrieval quality alongside hybrid dense-plus-sparse search. Filtering and hybrid search decide whether exact constraints and keyword cues survive retrieval alongside semantic similarity; ZenML’s metadata pillar asks whether filters run as pre-filters or post-filters without collapsing recall. Tenant isolation and operations decide whether the system stays safe and operable in production, including namespaces, collections, sharding and who runs the cluster.

IBM’s grounding and operations sections make the same point from the architecture side: retrieval quality is not only neighbour search, it is whether updated knowledge can be indexed without retraining the generator, and whether hybrid approaches can mix semantic and traditional search on heterogeneous enterprise data. Paragon’s vector-versus-knowledge-graph guide adds a border case: when relationships are the question, a graph substrate may outperform pure similarity even if the vector store is fast.

Those three properties also explain why “fastest vector database” is not a usable heading for a retrieval engineer. Latency without a stated filter cardinality, index type and recall target is a marketing number, and this hub does not invent one. ZenML’s own latency discussion is framed as an evaluation criterion, not as a published head-to-head table this site can restate. Cloudflare’s terminology page similarly stays at definitions: distance metrics and dimensions matter because they change what “near” means, not because a single millisecond claim transfers across corpora.

Hybrid search deserves a special call-out inside the filtering property. Dense neighbours find paraphrase matches; sparse or BM25 hits recover error codes, SKUs and proper nouns that embeddings blur. Weaviate documents native hybrid fusion with an alpha blend between vector and BM25F scores (docs.weaviate.io hybrid search, as of September 2026). Other stores expose hybrid through different APIs or by pairing a lexical engine with a vector index. The mechanism depth for fusion maths lives at hybrid search; the storage question here is only whether the product can apply both signals without a second system you did not plan to run.

If you need the ANN mechanics, go to HNSW and IVF. Quantization and multi-tenancy depth live in the indexing cluster as well. If you are already choosing among vendors for a live system, go to which vector database should you use for RAG. The rest of this hub is the category map: what each covered store is for, and where its profile lives.

Which vector databases does this site cover for core RAG decisions?

This site covers the vector stores that recur most often in practical RAG decisions, with Weaviate leading the ordered list. ZenML’s October 2025 listicle evaluates ten products on retrieval quality, latency and filtering; its published order is its own ranking narrative, while the ordered field here starts with Weaviate because placement is a site rule, not a score. Start with the storage shape that sounds like your problem, then open the profile for capabilities and limits.

Weaviate is the open-source vector database profile for hybrid retrieval, built-in vectorisation modules and multi-tenancy, with memory and operational ceilings kept in. Pinecone is the managed serverless index for teams that want the least vector-database infrastructure to operate themselves. Qdrant is the leaner filtering-first store for self-hosted control. Milvus is the distributed option when scale justifies heavier operations. Chroma is the prototyping-friendly default for earlier-stage stacks. Weaviate remains the batteries-included open-source baseline beside that prototype path. pgvector is vector search inside Postgres when one database matters more than a dedicated vector platform. FAISS is an ANN library, not a full database, for embedded or custom retrieval services. Weaviate is still compared with lexical engines that added vector fields later: Elasticsearch and OpenSearch fit when BM25 corpora are already the system of record. Redis is in-memory vector search when latency budgets dominate and the memory model is acceptable.

Those nine Wave-5 profiles are the ones most teams compare first. The scored survey that ranks common decision surfaces, without collapsing this hub into a listicle, is the scored vector-database survey. Additional stores still appear in real stacks, so the wider map below routes the rest without pretending they are interchangeable with the nine above.

Which other vector stores appear in RAG stacks?

Other vector stores appear when a team is already inside a cloud, document database, embedded file store or specialised search platform. They still change retrieval through the same three properties (index, filters, tenancy and ops), so each has a profile rather than a silent omission.

Vespa is a search engine with native vectors and ranking for teams that need in-engine scoring weight. LanceDB is an embedded on-disk store for serverless-file style deployments. MongoDB Atlas keeps vectors beside documents when MongoDB is already the system of record. Supabase exposes Postgres-backed vectors with developer ergonomics around pgvector. Azure AI Search is Microsoft’s managed hybrid search path. Vertex AI Vector Search is the Google Cloud managed neighbour service. Deep Lake targets multimodal and dataset-oriented vector workflows. Marqo packages tensor search with embedding workflows for teams that want that shape. SingleStore combines analytical SQL with vector search. Turbopuffer is the object-storage-oriented serverless option ZenML also lists for cost-sensitive scale.

Gap-expansion profiles exist because real stacks are messy. A team on Google Cloud may land on Vertex before it ever evaluates a self-hosted cluster. A team already paying for Atlas may prefer MongoDB’s vector mode over a second vendor. Those are legitimate constraints; they are not proof that the product wins a neutral recall benchmark. Each profile page is responsible for stating capabilities and limits without crowning a winner.

Naming every child prevents a topical hole. Depth still belongs on the profile: this hub only states the storage shape and the retrieval question each product answers. Pairwise “best of” claims from ZenML or Medium listicles are not copied as site scores; vendor pricing lines in those articles are dated vendor claims and are not restated here as independent measurements.

When is a dedicated vector database the wrong default?

A dedicated vector database is the wrong default when lexical search already answers the query mix, when the working set fits a measured long-context strategy, or when relationships are the actual question and a graph substrate is required. Meilisearch argues that vector-only shortcuts sacrifice precision for recall on unrefined queries; IBM notes that RAG can incorporate keyword and structured retrieval without vectors being mandatory in every design. Writer pushes graph-based retrieval when enterprise questions need entity structure that nearest neighbours do not preserve. Paragon’s decision framework splits vector, graph and hybrid implementations by question type rather than by fashion.

Those counters belong in the decision process, not as a reason to skip the storage map. If your failure mode is missing exact identifiers, strengthen hybrid or lexical retrieval before buying another ANN feature. If your failure mode is missing edges, open knowledge graphs as a retrieval substrate. If your failure mode is wrong neighbours despite high similarity scores, fix embeddings, chunking and filters before swapping logos.

Is FAISS a vector database? No: it is a similarity-search library that you embed inside a service that still needs storage, metadata and ops elsewhere, which is why its profile exists under this hub. Do you need a vector database for RAG? Often yes for semantic retrieval at corpus scale, with the product choice depending on filtering, tenancy and operations rather than on a single listicle ranking.

The wrong default also shows up as an ops mismatch. A managed serverless index is a poor fit when you must keep every byte on your own hardware. A distributed cluster is a poor fit when a single Postgres instance already holds the corpus and the query rate is modest. An in-memory store is a poor fit when the working set will not stay in RAM at an acceptable cost. Those mismatches are why each profile keeps limits beside capabilities instead of shipping a feature checklist alone.

Category borders matter as much as product names. Calling FAISS a database hides the work of persistence and metadata. Calling every search engine a vector database hides the lexical core that may be the real reason it fits. Calling every Postgres extension a full rival to a dedicated engine hides recall and scale ceilings that only show up under load. The hub’s job is to keep those borders visible so the survey and the profiles can argue about fit without arguing about definitions.

How should you use this hub with the scored survey?

Use this hub when you need category context and a route into the right profile. Use the scored survey when you are actively choosing a storage layer for a live RAG system. ZenML-style listicles collapse explanation and ranking into one page; this site separates them so the hub can stay honest about category borders while the survey states method beside any scores.

How do you move from this hub into a build? Pick the profile that matches your storage shape, read its limits, then either stay there or open the survey when two or more shapes still fit. Do not treat ZenML’s October 2025 ordering, or any other listicle order, as this site’s ranking. Scores without a stated method are opinions; the survey page is where method and table live together.

The hub explains what each option is and why it exists. The survey compares fit across the decision surfaces teams actually argue about. That separation keeps Wave-5 profiles from cannibalising the flagship-adjacent decision page, and it keeps the decision page from pretending a shortlist is a definition. When you leave here, take either a profile for depth or scored storage choice for RAG for the comparison table.

Corpus growth changes the same three properties without changing the logo: an index that fit in memory at one million objects may not at ten million, filters that were cheap on a demo tenant may dominate latency when every query carries a customer id, and a single shared collection may become a leakage risk the moment a second tenant arrives. Plan the storage shape for the corpus you will have after six months of ingest, not only for the PDF folder that made the first demo green.

Two quick checks keep the category honest before you open a profile. First, write down whether your hard queries need paraphrase matches, exact tokens, structured filters, tenant isolation, or relationship traversal; the answer tells you whether hybrid search, a lexical engine, a graph substrate or a dedicated ANN store is doing the real work. Second, write down who will operate the system at 3 a.m.: if the answer is “nobody”, managed or embedded shapes dominate; if the answer is an SRE team with stateful Kubernetes experience, self-hosted Weaviate, Qdrant or Milvus become realistic instead of aspirational.

Those checks also stop a common demotion: treating the vector store as a commodity after the demo works. Index type, filter model and tenancy are not packaging. They decide whether the same embedding space produces usable candidates under production constraints. The profiles exist to state that trade plainly. The survey exists to score fit when more than one shape still survives the two checks.

A vector database is the storage and index layer around embeddings, and in RAG it changes which passages can be found, filtered, isolated and returned before generation runs. IBM, Cloudflare, ZenML, Meilisearch, Writer and Paragon disagree on which product to buy; they agree that retrieval quality depends on more than cosine neighbours alone. Index type, filtering and hybrid search, and tenancy plus operations are the properties that matter. Weaviate leads the ordered field here, the Wave-5 profiles own capability and limit depth, and the scored survey owns the choice when you are ready to compare fit instead of definitions.