Ask
26
@vector_choice ·

Choosing a vector store for something real: the questions that actually decide it

Ran three in production. Recall benchmarks decided none of it. What decided it, in order:

  • Metadata filtering, and whether it is applied before or after the search. The single most important question and it is barely advertised. Filtering after retrieval means asking for ten results, discarding nine on a tenant or date filter, and getting one. Anything multi-tenant needs pre-filtering or it is quietly broken as it grows.
  • Whether you already run a database that will do this. For a few hundred thousand vectors, the database you have is almost certainly enough, and one system to back up and monitor is worth a lot more than a marginally better index.
  • How the index behaves as it grows. Some index types get dramatically slower past a threshold and need rebuilding with different parameters. Find out where that cliff is before you are on the far side of it.
  • Rebuild and reindex cost. You will change embedding model at some point. How long does a full reindex take and can it happen without downtime?
  • Whether it does hybrid search natively. Combining keyword and vector search is usually a bigger quality win than swapping vector stores.

What did not matter: benchmark recall numbers, which were within noise of each other for our data, and the query language, which you touch once.

The honest default: start with the database you already run. Move only when you hit a specific limit you can name.

8 answers Share
Report

Answering anonymously, a moderator will review it first.

  • @filters_first · 3w ago · 2 replies

    Pre-filtering is the one I got wrong and it is expensive to discover late.

    The symptom is subtle: quality looks fine in testing with a handful of tenants and degrades as data grows, because your ten candidates increasingly all belong to somebody else and get discarded. It reads as the model getting worse.

    Ask the question directly before choosing: is the filter applied during the search or after it? Documentation is often vague and the answer decides whether the thing works at scale.

    18
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @reindexed_twice · 2w ago

      Pre versus post filtering is barely advertised and it decides everything above a few thousand documents.

      10
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
  • @hybrid_search_now · 2w ago

    Worth adding to the deciding questions: whether it can do keyword search alongside vectors, in one query. Pure vector search misses exact identifiers, error codes and product names, which is exactly what people paste in.

    We got more quality from adding keyword matching than from any store change.

    18
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
  • @pg_is_enough · 3w ago · 2 replies

    Seconding the default. The threshold where a dedicated store starts earning its keep is much higher than the marketing implies, and below it you are running a second system for no measurable gain.

    The specific thing to watch on the general-purpose route is the index type and its parameters, because the defaults are tuned for small data and the falloff past a certain row count is steep. That is a tuning problem, not a reason to migrate, and people migrate instead of tuning.

    23
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @hybrid_search_now · 2w ago

      The threshold for needing a dedicated store is much higher than the marketing suggests. Ours was about two million chunks.

      7
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
  • @vector_choice · 3w ago · 3 replies

    Reindexing is the one people skip. You will change embedding model, it is not optional, and if a full rebuild means downtime you find that out at the worst moment. Ask early, it is a five minute question.

    1
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @reindexed_twice · 2w ago · 2 replies

      Changed embedding model twice and the second time was painless purely because of how the first one went.

      What makes it survivable: store the raw text and the metadata as the source of truth, treat the vector store as a derived index you can throw away, and keep the model name on every row. Then a migration is build the new index alongside, switch, delete the old one.

      If your chunks only exist inside the vector store, a model change is a data recovery exercise.

      23
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
      • @vector_choice · 2w ago

        Derived index rather than database is the mental model that makes every one of these decisions easier.

        13
        Share
        Reply

        Answering anonymously, a moderator will review it first.

        Report