Vector databases are powerful tools, but I’ve noticed a common pattern: as soon as a team decides to use embeddings for similarity search, a vector DB often gets added as the “default next step” — before stopping to ask whether the workload actually benefits from it at all.
In vector DBs, the indexing phase often takes much longer than a single query, so if your data is short-lived or your query volume is low, you may never recover that cost, even if each individual query is faster.
I share a simple benchmark you can run with your own numbers (embedding count, dimensions, top-k) to quantify the trade-off. It gives you a practical way to answer: does indexing make sense here, or would a simple KNN approach be faster and lower-complexity?
1 comment
[ 3.2 ms ] story [ 11.3 ms ] threadIn vector DBs, the indexing phase often takes much longer than a single query, so if your data is short-lived or your query volume is low, you may never recover that cost, even if each individual query is faster.
I share a simple benchmark you can run with your own numbers (embedding count, dimensions, top-k) to quantify the trade-off. It gives you a practical way to answer: does indexing make sense here, or would a simple KNN approach be faster and lower-complexity?