# So, do you still need Vector DB in 2027? I often get pulled into discussions on whether we should move to Vector DB or move out of it altogether and let the Agent figure it out automagically? Moving out sounds attractive on paper as Vector databases add infrastructure overhead, require embedding pipelines that stale over time, and introduce compute costs on every query. Why pay for vector DBs when LLMs offer million token context windows, or when autonomous agents can run local search utilities like `grep`? I like to answer this question by saying "It depends on your usecase". ## Where Keyword & Agentic Search Collapses If a user asks how to handle a password reset issue, but the internal doc was renamed from `how to reset password` to `how to update credentials`, a `grep` command returns nothing. An AI agent running that loop will naturally conclude the information does not exist, causing it to hallucinate a resolution or would lead to no results. A vector database maps inputs by **semantic similarity** in a high-dimensional vector space rather than exact character matching, completely closing this semantic gap. ![](https://cdn.hashnode.com/uploads/covers/64e9d89567deab13f465f320/9e8b17a7-20ae-422a-a596-4757dff3eaa9.png align="center") --- ## How to decide? Instead of treating vector databases as an all-or-nothing requirement, its prudent to evaluate your needs against a decision ladder. **Tier 1: Small Data / Few Documents**\ Load your raw text directly into the prompt context. Fast, simple, zero extra infrastructure. > There is no retrieval cost in this tier. > > But remember, the moment your context becomes big, the quality of the results might drop. **Tier 2: Deterministic & Keyword Search**\ Use **Keyword Search (**`grep`**, BM25)** for quick, literal pattern matching where exact terms are guaranteed. > Pro tip: An autonomous agent could generate synonyms and run a loop until it finds results but this could result to context rot and poor quality results. **Tier 3: Moderate Scale (< 10 Million Vectors)**\ Use **In-Database Vector Extensions** (e.g., PostgreSQL with `pgvector`). Embedding is after all extra column of numbers next to the row it describes and indexing columns is what databases do. Utilizing this, you can keep data in a single location with hybrid keyword and vector query support. This works great but need benchmark based on your exact load. There are often Hard ceilings on the number of embedding dimensions that can be indexed, along with latency degradation as and when the number of embeddings increase, you need to effectively test it against your expected query patterns. Things to look out for - Do you really need a vector index? or just a flat index works for your embeddings. This way you will have full recall. Remember that HNSW is an approximate algo, so vector indexes are approximate and can lead to low recall. > Normally folks have a mental model that indexes are supposed to be exact, so it could lead to suprises, when they are told that vector indexes are approximate and could have low recall. - Combining filters (WHERE clause) with vector indexes are tricky. Pre-filtering (filter then search), Post-filtering (search then filter) are some of the common approaches.\\ **Tier 4: Enterprise Scale (> 10 Million Vectors)**\ Scale up to a **Dedicated Vector Database** (e.g., Pinecone, Milvus, Qdrant) designed specifically to handle high concurrency, low latency, and massive embedding indexes. ![](https://cdn.hashnode.com/uploads/covers/64e9d89567deab13f465f320/484d1867-73ba-4eaa-9107-45e60fad584b.png align="center") --- Thank you for reading this article. Hope you learnt something new today🙏 ![](https://cdn.hashnode.com/uploads/covers/64e9d89567deab13f465f320/574e8e7f-7590-4b8d-8919-bafc21e17cac.png align="center") ## Appendix - -