uripeled2

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?

Our vision is to provide async native and production ready SDK while creating a powerful and fast integration with different LLM without letting the user lose any flexibility (API params, endpoints etc.)

Take a look at llm-client a similar library that also support chat, async and more llm providers https://github.com/uripeled2/llm-client-sdk