A vector is just an attribute
A vector is a list of numbers on an item. An index is what makes it searchable.
Why
There is no vector attribute type. A vector is an L of N, a list of numbers, sitting on the item beside everything else. What makes it searchable is a vector index, and that is declared at the top level of CreateTable under VectorIndexes rather than as a variant of a GSI, because it is not one: it has no key schema, and you search it by distance rather than querying it by key.
The index pins two things at creation that you cannot change afterwards: how many dimensions each vector has, and which distance function compares them. Everything else about the vector is unchecked. Write three numbers into a three-dimensional index and it is happy; write three different numbers that mean something else entirely and it is just as happy.
One rule here runs backwards from everything the course has taught so far. Every key attribute has to be declared in AttributeDefinitions. The vector attribute must not be, and a CreateTable that declares it is rejected.
The base table keeps exactly what you wrote. The index holds 32-bit copies, so a value written at full double precision reads back through the index very slightly rounded. At three dimensions that is invisible, and at 384 it is still far below anything that changes a ranking.
Notice what is not in any of this. Nothing required a model to have produced the numbers: these are the red, green and blue channels off a paint chart, and the index handles them exactly as it handles a sentence embedding, by counting them and comparing them by distance. A vector index is a nearest-neighbour structure over an n-dimensional space, and it neither knows nor cares whether that space came out of a neural network, a map projection or a unit conversion. Anything you can turn into a fixed-length list of numbers where being near means something useful is a candidate.
A vector is an ordinary list-of-numbers attribute; the index is what makes it searchable, and it fixes the dimensions and the distance function for good.
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.
Crimson's rgb sits alongside name and family as an ordinary attribute. It is a list of three numbers, an L of N. There is no vector type in DynamoDB.
A bright red goes in as the search vector; the reds come back. You could have picked these off the table yourself, which is the point: nothing mystical happens at three dimensions, and nothing different happens at 384.
A plain PutItem. The vector is supplied like any other attribute, because DynamoDB never computes one for you: your application embeds, then writes.
Cherry is in the results now. Nothing rebuilt the index and nothing was queued: the index was maintained as part of the write that added the row.
Built on this
- Sensor Fusion - Which machines are behaving like this one?
- Geospatial Nearest Neighbour - Which store is actually nearest?
- Agent Memory Store - What should this agent remember?
- RAG Chunk Store - Which passages answer this question?
- Tenant Incident Triage - Which matching tickets belong to us?
- More Like This - What else is like this item?
- Catalogue Semantic Search - What’s like this, and in stock?
- Design Token Similarity - Which approved colour is this one?
Crimson's rgb sits alongside name and family as an ordinary attribute. It is a list of three numbers, an L of N. There is no vector type in DynamoDB.
Choose an access pattern above, or build your own request. See what comes back and what it costs.