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.

1
Small scale: thousands to tens of thousands of vectors; brute force is fast enough.
2
Keyword-dominant: queries are mostly exact terms; a search engine is better suited.
3
Operational simplicity: the team lacks the capacity to operate another database.
4
Embedded vector search: pgvector in an existing Postgres may be sufficient.
5
Managed service: a managed vector service may be simpler than self-hosting.
6
Hybrid queries: if both keyword and semantic are needed, a search engine with vector support may be enough.
7
Growth path: plan the migration to a vector database when the dataset or the requirements grow.
8
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.

javascript

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.

Difficulty: 6/10

Topics: Database Comparison, Small Scale, Search Engines

Scenario Questions

0-2 years experience

1
You have 5,000 vectors and you are considering Qdrant. Explain why brute force might be sufficient and simpler.
2
A teammate wants to add a vector database for a keyword-heavy search feature. Explain why a search engine might be better.

2-5 years experience

1
Your dataset has grown from 10k to 1M vectors and brute force is too slow. Describe the migration to a vector database.
2
You need both keyword and semantic search. Describe how you would decide between a search engine with vector support and a dedicated vector database.

5-8 years experience

1
Design a hybrid search system that uses a traditional search engine for keyword and a vector database for semantic, and describe how you would merge the results.
2
You are advising a team on their search architecture. Describe the decision framework for choosing between brute force, a search engine, and a vector database.

8+ years experience

1
Derive the dataset size at which a vector database becomes more cost-effective than brute force, as a function of dimension, QPS, latency target, and infrastructure cost.
2
You are designing a search architecture for a company with diverse workloads. Describe how you would decide which workloads use which technology.

Follow-up Questions

❓At what dataset size does brute force become too slow, and how would you determine that for your specific workload?
❓If you start with a traditional search engine and later need a vector database, what is the migration path and how would you keep the two in sync?