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".

ProductCataloguedynoxide · wasm · DynamoDB API 2012-08-10 · contract 1

These rows are real and already here. Running an operation against them downloads a DynamoDB-compatible engine, about 850 KB, and executes it in this tab.

Try an example

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.

Indexoptionalbase table, or a secondary indexKeyConditionExpressionFilterExpressionoptionalExpressionAttributeValues

{
  "TableName": "ProductCatalogue",
  "ReturnConsumedCapacity": "TOTAL"
}

pk(pk)