Key takeaways
- IVF searches the nearest clusters, while HNSW walks a layered neighbour graph for fast, high-recall search.
- No single algorithm wins; HNSW is the common default, with DiskANN and quantization for larger scale.
- Semantic search is the goal, and a vector database is one way to implement it.
- Keyword search misses synonyms and vector search misses exact codes, so hybrid search with reranking wins.
- pgvector, MongoDB Atlas and Databricks all add vector indexes beside your existing data.
Vector search finds items whose embeddings are closest to a query embedding, letting applications search by meaning rather than exact words. It powers semantic search, recommendations and retrieval for LLM apps. RAG.NextUpgrad combines dense vector search with BM25 keyword search using reciprocal rank fusion, and FaceVision stores face embeddings, never images, in PostgreSQL, so this page covers IVF and HNSW, current algorithms, semantic search, full-text and keyword comparisons, PostgreSQL, MongoDB, Databricks and troubleshooting.
How does vector search actually work with IVF and HNSW?
Exact search compares the query with every vector, which is too slow at scale, so approximate nearest neighbour indexes trade a little accuracy for speed. IVF partitions vectors into clusters, while HNSW builds a layered graph of neighbours.
Also asked as: how vector search actually works: ivf and hnsw
IVF, the inverted file index, runs k-means to create clusters and assigns each vector to its nearest centroid. At query time it searches only the closest few clusters, controlled by a parameter often called nprobe, and it can be combined with product quantization to compress vectors. HNSW, from Malkov and Yashunin, links each vector to nearby vectors across several layers; searches start at a sparse top layer and greedily descend toward the closest neighbours. HNSW usually gives higher recall at low latency but uses more memory, while IVF builds faster and compresses better.
Which algorithm is the current state of the art for vector search?
There is no single winner. Graph-based methods such as HNSW are the common default for in-memory search, DiskANN-style graphs handle billion-scale data on SSDs, and quantization methods, such as product and binary quantization, cut memory.
Google's ScaNN uses anisotropic quantization for strong speed and recall trade-offs, and GPU libraries such as NVIDIA's CAGRA accelerate graph search for very large workloads. Benchmarks such as ANN-Benchmarks compare recall against queries per second across libraries and datasets, and rankings shift with data size, dimensions and hardware. For most applications under tens of millions of vectors, HNSW in a mature database works well. Choose based on your scale, memory budget, update frequency and filtering needs, and measure recall on your own data rather than trusting headline numbers.
What is semantic search in a vector database?
Semantic search in a vector database converts documents and queries into embeddings with the same model, stores the document vectors, and returns the nearest vectors to the query, so results match meaning even when words differ.
Also asked as: what is semantic search in vector database
For example, a query about resetting a password can find a passage titled recovering account access. The pipeline involves chunking documents, embedding chunks, indexing them with metadata, embedding each query, retrieving top matches, and often reranking them with a cross-encoder for precision. Filters on metadata, such as date, language or permissions, narrow results. Quality depends mostly on the embedding model and chunking, not the database. For LLM applications, retrieved chunks are then passed to the model as context, which is the core of retrieval-augmented generation.
Is semantic search the same as querying a vector database?
Not quite. Semantic search is the goal of finding results by meaning; querying a vector database is one common way to implement it. A complete semantic search system also needs an embedding model, chunking, ranking and evaluation.
Vector databases store any embeddings, including image, audio and recommendation vectors, so not every vector query is semantic text search. Conversely, semantic search can run without a dedicated vector database, using libraries such as Faiss, extensions such as pgvector, or search engines with vector support. Good semantic search often combines vector similarity with keyword matching and rerankers, since vectors alone miss exact terms. Think of the vector database as storage and retrieval infrastructure, and semantic search as the end-to-end experience you design around it.
What is the difference between a vector database and full-text search?
Full-text search uses an inverted index of words and ranks documents with formulas such as BM25, matching exact terms and their variants. A vector database indexes embeddings and ranks by similarity of meaning using approximate nearest neighbour search.
Also asked as: what's the difference between a vector database and full-text search
Full-text search excels at exact names, codes, phrases and Boolean queries, is explainable, and needs no model. Vector search excels at paraphrases, synonyms, natural-language questions and cross-language matching, but depends on embedding quality and can return confidently irrelevant results. The line has blurred: Elasticsearch, OpenSearch, PostgreSQL and many vector databases now support both. Most production systems use hybrid search, running both and fusing results with methods such as reciprocal rank fusion, as RAG.NextUpgrad does before reranking.
Where do keyword search and vector search each fail?
Keyword search fails when users and documents use different words, such as synonyms, paraphrases or other languages. Vector search fails on exact identifiers, product codes, rare names, numbers and negations, where similar-looking meaning is not enough.
Also asked as: where keyword search and vector search each fail
A query for car insurance claim may miss a document about vehicle policy reimbursement with keyword search alone. A query for error code E1047 may return documents about other errors with vector search, because embeddings blur exact tokens. Vector search also struggles with very short queries, domain jargon outside the embedding model's training, and constraints such as dates or numeric ranges. Hybrid search covers both weaknesses, and a reranker then orders the combined candidates by true relevance. Evaluate both failure types with real queries from your users.
How do you create a vector database in PostgreSQL?
Install the pgvector extension, run CREATE EXTENSION vector, add a column of type vector with your embedding dimensions, insert embeddings from your model, and query nearest neighbours by ordering on a distance operator such as cosine distance.
Also asked as: how to create vector database in postgresql
For speed at scale, create an HNSW or IVFFlat index on the vector column with the operator class matching your distance metric, such as vector_cosine_ops. Combine vector similarity with normal SQL filters and joins, which is a major advantage over separate vector stores. PostgreSQL's built-in full-text search can sit alongside it for hybrid retrieval. Managed services such as Supabase, Neon and most cloud PostgreSQL offerings support pgvector. FaceVision keeps face embeddings, never images, in PostgreSQL, which keeps identity data and application data in one familiar database.
How do you create a vector search index in MongoDB?
In MongoDB Atlas, store embeddings in a document field, then create a Vector Search index specifying the field path, number of dimensions and similarity function, such as cosine, euclidean or dot product, through the Atlas UI, CLI or drivers.
Also asked as: how to create vector search index in mongodb
Query with the $vectorSearch aggregation stage, passing the index name, field path, query vector, the number of candidates to consider and the limit of results. Add filter fields to the index definition if you want to pre-filter by metadata such as category or tenant. Larger candidate numbers improve recall at some latency cost. Vector search runs alongside regular MongoDB queries, so you can combine it with lookups and projections. Generate embeddings with any model, or use the Voyage AI embedding models that MongoDB now offers.
How do you create a vector search index in Databricks?
Create a vector search endpoint in Mosaic AI Vector Search, then create an index on a Delta table, either a Delta Sync index that updates automatically from the table or a Direct Vector Access index you write to through the API.
Also asked as: how to create vector search index in databricks
For a Delta Sync index, enable Change Data Feed on the source table, choose a primary key, and either let Databricks compute embeddings from a text column using a model serving endpoint or supply your own embedding column. You can create indexes in Catalog Explorer or with the Python SDK. Query with similarity search, passing query text or a vector, the columns to return and the number of results, optionally with filters or hybrid keyword matching. Indexes are governed through Unity Catalog, which keeps permissions consistent with your data.
How do you troubleshoot vector search in an AI application?
Start by inspecting what is retrieved for failing queries. Most problems come from mismatched embedding models, wrong distance metrics, poor chunking, overly strict filters, stale indexes or approximate index settings that sacrifice too much recall.
Also asked as: how to troubleshoot vector search in an ai application
Confirm queries and documents use the same embedding model, version and any required prefixes, and that normalisation matches the metric. Compare approximate results with exact search on a sample to measure recall, and raise parameters such as efSearch or nprobe if needed. Check that new documents were indexed and that filters are not excluding answers. Review chunk sizes, since chunks that are too large dilute meaning and too small lose context. Build a labelled test set and track recall at k. Add hybrid search and a reranker when exact terms keep failing.
Sources
GenAI engineer and AI product builder with 2+ years shipping production-grade AI systems: RAG pipelines, fine-tuned LLMs, hybrid retrieval and multi-modal apps across vision, speech and OCR, architected end to end from ingestion to deployment. Leads engineering for SCULT INDIA's 14-member team, founded the 500+ member TechVerse Enclave community and has mentored 200+ students. Three hackathon first prizes: Changethon 2025 (IIT Roorkee), Product Genesis at Vividhotsava 2025 (CSJMU) and BYTEBATTLE (MeetKats).
Open to GenAI roles, hackathon judging, mentorship sessions and guest talks at colleges. For campus sessions the inviting institution covers the visit end to end: travel (a First AC train ticket for journeys up to five hours, a flight for anything longer), accommodation, meals, and pickup and drop; the honorarium and workshop fees are negotiable on WhatsApp or on the call, and requests are welcome from institutions that can cover the visit this way. Email pranjulrathour41@gmail.com.
