When similarity is the wrong question
Some questions are not similarity questions, and a vector index answers them badly.
Why
TopK is a hard ceiling of 100, and there is nothing behind it. A search response carries no LastEvaluatedKey, so there is no way to ask for the next hundred. Every other read in this course can be continued; this one cannot.
That changes what post-filtering costs you. Filter a Query's results in your application and you can always go back for more rows. Filter a search's results and you are spending from a fixed budget of a hundred with no way to top it up. This catalogue has 104 in-stock outdoor products and just 12 of them are under 50 pounds, so a hundred results spent on similarity, then filtered on price in your own code, leaves you with a handful and no way to ask for others. The third run answers that same question exactly, with a key condition, and it is not close.
Three shapes where a vector index is the wrong tool. An exact lookup: you know the key, so use it. A small candidate set: a Query reads all of them for less than a search costs. And anything needing full recall, because a production vector index is approximate by design and can miss a match that was genuinely there.
That last point needs care on this page, because the engine running these examples is not approximate. It compares your query against every entry in the scoped index and returns the true nearest, which is why the results here are exactly reproducible. AWS builds an approximate index and trades a little recall for speed at a scale this table will never reach. The mechanics, the API, the refusals and the costs are the same; the guarantee about completeness is not, and it is the one thing on this page you should not carry across unchanged.
None of this makes vector indexes a bad tool, and it does not make them a replacement for a GSI either. They are complements. Reach for the vector index when the question is genuinely "what is like this", and for a key condition when it is "what matches this". Most features need both, and the tell is whether you could write the question down as a rule.
Top-K is a hard ceiling with no pagination behind it, so anything you can express as a key condition belongs in one; a vector index answers "what is like this", not "what matches this".
Try it. Then change it.
Predict what each request will do. Run it, inspect the response, then change a value in the workbench and try again.
TopK at its maximum, filtered to in-stock outdoor gear. A hundred results come back, which is every result you are ever going to get for this query.
Meant to fail. One more than the maximum is refused, and there is no LastEvaluatedKey in a search response to continue from either. A hundred is not a page size, it is the whole answer.
"Outdoor gear between 20 and 50 pounds, cheapest first." A GSI keyed on category with price as its sort key answers it exactly, completely, in order, and for a fraction of the cost. Nothing about this question was ever a similarity question.
TopK at its maximum, filtered to in-stock outdoor gear. A hundred results come back, which is every result you are ever going to get for this query.
Choose an access pattern above, or build your own request. See what comes back and what it costs.