Amazon S3 Vectors ucciderà i database vettoriali—o li salverà?
Non molto tempo fa, AWS ha lanciato qualcosa di nuovo: S3 Vectors. È il loro primo tentativo di una soluzione di archiviazione vettoriale, che consente di archiviare e interrogare embedding vettoriali per la ricerca semantica direttamente all’interno di Amazon S3.
A prima vista, sembra un database vettoriale leggero in esecuzione sopra uno storage a oggetti a basso costo—a un prezzo chiaramente interessante rispetto a molte soluzioni di database vettoriali dedicate.
amazon s3 vectors.png
Naturalmente, questo ha scatenato molte opinioni forti. Ho visto persone sui social media e nei circoli di ingegneria dire che questo potrebbe essere la fine dei database vettoriali purpose-built—Milvus, Pinecone, Qdrant e altri inclusi. Un’affermazione audace, no?
In qualità di architetto ingegneristico di Milvus e di persona che ha passato fin troppe notti in bianco a pensare alla ricerca vettoriale, devo ammettere che: S3 Vectors porta qualcosa di interessante sul tavolo, soprattutto per quanto riguarda costi e integrazione all’interno dell’ecosistema AWS. Ma invece di “uccidere” i database vettoriali, lo vedo inserirsi nell’ecosistema come un componente complementare. In effetti, il suo vero futuro probabilmente sta nel lavorare con database vettoriali professionali, non nel sostituirli.
In questo post, ti spiegherò perché la penso così—analizzandolo da tre angolazioni: la tecnologia in sé, cosa può e non può fare, e cosa significa per il mercato.
Un fatto sorprendente: l’archiviazione vettoriale può costare più delle chiamate agli LLM
La ricerca vettoriale è potente, ma porta con sé un problema serio: è costosa. Le esigenze computazionali sono spesso da uno a due ordini di grandezza superiori a quelle che vedresti in un tipico database NoSQL. Quel divario non è solo teorico—si manifesta nelle fatture reali.
Di recente ho parlato con il CTO di una popolare app AI per prendere appunti, che mi ha detto qualcosa di sorprendente: spendono il doppio di quanto spendono per la ricerca vettoriale rispetto alle chiamate API di OpenAI. Pensaci un secondo. Gestire il livello di retrieval costa loro più che pagare per l’LLM stesso. Questo ribalta completamente l’ipotesi abituale.
Il boom di ChatGPT del 2022 ha reso tutto questo ancora più evidente. All’improvviso, gli embedding erano ovunque e i dati vettoriali sono diventati il tipo di dati in più rapida crescita sul cloud pubblico. Retrieval-Augmented Generation (RAG) è stato il motore—e con esso sono arrivate tre sfide che hanno ridefinito ciò che un database vettoriale come Milvus doveva fare:
Esplosione massiccia dei dati: I workload sono passati da decine di milioni a decine di miliardi di vettori quasi da un giorno all’altro. Non è una crescita lineare—è un salto quantico, e ha mandato in crisi i vecchi modi di gestire i dati.
La tolleranza alla latenza è cambiata: Poiché gli LLM impiegano comunque tempo per generare risposte, gli utenti sono diventati più tolleranti verso retrieval leggermente più lenti. La mentalità del “recall sotto i 10 ms a tutti i costi” è diventata improvvisamente meno importante.
La sensibilità ai costi è aumentata alle stelle: Raddoppiare o triplicare il volume dei dati non era solo un problema di storage; diventava una crisi finanziaria se si cercava di scalare usando design tradizionali ad alta intensità di calcolo.
In breve: i database vettoriali hanno dovuto evolversi rapidamente, non perché la tecnologia non funzionasse, ma perché l’economia del retrieval è diventata improvvisamente centrale.
L’evoluzione dell’archiviazione vettoriale: dalla memoria al disco, e ora allo storage a oggetti
La pressione su costi e scala ha portato a una conclusione: i database vettoriali non potevano restare solo in memoria per sempre. Dovevano evolversi—prima verso il disco, e ora verso lo storage a oggetti come S3. Non è stata una scelta; era un’inevitabilità del settore. E se hai seguito questo ambito, probabilmente hai notato la stessa tendenza che ho visto io negli ultimi anni.
Ho visto i database vettoriali attraversare tre fasi distinte:
Fase I (2018–2022): l’era della memoria pura: Nei primi giorni di Milvus, ci affidavamo a indici in memoria come HNSW e IVF. Le prestazioni e il recall erano fantastici, ma i costi erano brutali. La memoria non scala a basso costo, e chiunque pagasse quelle bollette cloud lo sapeva.
Fase II (2022–2024): la rivoluzione degli indici su disco: Per superare il collo di bottiglia della memoria, abbiamo introdotto un approccio basato su disco utilizzando DiskANN insieme al nostro indice proprietario Cardinal (esclusivo di Zilliz Cloud, il Milvus gestito). Con accorgimenti come l’I/O asincrono (AIO) e io_uring, siamo riusciti a ottenere prestazioni reali dai dischi. Il risultato? Una riduzione dei costi di 3–5 volte. Le nostre compute unit (CU) ottimizzate per la capacità sono rapidamente diventate bestseller in Zilliz Cloud.
Fase III (2024– ): l’era dello storage a livelli: Il passo successivo era ovvio: spostare gli indici vettoriali su storage a oggetti economico. Nuovi attori come TurboPuffer hanno puntato tutto su S3, abbassando i costi di storage a circa ~$0,33/GB/mese: una riduzione di 10 volte. Ma il compromesso era altrettanto chiaro: latenza delle query a freddo nell’intervallo 500 ms–1 s e precisione di recall più debole.
In Zilliz, lavoriamo da tempo sullo storage a livelli, ma abbiamo rimandato il rilascio finché non fossimo riusciti a domare le prestazioni delle query a freddo. Il mese prossimo lanceremo le nostre CU aggiornate a capacità estesa con vera separazione hot/cold in Zilliz Cloud. Ciò significa latenza stabile delle query a freddo sotto i 500 ms, abbinata a QPS ultra-elevati per le query a caldo. In altre parole, il meglio di entrambi i mondi.
Amazon S3 Vectors arriva proprio al momento giusto
Con lo storage a livelli che ha già dimostrato il suo valore, non sorprende che AWS sia entrata in gioco con S3 Vectors. In effetti, il rilascio sembra un’estensione naturale di ciò che stava già accadendo in tutto il settore. Amazon stava ampliando il ruolo di S3 con funzionalità come S3 Tables, facendolo evolvere da “semplice storage a oggetti” a dorsale di storage a freddo multimodale. I vettori sono semplicemente la modalità successiva in questa evoluzione, e probabilmente non si fermerà lì. Grafi, dati chiave-valore e serie temporali potrebbero tutti seguire lo stesso percorso.
E Amazon porta sul tavolo tre vantaggi innegabili:
Costo inferiore: tra i prezzi di storage più bassi del settore.
Scala massiva: i pool di macchine di AWS possono assorbire quasi qualsiasi carico di query.
Architettura nativa per microservizi: perfettamente allineata al flusso di lavoro scrittura–costruzione–query dell’indicizzazione vettoriale.
Nel loro insieme, questi elementi danno a S3 Vectors le premesse per diventare una soluzione di storage a freddo per vettori a costo ultra-basso e altamente scalabile.
S3 Vectors è un vero killer dei prezzi, ma con limiti chiari
Non appena S3 Vectors è stato annunciato, il nostro team lo ha sottoposto a test completi. I risultati sono stati illuminanti: non solo in termini di quanto sia economico, ma anche di dove iniziano a comparire le crepe.
S3 Vectors è un vero killer dei prezzi
Non c’è modo di negarlo: S3 Vectors è incredibilmente conveniente.
Lo storage costa appena $0,06/GB, circa 5 volte meno della maggior parte delle soluzioni vettoriali serverless. Per un carico di lavoro rappresentativo, ad esempio 400 milioni di vettori più 10 milioni di query al mese, il conto arriva a circa $1.217/mese. Si tratta di una riduzione di oltre 10 volte rispetto ai database vettoriali tradizionali. Per carichi di lavoro a basso QPS e tolleranti alla latenza, è quasi imbattibile.
Ma le prestazioni hanno vincoli reali
Limiti di dimensione della raccolta: Ogni tabella S3 arriva a un massimo di 50M vettori e puoi creare solo fino a 10.000 tabelle.
Query cold: La latenza si attesta a ~500ms per 1M vettori e ~700ms per 10M vettori.
Query hot: La latenza rimane sotto i 200ms a 200 QPS, ma spingersi oltre quel tetto di 200 QPS è difficile.
Prestazioni di scrittura: Limitate a meno di 2MB/s. È di ordini di grandezza inferiore rispetto a Milvus (che gestisce GB/s), anche se, a suo merito, le scritture non degradano le prestazioni delle query. Traduzione: non è progettato per scenari con dataset grandi e che cambiano frequentemente.
Compromessi tra precisione e funzionalità
La questione della precisione è dove le cose si complicano. Il recall si aggira intorno all’85–90% e non hai leve per portarlo più in alto. Aggiungi filtri e il recall può scendere sotto il 50%. In un test in cui abbiamo eliminato il 50% dei dati, le query TopK chiedevano 20 risultati ma potevano restituirne solo 15.
Anche la funzionalità è ridotta all’essenziale. Le query TopK arrivano al massimo a 30. I metadati per record hanno limiti di dimensione rigorosi. E non troverai funzionalità come hybrid search, multi-tenancy o filtri avanzati, tutte indispensabili per molte applicazioni di produzione.
Analisi di S3 Vectors: l’architettura probabile
Dopo aver eseguito test e averli confrontati con pattern di progettazione AWS familiari, ci siamo fatti un’ipotesi piuttosto solida su come funzioni S3 Vectors sotto il cofano. Sebbene Amazon non abbia pubblicato tutti i dettagli, le caratteristiche prestazionali indicano cinque tecnologie fondamentali:
Indicizzazione dinamica SPFresh: Invece di ricostruire interi indici dopo ogni scrittura, S3 Vectors sembra aggiornare solo le parti interessate. Questo design mantiene bassi i costi di scrittura e alta la disponibilità, ma ha un prezzo: i tassi di recall calano di qualche punto percentuale dopo gli aggiornamenti.
Deep Quantization (PQ a 4 bit): Per ridurre l’overhead I/O di S3, gli embedding sono probabilmente compressi usando la quantizzazione di prodotto a 4 bit.
Il lato positivo: lo storage è economico e le query restano veloci.
Il lato negativo: il recall si appiattisce intorno a ~85% e non ci sono leve per gli sviluppatori per portarlo più in alto.
Meccanismo di post-filter: Il filtraggio sembra essere applicato dopo il recupero grossolano. Questo mantiene l’indice unificato e semplice, ma fatica con condizioni complesse. Nei nostri test, quando abbiamo eliminato il 50% dei dati, le query TopK che richiedevano 20 risultati ne hanno restituiti solo 15: segnali classici di una pipeline di post-filter. Questo suggerisce anche che Amazon si sia appoggiata molto a design di indici open-source esistenti invece di costruirne uno personalizzato da zero.
Caching multi-livello: Le query hot si comportano molto più velocemente, probabilmente grazie a una cache SSD/NVMe davanti a S3. Ma quando una query manca la cache, la latenza aumenta in modo significativo. Questo pattern si adatta a una gerarchia di cache multi-livello costruita per mascherare la lentezza intrinseca dell’object storage.
Scheduling distribuito su larga scala: AWS non ha certo carenza di pool di macchine. S3 Vectors sembra distribuire il carico di lavoro tra microservizi, mettendo in pipeline il flusso lettura → decompressione → ricerca. Il risultato è quello che abbiamo osservato nei test: una distribuzione della latenza notevolmente stabile, anche sotto carico intenso.
Dove si inserisce S3 Vectors: lo strumento giusto per lavori specifici
Dopo aver messo alla prova S3 Vectors, è chiaro che brilla in alcuni scenari e mostra limiti in altri. Come la maggior parte degli strumenti infrastrutturali, non è una soluzione valida per tutto: è lo strumento giusto per il lavoro giusto.
Dove funziona bene
Archiviazione di dati cold: Perfetto per archiviare dataset storici a cui si accede raramente. Se puoi convivere con tempi di query di 500ms+, i risparmi sui costi sono imbattibili.
Query RAG a basso QPS: Pensa a piccoli strumenti interni o chatbot che eseguono solo decine di query al giorno, restando sotto i 100 QPS. Per questi casi d’uso, la latenza non è un fattore decisivo.
Prototipazione a basso costo: Ottimo per progetti proof-of-concept in cui l’obiettivo è testare un’idea senza spendere molto in infrastruttura.
Dove fatica
Ricerca e raccomandazione ad alte prestazioni: Se la tua applicazione necessita di una latenza inferiore a 50 ms, S3 Vectors semplicemente non è progettato per questo.
Scritture ad alto volume o aggiornamenti frequenti: Le prestazioni degradano rapidamente e la precisione del recall cala sensibilmente in condizioni di elevato churn.
Carichi di query complessi: Non c’è supporto per la ricerca ibrida, le aggregazioni o altre funzionalità di query avanzate.
App di produzione multi-tenant: Con un limite rigido di 10.000 bucket, non è pensato per distribuzioni multi-tenant su larga scala.
In altre parole, S3 Vectors è eccellente per scenari cold, economici e a basso QPS, ma non è il motore che vorresti usare per alimentare un sistema di raccomandazione, un’app di ricerca in tempo reale o qualsiasi sistema di produzione su larga scala.
Il futuro è lo storage vettoriale a livelli
S3 Vectors non segna la fine dei database vettoriali: conferma qualcosa che molti di noi osservano da tempo: il futuro è lo storage a livelli. Invece di mantenere ogni vettore in costosa memoria o su disco veloce, i carichi di lavoro si distribuiranno naturalmente tra livelli hot, warm e cold in base alla frequenza di accesso e al tipo di latenza che l’applicazione può tollerare.
Ecco come appare in pratica:
Livello dati hot (<50 ms) – Qui vivono ricerca in tempo reale, raccomandazioni e annunci mirati. La latenza deve essere inferiore a 50 ms, il che significa che i database vettoriali specializzati restano l’opzione migliore. Sono ottimizzati sia per una velocità fulminea sia per un’elevata capacità di query.
Livello dati warm (50–500 ms) – Molte applicazioni basate su RAG e servizi condivisi multi-tenant rientrano qui. Questi carichi di lavoro non richiedono una latenza ultra-bassa, ma necessitano di prestazioni prevedibili a un costo inferiore. S3 Vectors e le istanze di storage a livelli di Milvus si collocano in questa fascia intermedia.
Livello dati cold (>500 ms) – Gli archivi storici e l’analisi offline non richiedono risposte in tempo reale, quindi una latenza nell’ordine delle centinaia di millisecondi è accettabile. Ciò che conta qui è l’efficienza dei costi su scala massiccia. È qui che soluzioni come S3 + Spark/Daft o il data lake vettoriale di Milvus brillano.
La suddivisione hot–warm–cold bilancia latenza, costo e scala in un modo che nessun singolo livello di storage può coprire da solo. È un modello che abbiamo già visto nei database relazionali, nei data warehouse e persino nelle CDN, e ora lo storage vettoriale sta seguendo la stessa traiettoria. Questa architettura a tre livelli si allinea anche strettamente alla roadmap che stiamo costruendo per Milvus e Zilliz Cloud.
1. Un’architettura di elaborazione online + offline unificata
Le applicazioni AI non vivono ordinatamente in mondi separati “online” e “offline”. In realtà, i dati si spostano costantemente tra i due. Ecco perché con il prossimo Milvus 3.0, introdurremo un data lake vettoriale, progettato per supportare sia il recupero in tempo reale sia l’elaborazione offline dallo stesso dataset.
In pratica, questo significa che un unico dataset può alimentare le tue query RAG e di ricerca live, fornendo al contempo input per analisi offline basate su Spark, ad esempio per curare i dati di training per gli LLM. Nessuna duplicazione, nessuna gestione di due pipeline diverse.
Introdurremo anche il formato StorageV2 per il data lake vettoriale, che porta l’economia a un altro livello:
Fino a 100 volte più economico per lo storage di dati cold.
Fino a 100 volte più veloce rispetto alle query Spark brute-force sui dati hot.
Il risultato è un sistema unificato che minimizza la ridondanza, mantiene i costi sotto controllo e rende il lavoro con i dati vettoriali molto meno doloroso.
2. Creare funzionalità di cui gli sviluppatori AI hanno davvero bisogno
Negli ultimi due anni, le applicazioni di IA si sono evolute rapidamente, e lo stesso è accaduto ai requisiti dell’infrastruttura che le supporta. In Zilliz, abbiamo fatto progredire Milvus di pari passo con queste esigenze, rilasciando funzionalità come la ricerca ibrida BM25 + vettoriale, l’isolamento multi-tenant, lo storage a livelli hot–cold e la deduplicazione MinHash, insieme a una lunga serie di miglioramenti pensati per gli sviluppatori.
La nostra filosofia è stata semplice: quando combini una profonda comprensione dei casi d’uso aziendali con la tecnologia più recente, sblocchi possibilità infrastrutturali completamente nuove. È questa la mentalità che sta plasmando Milvus 3.0, che porterà una nuova ondata di funzionalità AI-native progettate direttamente per applicazioni reali. Tra queste:
Ponderazione delle parole chiave nella ricerca – Così una query come “telefono rosso” può dare la giusta priorità a rosso.
Supporto alla geolocalizzazione – Archivia e interroga vettori sensibili alla posizione per gestire prompt come “trova caffetterie nelle vicinanze.”
Supporto multi-vettore per RAG – Associa più embedding a ciascun testo, migliorando recall e accuratezza nelle attività di recupero complesse.
Elaborazione UDF flessibile – Funzioni definite dall’utente per un’elaborazione dei dati più ricca e personalizzabile.
Strumenti di analisi visiva – Mining offline e esplorazione dei dati più approfonditi su larga scala.
E questo è solo l’inizio. Il punto più importante è che Milvus si sta evolvendo in un sistema non solo efficiente e scalabile, ma AI-native nel suo nucleo—costruito appositamente per il modo in cui funzionano davvero le applicazioni moderne.
3. Ingegnerizzare per la scala senza il prezzo elevato
In Zilliz, crediamo che: una riduzione dei costi di 10 volte apra la porta a 100 volte più casi d’uso applicativi. Questo principio ha guidato ogni grande traguardo di Milvus. Dal 2022, abbiamo introdotto indici basati su disco, accelerazione GPU e quantizzazione RabitQ—tutti elementi che hanno aumentato le prestazioni delle query di ordini di grandezza, riducendo al contempo i costi.
Guardando al futuro, il nostro obiettivo è estrarre ancora più efficienza dallo stack:
Ottimizzazione hardware più profonda – Ottimizzazione per la potenza di calcolo grezza e le prestazioni IOPS.
Compressione e quantizzazione più intelligenti – Rendere i vettori più leggeri senza rinunciare all’accuratezza.
Terminazione anticipata per le query sugli indici – Interrompere il calcolo sprecato non appena abbiamo risultati affidabili.
Indicizzazione a livelli perfezionata – Migliore utilizzo della cache per un accesso più rapido ai dati freddi.
L’obiettivo finale non è cambiato: costruire un’infrastruttura che funzioni subito, scali on demand e rimanga al tempo stesso veloce e conveniente.
Perché l’arrivo di S3 Vectors è una buona notizia per tutti
Molte persone temono che S3 Vectors renda obsoleti i database vettoriali tradizionali. La mia opinione è l’opposto: il suo rilascio è una buona notizia per l’intero settore. In effetti, vedo tre grandi vantaggi.
Convalida la domanda. Nessuno può più sostenere che i vettori siano solo una moda passeggera. Se AWS sta costruendo un prodotto attorno a questo, è la prova positiva che l’archiviazione vettoriale è una necessità reale, non solo “indici racchiusi in un database.”
Educa il mercato. Con la portata di AWS, ora più imprese sono consapevoli dei database vettoriali, il che amplia i confini di ciò che le applicazioni possono realizzare.
Stimola l’innovazione. La concorrenza spinge tutti noi, Milvus incluso, a ottimizzare di più, ridurre ulteriormente i costi e trovare punti di forza differenziati.
Dal punto di vista del posizionamento, S3 Vectors assomiglia meno a un database vettoriale completo e più al livello freddo dell’archiviazione vettoriale. Il suo basso costo lo rende particolarmente interessante per scenari che in precedenza erano fuori budget: piccoli team che creano app RAG, singoli sviluppatori che sperimentano, o organizzazioni che indicizzano enormi dataset con esigenze di recupero solo di base. È un vero sblocco per l’ecosistema.
Personalmente, voglio anche riconoscere il lavoro del team di ingegneria di AWS. Hanno migliorato costantemente la loro piattaforma, dal debugging di Lambda alle prestazioni di cold start, e S3 Vectors è un altro esempio di innovazione di prodotto ben ponderata. Sono sinceramente curioso di vedere cosa costruiranno gli sviluppatori ora che l’economia è così favorevole.
Quindi no, il mercato dei database vettoriali non viene sconvolto: sta maturando in un ecosistema a livelli in cui soluzioni diverse soddisfano diverse esigenze di prestazioni e costo. È positivo per le imprese, positivo per gli sviluppatori e positivo per l’intero stack dell’infrastruttura AI.
L’età dell’oro dei database vettoriali non è finita: è appena iniziata.
Continua a leggere
We spent 8 years making vector databases faster. Then we stopped.
Rarely queried embeddings still need to stay searchable. See how Vector Lakebase enables on-demand vector search without always-on compute costs.
Zilliz Cloud BYOC Now Available Across AWS, GCP, and Azure
Zilliz Cloud BYOC is now generally available on all three major clouds. Deploy fully managed vector search in your own AWS, GCP, or Azure account — your data never leaves your VPC.
Zilliz Cloud Enterprise Vector Search Powers High-Performance AI on AWS
Zilliz Cloud on AWS powers secure, scalable, ultra-fast vector search for enterprise AI apps, with BYOC, sub-10ms latency, and zero-DevOps simplicity.