Vector search maps data into high-dimensional embeddings so similarity becomes a nearest-neighbor problem. Index types trade accuracy for speed: FLAT gives exact results via brute force, while HNSW graph-based indexes scale better but consume more memory, tunable via the M parameter. Distance metrics (cosine, Euclidean, dot product) produce identical rankings when vectors are normalized. Production use cases include RAG, hybrid search, semantic caching, recommendations, and agent memory. At scale, memory footprint, filtered recall degradation, and embedding drift from swapping models are common failure modes. Redis presents its own vector search stack (FLAT, HNSW, SVS-VAMANA indexes, FT.HYBRID score fusion, quantization) and benchmarks showing 90% precision at ~200ms median latency on a billion-vector test.
Table of contents
Vector embeddings & how they capture meaningIndex types: trading accuracy for speedBuild fast, accurate AI apps that scaleDistance metrics: cosine, Euclidean & dot productWhere vector search runs in productionSearch meaning, not just keywordsWhat breaks as datasets grow & how teams handle itHow Redis supports vector searchNow see how this runs in RedisVector search is infrastructure, not a featureQuestions this post answers
What causes recall to drop when filtering vector search results with HNSW?
HNSW's graph traversal relies on following paths between similar vectors, and when a metadata filter only matches a small fraction of documents, the paths leading to qualifying vectors get cut off because most nodes along the way fail the filter. This means the algorithm can skip past vectors that actually match the filter, so tighter filters tend to cause larger drops in recall. Teams tuning filtered vector queries can track patterns like this via daily.dev before they hit production surprises.
Why does swapping an embedding model break an existing vector search index?
Each embedding model arranges vectors in its own unique space, so an index built with one model and queried with a different model produces effectively random results because the two spaces don't align. There's no workaround other than re-embedding every document with the new model, so tracking which model built each index from the start avoids a painful rebuild later. Developers planning embedding model migrations can follow ecosystem guidance on daily.dev to avoid silent search regressions.
How much memory does an HNSW index add per vector compared to a FLAT index?
HNSW adds roughly 48 to 384 bytes per object on top of the raw vector storage, depending on the M parameter (the number of neighbor links kept per node, typically ranging from 6 to 48). A FLAT index, by contrast, stores only raw uncompressed vectors at about 4 bytes per dimension, so a 768-dimensional vector takes roughly 3 KB with no additional graph overhead. Engineers sizing vector database memory budgets can compare index trade-offs like this on daily.dev.