Keyword vs vector search: FTS, grep, Elasticsearch, algorithms, models, DBs, SPLADE

Keyword search matches the exact words in a query, while vector search matches meaning using embeddings, so each finds results the other misses. Production systems often combine both. In RAG.NextUpgrad I use hybrid retrieval, dense vectors plus BM25 merged with reciprocal rank fusion and then reranked, so this page compares keyword, full-text, grep and Elasticsearch with vector search, then covers examples, algorithms, models, databases, SPLADE and a short tutorial.

Keyword vs vector search: what is the difference?

Keyword search ranks documents by matching query terms, usually with BM25 over an inverted index. Vector search converts text into embeddings and finds documents whose vectors are closest in meaning, even without shared words.

Keyword search excels at exact names, codes, error messages and rare terms, and it is fast, cheap and explainable. Vector search handles synonyms, paraphrases and natural language questions, such as matching car repair to automobile maintenance, but it can miss exact identifiers and is harder to debug. Hybrid search runs both and merges results, often with reciprocal rank fusion, then a reranker orders the final list. That combination is the pattern I use in RAG.NextUpgrad, because real users mix exact terms with vague questions.

FTS vs vector search: which should you use?

Full-text search, such as PostgreSQL's tsvector or SQLite FTS5, is keyword search built into a database, with stemming, stop words and ranking. Use it for exact terms, and use vector search for meaning-based queries.

Many teams run both in the same database: PostgreSQL with full-text search and pgvector lets you combine scores in one SQL query, avoiding a separate search service. Full-text search needs no embedding model, updates instantly and costs little, while vector search requires embedding every document and query. For product search, documentation and RAG, a hybrid of the two usually gives the best relevance. Start with full-text search if queries are mostly keywords, and add vectors when users ask natural language questions.

Grep vs vector search: when does each work?

Grep finds exact text patterns, including regular expressions, by scanning files line by line. It has no ranking or understanding of meaning. Vector search ranks results by semantic similarity but cannot guarantee exact matches.

Grep suits code, logs and configuration, where you know the identifier or error string, and it needs no index. Coding agents rely heavily on grep-style search because code has precise names that agents can guess and refine. Vector search suits natural language documents where wording varies. For large codebases, combine both: grep or symbol search for identifiers, and embeddings for questions such as where authentication is handled. Grep slows on huge corpora, while indexed search scales better.

Elasticsearch vs vector search: are they different?

Elasticsearch began as a keyword search engine built on Lucene and BM25, but it now supports vector search too, with dense vector fields, approximate kNN using HNSW and hybrid queries combining both.

So the real comparison is Elasticsearch, or OpenSearch, versus dedicated vector databases such as Qdrant, Milvus or Pinecone. Elasticsearch is strong when you need mature keyword search, filtering, aggregations and analytics alongside vectors in one system. Dedicated vector databases can be simpler to operate for pure vector workloads and may offer more vector-specific features. Teams already running Elasticsearch often add vectors there rather than introducing a new database. Benchmark on your data and query patterns before choosing.

What are examples of vector search?

Common examples include semantic document search, retrieval for RAG chatbots, product recommendations, image search with models such as CLIP, near-duplicate detection, code search, and matching support tickets to known solutions.

In RAG, vector search retrieves passages relevant to a question so the model answers from evidence. E-commerce sites find similar products from text or images. Music and video platforms recommend content from embedding similarity. Fraud and anomaly detection compare behaviour vectors. Face recognition compares face embeddings, as FaceVision does in the browser, storing embeddings rather than images. Each example follows the same pattern: convert items to vectors with a suitable model, index them, then search by similarity.

What is the best vector search algorithm?

HNSW, a graph-based approximate nearest neighbour algorithm, is the most widely used default, offering high recall and fast queries. Other strong options include IVF with product quantization for memory efficiency and DiskANN for huge datasets on SSDs.

For small collections, up to perhaps tens of thousands of vectors, exact brute-force search is simple and accurate. HNSW trades memory for speed and suits most production workloads. IVF partitions vectors into clusters and searches only the nearest ones, and quantization compresses vectors to cut memory at some recall cost. Libraries such as FAISS implement many of these. Tune parameters such as ef_search in HNSW, measuring recall against exact search and latency on your data.

What is the best model for vector search?

There is no single best model. Strong embedding options include OpenAI's text-embedding-3 models, Cohere Embed, Voyage AI, and open models such as BGE-M3, E5, Nomic Embed and Qwen3 Embedding. The MTEB leaderboard compares them across tasks.

Choose by language coverage, domain, context length, dimension size, licence and whether you need self-hosting. Multilingual models matter for Indian languages and mixed-language text. Smaller dimensions reduce storage and speed up search, and some models support shortening embeddings with little loss. Benchmarks rarely match your data, so build a small evaluation set of real queries with known relevant documents and measure recall for a few candidates. Use the same model for documents and queries.

What are the top vector search databases?

Popular choices include pgvector for PostgreSQL, Qdrant, Weaviate, Milvus, Pinecone, Chroma and LanceDB, plus vector features in Elasticsearch, OpenSearch, Redis and MongoDB Atlas.

Also asked as: top vector search dbs

Pick based on scale and operations. pgvector suits teams already on PostgreSQL who want vectors beside relational data. Qdrant and Weaviate offer strong filtering and hybrid search, Milvus targets very large deployments, and Pinecone is fully managed. Chroma and LanceDB work well for local development and smaller apps. Check filtering performance, hybrid search support, backups, multi-tenancy and hosting options. For most projects, the database matters less than chunking, embedding choice and retrieval design, so do not over-optimise this decision early.

What is SPLADE for sparse vector search?

SPLADE is a learned sparse retrieval model. It uses a BERT-style model to assign weights to vocabulary terms for each document and query, including related terms not present in the text, producing sparse vectors searchable with an inverted index.

Also asked as: splade for sparse vector search explained

This combines the precision and efficiency of keyword search with some semantic understanding: a document about automobiles can receive weight for car even if it never uses that word. Because the vectors are sparse, they work with inverted indexes, and results are more interpretable than dense embeddings. SPLADE often performs strongly on retrieval benchmarks and pairs well with dense vectors in hybrid systems. Several vector databases support sparse vectors natively, making SPLADE practical in production.

What does a basic vector search tutorial look like?

Split documents into chunks, embed each chunk with an embedding model, store the vectors with their text in an index, embed the user's query with the same model, and return the nearest chunks by cosine similarity.

A minimal Python version uses sentence-transformers for embeddings and FAISS or Chroma as the index, in under fifty lines of code. Next steps improve quality: add metadata filters, hybrid search with BM25, reciprocal rank fusion and a reranker. Evaluate with real questions, measuring whether the right chunk appears in the top results. Then add an LLM that answers from retrieved chunks with citations, and you have the core of a RAG system like RAG.NextUpgrad.

Pranjul Rathour

GenAI Engineer · India

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.

PortfolioInvite me to your campusHire meLinkedInGitHubXInstagramThreadsFacebookBlueskyDev.toBloggerHashnodeSCULTEmail