SearchConditionExpression must be provided when SearchSchema has a HASH key

TL;DR — the vector index was created with a HASH search-schema attribute, which makes a partition filter mandatory. Every SearchVectors call must pin exactly one value for it with an equality condition; there is no "search all partitions" mode.

What it means

ValidationException: SearchConditionExpression must be provided when SearchSchema has a HASH key

That is the verbatim service response we captured in us-east-1 by omitting the condition against an index defined with a HASH element. The choice was made at index creation: a HASH key partitions the index, and from then on each search is scoped to exactly one partition value.

Why it happens

• The condition is missing entirely — the most common case when code written against a schema-less index is pointed at one with a HASH key.
• The expression doesn't pin the HASH attribute — filtering only on an INLINE_FILTER attribute doesn't satisfy the requirement.
• The expression uses anything other than equality — SearchConditionExpression accepts = only, so a begins_with or IN on the partition attribute fails too.

How to fix it

Add the condition and pin one value:

aws dynamodb search-vectors \
  --table-name SupportTickets \
  --index-name TicketEmbeddings \
  --search-vector file://query-vector.json \
  --top-k 10 \
  --search-condition-expression "product = :p" \
  --expression-attribute-values '{":p": {"S": "checkout"}}'

If your access pattern genuinely needs cross-partition search, the index must be created without a HASH element — the search schema is immutable, so that means a new index. And treat the key as a routing choice, not a security boundary: fine-grained access control does not apply to SearchVectors.

Related

What a HASH key buys you (throughput scaling, cheaper searches) and what it costs: the DynamoDB vector search guide.