--- title: Vector Search: A Practical Guide for Developers | daily.dev description: Vector search maps data into high-dimensional embeddings so similarity becomes a nearest-neighbor problem. Index types trade accuracy for speed: FLAT gives... canonical: https://daily.dev/posts/vector-search-a-practical-guide-for-developers-wpvtprg29 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Vector Search: A Practical Guide for Developers | daily.dev og:description: Vector search maps data into high-dimensional embeddings so similarity becomes a nearest-neighbor problem. Index types trade accuracy for speed: FLAT gives... og:url: https://daily.dev/posts/vector-search-a-practical-guide-for-developers-wpvtprg29 og:image: https://api.daily.dev/og/posts/WPvtPrG29.png og:image:alt: Vector Search: A Practical Guide for Developers og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Vector Search: A Practical Guide for Developers **[Redis](https://daily.dev/sources/redislabs)** · 10 min read · 0 upvotes · 0 comments ## Summary 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. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does increasing the M parameter in an HNSW index affect recall and query latency? Increasing M, the number of neighbor links HNSW keeps per node, improves recall but raises memory use and latency. Recommended M values range roughly from 6 to 48, adding 48 to 384 bytes per object on top of the vectors themselves. On one dataset, pushing recall from 0.8 to 0.95 increased query latency by about 31%, illustrating the steep recall-latency trade-off at the top end. _Teams weighing recall against latency in HNSW tuning can track these operational trade-offs on daily.dev._ ### Why does adding a tight metadata filter reduce recall in an HNSW vector index? A tight metadata filter can sharply reduce recall because HNSW still walks its graph looking for near neighbors, but when most nodes fail the filter, the graph paths it would normally follow get cut off, causing it to skip past vectors that actually qualify. The tighter the filter, the more recall tends to drop, making results less relevant than expected. _Developers debugging filtered vector search recall issues can follow this failure mode discussion on daily.dev._ ### What happens if I query an HNSW vector index built with one embedding model using a different embedding model? Querying with a different embedding model than the one used to build the index produces effectively random results, because each model arranges vectors in its own distinct space and the two spaces do not align. There is no shortcut around this embedding drift; fixing it requires re-embedding every document with the new model, so tracking which model built each index from the start avoids a costly rebuild. _Anyone planning an embedding model swap can weigh this re-indexing cost using resources shared on daily.dev._ ## Similar posts on daily.dev - [Vector search database: news & 2026 guide](https://daily.dev/posts/vector-search-database-news-2026-guide-jn2fx26te) · Redis · 0 upvotes · 0 comments - [Vector Databases Explained in 3 Levels of Difficulty](https://daily.dev/posts/vector-databases-explained-in-3-levels-of-difficulty-pg3waxjnd) · Machine Learning Mastery · 4 upvotes · 0 comments - [Vector search in MySQL: an early look at HNSW and custom indexes in VillageSQL](https://daily.dev/posts/vector-search-in-mysql-an-early-look-at-hnsw-and-custom-indexes-in-villagesql-xzc5ovuqh) · Planet MySQL · 0 upvotes · 0 comments - [Scaling Vector Search with OpenSearch](https://daily.dev/posts/scaling-vector-search-with-opensearch-cu8mrge1x) · BigData Boutique blog · 5 upvotes · 1 comments - [Benchmarking vector indexes](https://daily.dev/posts/benchmarking-vector-indexes-hch39inje) · Percona Blog · 1 upvotes · 1 comments --- Tags: [#rag](https://daily.dev/tags/rag), [#redis](https://daily.dev/tags/redis), [#vector-search](https://daily.dev/tags/vector-search), [#embeddings](https://daily.dev/tags/embeddings) [View this post on daily.dev](https://daily.dev/posts/vector-search-a-practical-guide-for-developers-wpvtprg29) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Vector Search: A Practical Guide for Developers","url":"https://daily.dev/posts/vector-search-a-practical-guide-for-developers-wpvtprg29","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/vector-search-a-practical-guide-for-developers-wpvtprg29"},"datePublished":"2026-08-20T01:01:15.837Z","dateModified":"2026-09-13T18:56:28.932Z","description":"Vector search maps data into high-dimensional embeddings so similarity becomes a nearest-neighbor problem. Index types trade accuracy for speed: FLAT gives...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/33a89bf3fad7ed15775b896f90c6383a?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/33a89bf3fad7ed15775b896f90c6383a?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Redis","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Redis","logo":"https://media.daily.dev/image/upload/s--hr1KV229--/f_auto/v1729434313/logos/redis.png","url":"https://daily.dev/sources/redislabs"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/vector-search-a-practical-guide-for-developers-wpvtprg29","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"rag,redis,vector-search,embeddings","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Redis","item":"https://daily.dev/sources/redislabs"},{"@type":"ListItem","position":3,"name":"Vector Search: A Practical Guide for Developers"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/vector-search-a-practical-guide-for-developers-wpvtprg29#faq","mainEntity":[{"@type":"Question","name":"How does increasing the M parameter in an HNSW index affect recall and query latency?","acceptedAnswer":{"@type":"Answer","text":"Increasing M, the number of neighbor links HNSW keeps per node, improves recall but raises memory use and latency. Recommended M values range roughly from 6 to 48, adding 48 to 384 bytes per object on top of the vectors themselves. On one dataset, pushing recall from 0.8 to 0.95 increased query latency by about 31%, illustrating the steep recall-latency trade-off at the top end. Teams weighing recall against latency in HNSW tuning can track these operational trade-offs on daily.dev."}},{"@type":"Question","name":"Why does adding a tight metadata filter reduce recall in an HNSW vector index?","acceptedAnswer":{"@type":"Answer","text":"A tight metadata filter can sharply reduce recall because HNSW still walks its graph looking for near neighbors, but when most nodes fail the filter, the graph paths it would normally follow get cut off, causing it to skip past vectors that actually qualify. The tighter the filter, the more recall tends to drop, making results less relevant than expected. Developers debugging filtered vector search recall issues can follow this failure mode discussion on daily.dev."}},{"@type":"Question","name":"What happens if I query an HNSW vector index built with one embedding model using a different embedding model?","acceptedAnswer":{"@type":"Answer","text":"Querying with a different embedding model than the one used to build the index produces effectively random results, because each model arranges vectors in its own distinct space and the two spaces do not align. There is no shortcut around this embedding drift; fixing it requires re-embedding every document with the new model, so tracking which model built each index from the start avoids a costly rebuild. Anyone planning an embedding model swap can weigh this re-indexing cost using resources shared on daily.dev."}}]} ```