Scegli il vector database in base a cosa si rompe per primo

Quasi ogni sistema di retrieval dovrebbe partire da pgvector nel Postgres che già gestisci, e la domanda di selezione non è "quale vector database è il più veloce" ma "quale failure mode mi raggiunge per primo". I numeri pubblicati di recall e QPS convergono tra i vari engine alle scale a cui la maggior parte dei team opera davvero. Quello che non converge è cosa succede quando aggiungi un filtro per tenant a ogni query, quando l'indice va ricostruito in orario lavorativo, o quando il grafo HNSW smette di stare in RAM. Sono questi gli eventi che forzano una migrazione, e ogni engine fallisce su uno diverso.

Quindi il modo onesto di confrontare i vector store è lavorare a ritroso dalla rottura. Scegli il guasto che colpirai per primo, poi scegli l'engine che non ce l'ha. Tutto il resto è una griglia di feature.

Le quattro cose che si rompono davvero

Nei sistemi RAG e di memoria per agenti in produzione, quattro sintomi spiegano quasi ogni migrazione dalla scelta iniziale:

• Tempo di build e rebuild dell'indice. Cambi il modello di embedding, o la dimensione, o l'operatore di distanza, e ora devi ricostruire un indice approximate-nearest-neighbour su ogni riga. A un milione di vettori è il tempo di un caffè. A cinquanta milioni è una finestra di manutenzione, e devi decidere se il vecchio indice serve il traffico mentre il nuovo viene costruito.
• Recall della ricerca filtrata. Quasi nessuno esegue una query vettoriale senza filtri in produzione. Le query reali sono "nearest neighbours where tenant_id = X and status = active and updated_at > Y". Gli indici a grafo sono costruiti per il caso non filtrato, e un filtro selettivo può far restituire a una ricerca ANN meno delle k righe richieste, in silenzio. È un problema di correttezza travestito da problema di rilevanza.
• Memoria del grafo contro RAM. HNSW è un grafo, e vuole vivere in memoria. Quando il grafo più il tuo working set superano quello che l'istanza ha, la latenza non degrada con grazia, precipita da un dirupo mentre la macchina inizia a leggere pagine di indice dal disco a ogni probe.
• Ritardo di freshness sotto carico di scrittura. La memoria degli agenti e gli strumenti di supporto scrivono in continuazione. Ogni insert muta il grafo, la manutenzione dell'indice compete con il traffico di query, e il divario tra "abbiamo salvato il fatto" e "il fatto è recuperabile" inizia a contare per la correttezza, non per la sensazione.

Nota cosa non c'è in quella lista: le query grezze al secondo. Se stai servendo retrieval a un modello che poi passa due secondi a generare, dieci millisecondi di differenza nella latenza di ricerca sono rumore. The latency that hurts in RAG lives in the number of round trips, non nel probe ANN.

pgvector: il default corretto, e i suoi tetti reali

L'argomento a favore di pgvector non è che vince i benchmark. È che i tuoi embedding vivono nella stessa transazione della riga che descrivono, i tuoi filtri sono SQL ordinario su colonne che hanno già indici, la tua storia di backup e point-in-time recovery è quella che già gestisci, e il tuo on-call sa già leggere EXPLAIN. Quella combinazione vale parecchio p99.

I tetti sono specifici e vale la pena memorizzarli, perché la paura vaga di quei limiti causa più migrazioni premature di quante ne causino i limiti stessi:

• I limiti di dimensione sono limiti dell'indice, non della colonna. Una colonna vector accetta fino a 16.000 dimensioni, ma HNSW e IVFFlat indicizzano solo fino a 2.000. Usa halfvec (float a 16 bit) e indicizzi fino a 4.000 dimensioni con circa metà dello storage. bit indicizza fino a 64.000 dimensioni per la binary quantization, e sparsevec gestisce fino a 1.000 elementi non nulli. Un embedding a 3.072 dimensioni non è un motivo per lasciare Postgres, è un motivo per fare cast a halfvec nell'espressione dell'indice.
• Le query filtrate hanno smesso di essere un dirupo nella 0.8.0. Il vecchio guasto era reale: una scansione HNSW restituiva i suoi candidati ef_search, la tua clausola WHERE ne eliminava la maggior parte, e ricevevi tre righe quando ne avevi chieste dieci. pgvector 0.8.0 ha aggiunto le scansioni iterative dell'indice, che continuano a scansionare finché non hanno abbastanza righe sopravvissute. hnsw.iterative_scan = strict_order preserva l'ordinamento esatto per distanza, relaxed_order scambia un po' di ordinamento per un recall migliore. Se il tuo modello mentale del filtering di pgvector risale al 2024, è superato.
• La memoria di build è la cosa che morde davvero. HNSW costruisce in memoria quando il grafo sta dentro maintenance_work_mem, e ripiega su un percorso su disco molto più lento quando non ci sta. Il rimedio è alzarla per la build e usare worker paralleli, ma esiste una dimensione oltre la quale stai pianificando un rebuild invece di eseguirlo.
• I noisy neighbour sono un problema architetturale. Una build ANN che satura la CPU sull'istanza che serve il tuo flusso di checkout è il failure mode che non ha nulla a che fare con i vettori. Una read replica o un'istanza separata lo risolve, che è anche il momento in cui pgvector smette di essere gratis.

Su AWS in particolare, Aurora PostgreSQL con pgvector è un vector store di prima classe per Bedrock Knowledge Bases, quindi sceglierlo non ti costa nessuna feature di RAG gestito. Ho documentato il lato costi in the OpenSearch Serverless to Aurora migration post, con un avvertimento più sotto: il lato OpenSearch di quel confronto è cambiato a maggio 2026.

OpenSearch: stai comprando un motore di ricerca, quindi usalo come tale

Scegliere OpenSearch puramente come vector store è il modo costoso di ottenere la ricerca vettoriale. Sceglierlo perché ti serve la ricerca, e i vettori sono una delle cose con cui cerchi, è una decisione diversa e molto migliore.

Cosa ti dà che un vector store puro non dà: vera ricerca lessicale accanto all'ANN, così il retrieval ibrido che combina BM25 con la similarità vettoriale è una query, non un'architettura. Matching esatto per keyword sui codici articolo, i codici di errore e gli identificatori con cui gli embedding sono notoriamente pessimi. Aggregazioni, faceting e un motore di filtering costruito per attributi ad alta cardinalità invece che aggiunto a posteriori. E i vettori binari, che su Bedrock Knowledge Bases solo le due opzioni OpenSearch supportano.

L'argomento contrario è stato storicamente il pavimento di costo: OpenSearch Serverless fatturava in OCU con un minimo di produzione che costava soldi veri prima ancora di indicizzare un documento. È l'argomento su cui era costruito il mio post sulla migrazione, e va corretto. La nuova generazione di OpenSearch Serverless è diventata generally available il 28 maggio 2026 con compute e storage completamente disaccoppiati, scale-to-zero, e un autoscaling che AWS descrive come venti volte più rapido della generazione precedente. AWS dichiara risparmi fino al 60 percento rispetto al provisioning di un cluster per il carico di picco. Se il tuo workload è a raffiche, e il retrieval agentico è estremamente a raffiche, il vecchio argomento del pavimento non vale più nella forma in cui l'avevo formulato.

Cosa si rompe ancora: è un sistema distribuito con shard, repliche e uno stato di cluster, e prima o poi ti chiederà di pensare a tutti e tre. Il dimensionamento degli shard per workload vettoriali non è lo stesso dei log. E un rebuild è un reindex, il che significa pianificare capacità per due copie dell'indice.

S3 Vectors: un tier di storage che risponde alle query, non un tier di serving

S3 Vectors ha raggiunto la general availability il 2 dicembre 2025 a quaranta volte la scala della preview: fino a due miliardi di vettori per indice e diecimila indici per vector bucket, con diciassette regioni aggiunte a marzo 2026. AWS colloca la riduzione di costo rispetto a gestire un vector database fino al 90 percento, e la ragione è strutturale, non promozionale: non c'è cluster, non c'è compute provisionato, non c'è costo a vuoto.

Il numero che decide se fa al caso tuo è il profilo di latenza. AWS documenta query poco frequenti che tornano sotto il secondo, e query più frequenti attorno ai 100 millisecondi o meno. Leggilo come un effetto di cache calda, e poi sii onesto sul tuo traffico: un assistente di supporto interrogato quaranta volte l'ora non tiene caldo niente. Sotto il secondo va bene per un job di summarisation notturno ed è sbagliato per una chat interattiva dove il modello ha poi bisogno dei propri due secondi.

Dove è genuinamente la risposta giusta: tier vettoriali freddi o di archivio, indici per tenant dove i tenant sono tanti e il traffico di ciascuno è sparso, Bedrock Knowledge Bases orientate al costo con budget di latenza tolleranti, e ovunque l'alternativa fosse pagare un cluster inattivo. Si compone bene come secondo tier sotto uno store caldo, che è come lo userei io, piuttosto che come sostituzione in blocco.

Qdrant, Milvus, Pinecone: quando vince il payload

Lasci Postgres per un engine dedicato quando il workload vettoriale ha smesso di essere una feature della tua applicazione ed è diventato l'applicazione. Tre forme di questo:

Qdrant è quello da prendere quando il problema è il filtering. I suoi indici di payload e l'HNSW filtrabile sono progettati per il caso a cui la scansione iterativa di pgvector si limita a sopravvivere: filtri molto selettivi su ogni query, ad alta frequenza. Fornisce anche quantization scalare, product e binaria, che è il modo pratico di tenere un indice grande residente in memoria. Per uno store di memoria agenti multi-tenant con filtri per tenant a ogni lettura, questa è una ragione difendibile per gestire un altro database.

Milvus è la risposta alla scala del miliardo. L'indicizzazione su disco (DiskANN) significa che il working set non deve stare in RAM, ed è questo che cambia la bolletta hardware a quella dimensione. Il prezzo è operativo: è un sistema distribuito con ruoli separati di coordinator, query, data e index, e farlo girare in produzione è una decisione di organico prima che tecnica. Sotto qualche centinaio di milioni di vettori, quella complessità ti compra molto poco.

Pinecone è l'opzione compra-invece-di-costruire, e va valutata come si valuta qualsiasi SaaS: sul carico operativo che toglie, non sulla latenza. Il pricing serverless disaccoppia lo storage da letture e scritture senza costo a vuoto, il che si adatta ai workload a picchi e rende i deployment piccoli genuinamente economici. Quello a cui rinunci è il controllo sui failure mode, e ti prendi egress e accoppiamento al vendor. È anche uno store supportato da Bedrock Knowledge Bases, quindi non è un'uscita dal percorso RAG gestito da AWS.

La coda lunga, in breve

Weaviate è la cosa più vicina a uno store RAG con le batterie incluse: moduli di vettorizzazione integrati, ricerca ibrida e un modello schema-first. Attraente se vuoi opinioni già fornite, meno se hai già una pipeline di embedding. Chroma è uno strumento di prototipazione che lo ammette onestamente, e ogni deployment serio che ho visto alla fine ne è migrato via. Redis con la similarità vettoriale è eccellente quando i vettori sono effimeri, sessioni, memoria agenti a breve termine, cache semantiche, e pessimo come system of record. MongoDB Atlas Vector Search sta a Mongo come pgvector sta a Postgres: corretto se i tuoi documenti vivono già lì, e una pessima ragione per adottare Mongo se non ci vivono. Sia Redis Enterprise Cloud sia MongoDB Atlas sono store supportati da Bedrock Knowledge Bases.

La tabella di decisione

I trigger che significano davvero "lascia pgvector adesso"

Non la scala in astratto. Questi:

• Il tuo rebuild HNSW non sta più in una finestra di manutenzione accettabile, e hai già alzato maintenance_work_mem e usato worker paralleli.
• Il recall filtrato resta insufficiente anche dopo aver abilitato le scansioni iterative e regolato ef_search, perché i tuoi filtri sono così selettivi che il grafo è la struttura sbagliata.
• Il working set dell'indice supera la memoria dell'istanza e la taglia di istanza successiva costa più di quanto costerebbe un engine dedicato.
• La ricerca vettoriale sta affamando il tuo workload transazionale, e una read replica non è separazione sufficiente.
• Ti serve il ranking ibrido lessicale più vettoriale come query di prima classe invece che come due ricerche da fondere nel codice applicativo. Questo punta specificamente a OpenSearch.

Se nessuno di questi è vero, la migrazione che stai pianificando è una preferenza, non un requisito. Il team che consegna un layer di retrieval funzionante sul database che già gestisce, e si sposta solo quando uno di quei trigger scatta, arriva in produzione parecchio prima del team che ha passato il primo sprint a scegliere.

Il punto

Parti da pgvector, e conosci i suoi quattro tetti con precisione sufficiente da distinguere un limite reale dal folklore. Passa a OpenSearch quando ti serve la ricerca e non la similarità, e rifai il confronto dei costi contro l'offerta serverless di nuova generazione invece che contro il vecchio pavimento in OCU. Usa S3 Vectors come tier freddo e per indici per tenant sparsi, non come percorso di serving interattivo. Prendi Qdrant quando domina il filtering, Milvus oltre il punto in cui la RAM detta la bolletta, e Pinecone quando preferisci comprare le operazioni piuttosto che gestirle. Scegli in base alla rottura che colpirai per prima, perché è l'unica variabile di questo confronto che differisce in modo significativo tra gli engine.

Da leggere dopo

• Agent Memory Is a Database Problem, Not a Prompt Problem, sul perché il layer di storage decide cosa il tuo agente può ricordare.
• Knowledge Base Chunking Is Where Your RAG Quality Dies, sul problema di retrieval che nessun vector database risolve al posto tuo.

Per il lato infrastrutturale della gestione di Postgres e dei cluster di ricerca in produzione, gli appunti sul cloud vivono su ercan.cloud, e l'hub è su ercanermis.com.

Riferimenti

• pgvector on GitHub, vector types, index types, and dimension limits.
• pgvector 0.8.0 release announcement, iterative index scans and filtering improvements.
• The next generation of Amazon OpenSearch Serverless is now generally available, AWS What's New, 28 May 2026.
• Amazon S3 Vectors is now generally available with 40 times the scale of preview, AWS What's New, 2 December 2025.
• Working with S3 Vectors and vector buckets, Amazon S3 User Guide.
• Prerequisites for using a vector store you created for a knowledge base, Amazon Bedrock User Guide.
• Approximate k-NN search, OpenSearch documentation.
• Filtering, Qdrant documentation.
• DiskANN-based on-disk index, Milvus documentation.
• Pinecone pricing, serverless read unit, write unit, and storage model.