Ricerca vettoriale in DynamoDB

DynamoDB ha guadagnato la ricerca vettoriale nativa il 5 agosto 2026. Memorizzi gli embedding come una semplice List di valori Number sui tuoi item, aggiungi un indice vettoriale ed esegui query approssimate del vicino più prossimo con la nuova API SearchVectors.

Finora, ricerca per similarità significava replicare la tabella in OpenSearch o in un database vettoriale separato e tenere i due sincronizzati. Quella pipeline è sparita. Il modello di fatturazione che la sostituisce non assomiglia a nient'altro in DynamoDB.

DynamoDB supporta la ricerca vettoriale?

Sì — in modo nativo, dal 5 agosto 2026. Memorizzi gli embedding come una semplice List di valori Number, aggiungi un indice vettoriale ed esegui query approssimate del vicino più prossimo con l'API SearchVectors — nessuna replica OpenSearch, nessun database vettoriale separato. Funziona solo su tabelle on-demand, fino a 4,096 dimensioni, ed è fatturata per byte scritto, cercato e memorizzato.

• Una terza famiglia di indici: gli indici vettoriali stanno accanto a GSI e LSI. Una nuova API di lettura (SearchVectors), solo ANN, solo tabelle on-demand, fino a 4,096 dimensioni.
• È veloce, misurato: contro il nostro indice live a 1024 dimensioni in us-east-1, SearchVectors ha risposto rapidamente quanto GetItem dallo stesso client (p50 39 ms vs 44 ms), e una scrittura fresca è diventata ricercabile in ~136 ms.
• La misurazione è per byte: $0.52 per GB di scritture vettoriali, $0.002 per GB di dati vettoriali esaminati da una ricerca, $0.25 per GB-mese di archiviazione (us-east-1). Indicizzare un embedding fa sì che la sua copia nella tabella base fatturi esattamente 4 byte per dimensione; la stessa lista non indicizzata fattura ~1.9×.
• S3 Vectors resta l'archivio di massa: circa 8× più economico a riposo e molto più economico da caricare in batch. DynamoDB vince su letture in millisecondi, scritture in streaming e vettori che vivono accanto all'item che descrivono.

Come funziona un indice vettoriale

Non c'è nessun nuovo tipo di attributo. Un embedding è una normale lista di numeri sull'item, {"L": [{"N": "0.0132"}, {"N": "-0.0475"}, …]} sul wire, scritta con gli stessi PutItem e UpdateItem che usi già.

L'indice è una struttura separata. DynamoDB vi replica il vettore in modo asincrono con precisione float a 32 bit, insieme a qualsiasi attributo che proietti o su cui filtri. I risultati di ricerca sono eventualmente coerenti, come una lettura da GSI.

Il ritardo è piccolo nella pratica. Contro il nostro indice di test live, un vettore appena scritto è comparso nei risultati di ricerca circa 136 ms dopo che la PutItem era ritornata. Comunque, non costruirci mai sopra un flusso read-your-own-write.

Dove si colloca rispetto ai tipi di indice che già conosci:

Ogni indice fissa alla creazione il proprio numero di dimensioni (fino a 4,096) e una delle tre funzioni di distanza. Con COSINE ed EUCLIDEAN un punteggio più basso significa più simile; con DOT_PRODUCT un punteggio più alto significa più simile e può diventare negativo. Niente di tutto questo può essere cambiato in seguito.

Una nota sulla precisione prima di fare qualsiasi benchmark. L'indice conserva i vettori a f32; i valori a precisione più alta vengono accettati ma perdono precisione all'ingresso. Se arrivi con embedding float64, ogni distanza viene calcolata contro la copia f32, quindi misura il recall contro f32, non contro i tuoi originali.

Creane uno ed esegui una ricerca

Supponi di offrire ricerca semantica sui ticket di supporto, così che un agente possa trovare i "clienti che hanno già incontrato questo problema" senza far corrispondere parole chiave. Ogni item ticket porta un embedding del proprio oggetto e corpo, generato dal modello che preferisci (Titan Text Embeddings V2 costa $0.02 per milione di token di input su Bedrock).

Aggiungi l'indice alla tabella esistente. L'elemento HASH limita ogni ricerca a un singolo valore di product; gli attributi INLINE_FILTER (fino a 18) permettono filtri di uguaglianza al momento della ricerca:

aws dynamodb update-table \
  --table-name SupportTickets \
  --attribute-definitions AttributeName=product,AttributeType=S \
                          AttributeName=severity,AttributeType=S \
  --vector-index-updates '[{"Create": {
    "IndexName": "TicketEmbeddings",
    "VectorAttribute": {"AttributeName": "embedding"},
    "SearchSchema": [
      {"AttributeName": "product", "SearchSchemaElementType": "HASH"},
      {"AttributeName": "severity", "SearchSchemaElementType": "INLINE_FILTER"}
    ],
    "Projection": {"ProjectionType": "KEYS_ONLY"},
    "Dimensions": 1024,
    "DistanceFunction": "COSINE"
  }}]'

La costruzione si comporta come un backfill di GSI, ma con spigoli più taglienti. SearchVectors restituisce ValidationException per tutta la durata della costruzione, senza risultati parziali.

AWS avverte che l'endpoint di ricerca può continuare a rifiutare per un po' anche dopo che DescribeTable dice ACTIVE. Non esiste un waiter; sonda con una ricerca reale in un loop di retry. Quando abbiamo creato l'indice insieme a una tabella vuota, è passato ad ACTIVE in 26 secondi e ha accettato ricerche 0.6 s dopo.

La ricerca prende l'embedding di query come un array JSON nudo di valori {"N": …}. Non avvolgerlo in una L DynamoDB. L'attributo memorizzato usa il tipo lista, il parametro della richiesta no, e confonderli è un primo errore facile da fare:

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

Ricevi fino a TopK item ordinati dal più simile in giù, ciascuno con uno Score, più ConsumedCapacity quando la richiedi. TopK ha un tetto di 100, non c'è paginazione e la risposta ha un tetto di 16 MB.

L'embedding stesso è escluso dai risultati, a meno che tu non lo proietti e lo richieda. Quel default è deliberato; restituire i vettori gonfia sia la risposta sia la bolletta della ricerca.

Le espressioni di filtro accettano solo l'uguaglianza, senza BETWEEN, IN o begins_with. Quando l'indice definisce un attributo HASH, ogni ricerca deve fissarne esattamente un valore. La formulazione di AWS sugli operatori di intervallo è "not yet available", quindi questo vincolo potrebbe allentarsi.

Due sorprese operative vale la pena conoscerle prima del primo deploy. SearchVectors richiede la nuova azione IAM dynamodb:SearchVectors, che nessuna delle tue policy di lettura esistenti include.

Parla inoltre con un endpoint separato, search-dynamodb.{region}.amazonaws.com. Le allowlist di egress e le configurazioni di endpoint VPC che coprono solo dynamodb.{region} rompono la sola ricerca vettoriale, con un errore di connessione che non dice mai il perché.

Cosa fattura un indice vettoriale

Tre nuovi contatori, tutti per byte, con un minimo di 1 KB per ogni richiesta di scrittura e per ogni richiesta di ricerca, sopra ai normali addebiti della tabella (us-east-1, dall'API dei prezzi AWS, 2026-08-15):

La documentazione avverte che la copia nella tabella base di un embedding, memorizzata come stringhe decimali dentro una List, può essere "considerably larger" della copia f32 nell'indice. Abbiamo misurato la fatturazione in unità di scrittura contro tabelle live in us-east-1, e la verità è più strana.

Un embedding su un attributo senza indice vettoriale fattura la regola decimale documentata, circa 1.9× la dimensione f32. Punta un indice vettoriale su quello stesso attributo e la sua fatturazione nella tabella base scende esattamente a 4 byte per dimensione:

Misurato cercando per bisezione il confine delle unità di scrittura con un attributo di riempimento, chiave dell'item fresca a ogni scrittura, calibrato al byte. Il nostro item ticket completo a 1024 dimensioni ha fatturato 5 unità di scrittura; l'item identico senza un indice su embedding ne fattura 8.

Il contatore delle scritture vettoriali ha seguito da vicino la dimensione f32 negli stessi run. VectorWriteRequestBytes è risultato pari a 4 byte per dimensione più 11 B di overhead di chiave su un indice nudo, e più 65 B con il nostro search schema a due attributi.

La fatturazione delle ricerche è il contatore che non puoi calcolare in anticipo. VectorSearchRequestBytes traccia quanti dati vettoriali ha esaminato l'attraversamento ANN, e la stessa indicazione di AWS è di misurarlo tramite ReturnConsumedCapacity invece di stimarlo dal numero di dimensioni.

Il nostro probe fornisce i primi punti dati. TopK=10 su una partizione da 50 vettori ha esaminato 22.2-22.4 KB per ricerca; la stessa ricerca su una partizione da 1 vettore ha comunque esaminato 21.4 KB, quindi su piccola scala c'è un pavimento di circa 21 KB (circa $0.00000004) per query. Il tutorial di AWS riporta 31,449 byte per il proprio esempio da 50 vettori.

Modella i costi lato tabella nel calcolatore dei prezzi; i contatori vettoriali si sommano alle unità di scrittura che già calcola.

Ricerca vettoriale DynamoDB vs S3 Vectors

AWS ora vende due archivi vettoriali serverless, costruiti per pattern di accesso opposti. S3 Vectors (GA dicembre 2025) contiene fino a 2 miliardi di vettori per indice a $0.06/GB-mese, risponde nell'intervallo tra 100 ms e 1 s e fattura ogni query sull'intera dimensione dell'indice.

DynamoDB risponde in millisecondi e fattura su ciò che la ricerca esamina, non su ciò che l'indice contiene.

I minimi di scrittura decidono il caso streaming, e puntano nella direzione opposta rispetto alle tariffe di archiviazione. Scrivendo un vettore a 1024 dimensioni alla volta, per milione di scritture (dalle tariffe verificate e dalle nostre 5 unità di scrittura + 4,161 byte di scrittura vettoriale misurati per item):

Il minimo di 128 KB per PUT di S3 lo rende l'opzione costosa esattamente per il carico di lavoro per cui la gente lo presume economico. Manda i vettori in streaming uno alla volta dentro S3 Vectors e paghi quasi 5× la tariffa di DynamoDB; caricali in batch e paghi circa 7× meno.

Totali mensili di archiviazione e query per un corpus a 1024 dimensioni con 1M di query al mese, calcolati dalle tariffe verificate (i costi di scrittura sono nella tabella per milione qui sopra). L'addebito query di S3 Vectors segue la sua formula pubblicata: dimensione dell'intero indice per una tariffa a scaglioni.

L'addebito query di DynamoDB dipende dai byte esaminati, quindi mostriamo un intervallo di sensibilità invece di fingere di conoscere il tuo attraversamento:

Da quella tabella emergono due cose. Il costo per query di DynamoDB non cresce con la dimensione del corpus — una ricerca ANN esamina un vicinato, non l'indice, e la delimitazione per chiave di partizione lo riduce ulteriormente.

Il vantaggio di archiviazione di S3 Vectors (~8×, dato che DynamoDB memorizza due copie f32 a 4× la tariffa) si accumula per sempre, che qualcuno interroghi o no.

Quando usare quale

• I vettori descrivono item vivi che tieni già in DynamoDB (ticket, prodotti, sessioni utente, memoria di agenti): usa l'indice vettoriale. Un solo percorso di scrittura, un solo item, nessuna pipeline di sincronizzazione che possa andare alla deriva.
• Milioni di embedding, interrogati occasionalmente (RAG su documenti, archivi, job notturni): usa S3 Vectors. Carichi in batch a poco prezzo, paghi $0.06/GB a riposo, tolleri qualche centinaio di ms.
• QPS alto con ranking ibrido (rilevanza testuale + vettori, faceting, aggregazioni): OpenSearch resta la risposta, con un pavimento infrastrutturale di circa $350/mese per una classica collection serverless.
• Vettori uniti a dati relazionali: Aurora PostgreSQL con pgvector, che scala a zero e resta sotto ~$50/mese per piccoli carichi di lavoro RAG.

Il default onesto per chi lavora con DynamoDB è entrambi. Tieni i vettori caldi e filtrabili sulla tabella, dove le scritture sono atomiche con l'item, e archivia la coda lunga su S3 Vectors, le cui scritture in batch fortemente coerenti ne fanno un pozzo pulito.

Le trappole

• De-indicizzazione silenziosa: un item privo dell'attributo HASH dell'indice si scrive benissimo nella tabella e non entra mai nell'indice vettoriale. L'abbiamo riprodotto dal vivo: la PutItem è riuscita, e il vettore era assente da ogni partizione 15 secondi dopo. Nessun errore, nessun risultato, niente nella risposta a dirtelo.
• Le scritture con dimensioni sbagliate vengono rifiutate: cambia modello di embedding senza migrare e ogni scrittura fallisce con una ValidationException che nomina l'attributo ed entrambe le dimensioni (Invalid size for parameter, catturata verbatim nella sua pagina dedicata), dato che l'indice blocca per sempre il numero di dimensioni.
• Embedding obsoleti: DynamoDB non ricalcola mai i vettori. Modifica il testo di un ticket senza riscrivere embedding e le ricerche corrisponderanno silenziosamente al vecchio contenuto. Streams più un consumer di rigenerazione è la soluzione standard.
• TopK restituisce sempre K item: con tre corrispondenze buone e --top-k 10, ne ricevi comunque 10. Giudica la rilevanza dallo Score, non dal numero di risultati, e ricorda che la direzione del punteggio si inverte tra le funzioni di distanza.
• I minimi di 1 KB: i vettori a poche dimensioni non vengono misurati proporzionalmente più economici, né in scrittura né in ricerca.
• Tutto è immutabile: dimensioni, funzione di distanza e l'insieme di attributi di una proiezione INCLUDE richiedono tutti un elimina-e-ricrea per cambiare. L'archiviazione dell'indice fattura per l'intera vita dell'indice, interrogato o no.

Provalo sulle tue tabelle

La ricerca vettoriale eredita la disciplina dei costi che il resto di DynamoDB ti ha insegnato. Dimensiona l'embedding prima di impegnarti, perché i limiti di dimensione degli item valgono ancora e un embedding a 3072 dimensioni aggiunge 12 KB a ogni scrittura dell'item su entrambi i contatori.

La meccanica dell'indice ti sembrerà familiare se sai come i GSI si replicano in modo asincrono e quando scegliere un GSI invece di un LSI. Per la ricerca lessicale sugli stessi dati, DynamoDB non ha ancora un motore full-text; la ricerca vettoriale abbina il significato, non l'ortografia.

Verifica il costo reale in byte di un embedding nel calcolatore delle dimensioni degli item, poi prova DynoTable per sfogliare gli item dietro il tuo indice vettoriale — gli embedding vengono mostrati come normali attributi lista, proprio accanto ai campi su cui filtri.