Invalid size for parameter embedding, Expected: N, Actual: M
TL;DR — the vector you wrote has a different dimension count than the vector index expects. The index pinned its Dimensions at creation and it cannot change; either regenerate the embedding at the index's dimension count or create a new index.
What it means
ValidationException: One or more parameter values were invalid. Invalid size for parameter embedding, Expected: 1024, Actual: 512 IndexName: TicketEmbeddingsThat is the verbatim service response we captured in us-east-1 by writing a 512-dimension embedding to a table whose vector index was created with Dimensions: 1024. The write is rejected outright; nothing lands in the table or the index.
The message names three things: the vector attribute (embedding), the dimension count the index expects, and the one you sent. IndexName at the end tells you which of the table's vector indexes (up to 5) raised it.
Why it happens
- You switched embedding models. A model that outputs 512 dimensions replaced one that output 1,024. The index's
Dimensionsis fixed at creation, so every new write now fails. - A truncation or padding step disappeared. Pipelines that slice Matryoshka-style embeddings down to a target size fail like this when the slice is skipped.
- Two indexes, one attribute name. A write that satisfies one index's dimension count can still fail another index defined over the same attribute on a different table.
How to fix it
Regenerate the embedding at the index's dimension count, or delete the index and create a new one at the model's count. There is no in-place change: Dimensions and DistanceFunction are immutable, so a model migration means a new index and a backfill.
If both models must coexist during a migration, write them to two different attributes and give each its own vector index — a table takes up to 5.
Related
The full billing and limits picture is in the DynamoDB vector search guide. The generic prefix of this message has its own page: "One or more parameter values were invalid".