Under what circumstances would a team be justified in NOT using a vector database at all, and instead using brute-force search or a traditional search engine?

Question

Accepted Answer

There are three scenarios where a vector database may not be justified. First, small scale: if the dataset is small (thousands to tens of thousands of vectors), a brute-force search over an in-memory array is fast enough and simpler than any database. A linear scan over 10k vectors of 768 dimensions takes a few milliseconds in numpy, which is acceptable for many applications. Adding a vector database at this scale introduces operational overhead and a network hop for no meaningful benefit. Second, keyword-dominant queries: if the user's queries are mostly keyword-based and the semantic similarity is a nice-to-have rather than a core requirement, a traditional search engine like Elasticsearch or OpenSearch may be the better choice. These engines are optimized for keyword search, have mature relevance tuning, and support vector search as an add-on. Third, operational simplicity: if the team does not have the capacity to operate another database, and the vector search is a small feature, embedding it in the existing database (pgvector) or using a managed service may be preferable to running a dedicated vector database. The mechanism that determines whether a vector database is justified is the balance between the benefit and the cost. For small datasets, the benefit is small because brute force is already fast, and the cost is real because a database must be deployed, monitored, and maintained. For keyword-dominant queries, the benefit of semantic search is small relative to the cost of a separate system. For teams without operational capacity, the cost of running a database can outweigh the benefit. The decision should be based on the actual requirements: what is the dataset size, what is the query pattern, what is the latency target, and what is the team's operational capacity? If the dataset is small, the queries are keyword-based, or the team is small, a simpler tool may be the right choice. As the dataset grows or the semantic requirements increase, migrating to a vector database becomes justified. Small scale: thousands to tens of thousands of vectors; brute force is fast enough. Keyword-dominant: queries are mostly exact terms; a search engine is better suited. Operational simplicity: the team lacks the capacity to operate another database. Embedded vector search: pgvector in an existing Postgres may be sufficient. Managed service: a managed vector service may be simpler than self-hosting. Hybrid queries: if both keyword and semantic are needed, a search engine with vector support may be enough. Growth path: plan the migration to a vector database when the dataset or the requirements grow. Benchmark: measure brute force on your actual dataset and query pattern before assuming it is too slow. The trade-off is between simplicity now and scalability later. A brute-force solution is simple and fast to build but does not scale. A search engine is mature and handles keyword queries well but may not match a dedicated vector database for semantic search at scale. A vector database is specialized and scalable but adds operational overhead. The common mistakes are: (1) adding a vector database for a small dataset, which adds complexity without benefit; (2) using a traditional search engine for a semantic-heavy workload, which produces worse results; (3) not planning the growth path, so the team is stuck with a solution that does not scale; (4) assuming that vector search is always better than keyword search, when for many queries keyword is more precise. Version note: the capabilities of traditional search engines (Elasticsearch, OpenSearch, Postgres) have expanded to include vector search, which changes the trade-off. A modern search engine with vector support may be sufficient for many workloads that would previously have required a dedicated vector database. # Brute-force search over a small dataset with numpy.
import numpy as np

corpus = np.random.randn(10_000, 768).astype(np.float32)
corpus /= np.linalg.norm(corpus, axis=1, keepdims=True)
query = np.random.randn(768).astype(np.float32)
query /= np.linalg.norm(query)

similarities = corpus @ query
top_k = np.argpartition(-similarities, 10)[:10]

# This is fast enough for many applications up to ~100k vectors.
# Beyond that, an ANN index (Qdrant) becomes necessary. Version-dependent: the vector search capabilities of traditional search engines and databases (Elasticsearch, OpenSearch, Postgres with pgvector) have improved and are a viable alternative for many workloads. The decision should be based on the current capabilities of each option and benchmarked with your data.

Under what circumstances would a team be justified in NOT using a vector database at all, and instead using brute-force search or a traditional search engine?

Small scale, keyword-dominant queries, or operational simplicity favor simpler tools

Under what circumstances would a team be justified in NOT using a vector database at all, and instead using brute-force search or a traditional search engine?

Small scale, keyword-dominant queries, or operational simplicity favor simpler tools

Scenario Questions

Follow-up Questions