Vector indexes

A vector index lets DynamoDB find items whose embedding is nearest to a query vector. Dynomatic lists every vector index on a table beside its GSIs and LSIs, and creates and deletes them from the same place.

To get there, open a query tab on the table, click Table settings in the rail, and choose Indexes. The Manage indexes dialog reached from the Tables popover shows the same list.

What a vector index row tells you

Each row names the index, then its vector attribute, its dimensions, its distance function, and its projection, which is the one thing that tells two indexes on the same attribute apart.

• A Creating, Updating, or Deleting pill shows while DynamoDB is still working on the index.
• An Indexing existing items badge shows while DynamoDB is still covering the vectors already in your items. DynamoDB calls this backfilling, and it embeds nothing.
• A coverage line reads “approximately N of M items indexed”, refreshed about every six hours. It is always approximate, and it says so rather than showing a number it cannot stand behind.
• The index size appears where DynamoDB reports one.
• Embed jumps to the Embeddings section, and Delete removes the index.

The list refreshes itself every ten seconds until every index has settled, so an index that finishes is reflected without reopening anything. Refresh in the section header re-reads the table on demand.

Create a vector index

Click Create vector index. The dialog is a one-shot commitment, not a form you come back to, because every setting is locked in once DynamoDB has the index.

Fill in the edit step

• Index name, 3 to 255 characters of letters, numbers, dots, hyphens, and underscores. GSIs, LSIs, and vector indexes share one namespace on a table.
• Vector attribute, picked from the attributes Dynomatic has observed on the table, or typed in. Key attributes are excluded. An attribute another vector index already covers is offered, because a second index on it is legal, but the second index has to match the first one’s width.
• Dimensions, up to 4096. Choosing an attribute that an embedding recipe targets prefills the recipe’s width, tagged “from recipe”, along with cosine. A width you typed is never overwritten by a later prefill.
• Distance function, one of cosine, euclidean, or dot product.
• Projection, one of All attributes, Keys only, or Include specific attributes, where the last takes a list of projected attributes.
• Search schema, at most one partition attribute plus any number of inline filter attributes. Each row carries a declared type of String, Number, or Binary, prefilled from the table’s attribute definitions, then from what Dynomatic has observed, else String.

Two live counters sit under the fields. One reads “N of 100 projected attributes used across this table’s indexes”, turns red past the limit, and blocks. The other reads “N of 5 vector indexes”, and at five Continue goes inert with the reason announced. Both are DynamoDB’s limits, not Dynomatic’s.

When you set dimensions on a table that has ALL-projection GSIs, a warning names them, because every one of those indexes copies the vector and grows accordingly.

Review and confirm

Continue leads to a review step listing all six settings, each suffixed “cannot be changed after creation”, with the GSI growth warning again and one sentence of reasoning. DynamoDB backfills the index at no charge, so the cost is permanence and storage, and a wrong setting can only be fixed by deleting the index and creating it again.

On a table classified as production the confirm is red, reads Create on prod, and stays inert until you type the table name. Elsewhere it is a plain Create index. Back returns to the edit step with everything kept.

If the table is not ACTIVE when you confirm, the dialog waits and dispatches on its own once the table comes back. Success closes the dialog, and the row shows Indexing existing items until DynamoDB has covered the items already in the table.

Delete a vector index

Delete on a row opens a dialog that says up front that your items are untouched, and that delete and recreate is how a wrong configuration is fixed. It is gated on typing the table name, and on a production table it reads Delete from prod and carries a production badge. The row shows Deleting until DynamoDB removes it.

DynamoDB refuses a table delete while one of its vector indexes is being created, updated, or deleted, and the delete-table dialog says so and names the index.

Things to know

• Creating and deleting vector indexes sits behind the Table CRUD plan gate. The controls stay readable and focusable with the reason announced when the gate is not met.
• Vector indexes are never offered as a Query target. Picking one in a place that chooses an index opens the Vector search flavor instead of binding the builder.
• Recreating a table in another workspace does not copy its vector indexes. The dialog says so and points you back here.
• A table with a vector index does not scan on open, whatever its status, because DynamoDB charges a scan for every item’s full vector even when the projection leaves it out. A per-table override turns it back on.
• Next, generate the vectors themselves with an embedding recipe.