Why Vector DBs Are the Wrong Abstraction – and What We Built Instead (opens in new tab)

disclaimer: co-founder of topk here :)

not rude at all, it's a common sentiment. TopK gives you all the capabilities under one roof -- text, vectors, filters, embeddings, re-ranking, all behind a single API (so single SDK, single vendor, single bill, single observability plane, etc). This simplifies your integration (less code on your part) and gives you more flexibility to define custom scoring rules (elastic-style) but over text + vectors + any other pre-computed factors. Take a look at [this](https://docs.topk.io/concepts/unified-retrieval#custom-scori...) docs page which goes into detail if you are interested.

I'd be curious to learn about your setup though. Vespa comes with lexical search so what made you choose this combo? Was Elastic already present in your stack before adopting Vespa?

We actually tried to extend DataFusion at first but ultimately decided against it since we can get most of the value by using Arrow and its compute kernels directly. DataFusion also executes filters in a way that rebuilds the underlying arrays (data copy) and requires strict schema, which is not a good fit for our schemaless document-oriented model. In the end, switching from DataFusion to Reactor gave us 3x better latencies.

Founder of TopK here. There are legit use cases for vector-based retrieval (e.g. semantic search, recommendations, multi-modal search, etc.) but that only requires supporting vectors as a data type, not building the whole database around vectors as a first-class citizen (which is what vector DBs do). In practice, you also want to combine multiple vectors, text filters, and metadata alongside custom scoring functions to optimize relevance in your domain, which is not possible with a database built around a vector index.