Costo di un database vettoriale: cosa si paga davvero

Il costo di un database vettoriale non è un semplice prezzo di listino. Quello che si paga davvero è memoria e spazio di archiviazione (in base a quanti vettori si conservano e quante dimensioni ha ciascuno), potenza di calcolo per query e indicizzazione, e tante copie quante sono le repliche. A questo si aggiungono costi che in fattura non compaiono: la generazione degli embedding, la reindicizzazione completa a ogni cambio di modello e il tempo degli sviluppatori. Questa guida analizza ogni voce, mostra come stimare la memoria con un calcolo elementare e La aiuta a capire se un database vettoriale Le serve.

Che cosa contiene davvero un database vettoriale

Un database vettoriale archivia embedding: sequenze di numeri che rappresentano il significato di un brano di testo. Ogni documento viene suddiviso in frammenti (chunk) e ogni frammento riceve il proprio vettore. Quando qualcuno pone una domanda, anche la domanda diventa un vettore e si cercano i frammenti più vicini. Per seguire l'intero percorso con un esempio concreto, legga Come funziona il RAG, passo dopo passo.

Prima lezione per il budget: non si paga a documento, ma a vettore. Un PDF di 50 pagine può diventare 50 vettori oppure 500, a seconda della dimensione dei frammenti e della sovrapposizione. Questa scelta, spesso fatta una volta e poi dimenticata, può spostare la spesa di un ordine di grandezza.

Le quattro leve del costo

Che si ospiti un motore open source, si aggiunga un'estensione a PostgreSQL o si usi un servizio gestito, sotto ci sono sempre le stesse risorse fisiche. I fornitori le fatturano in modi diversi (a ora, a gigabyte, a unità di lettura), ma le leve restano queste quattro.

1. Numero di vettori

Conti i frammenti, non i file, e preveda la crescita: se l'archivio documentale raddoppia in un anno, raddoppia anche l'indice.

2. Dimensioni e precisione

Il modello di embedding stabilisce il numero di dimensioni; 384, 768, 1.024, 1.536 e 3.072 sono valori comuni. In float32 ogni dimensione occupa 4 byte: un vettore da 1.536 dimensioni pesa quindi circa 6 KB, indice escluso.

3. Volume di query e latenza

Gli indici di ricerca approssimata dei vicini più prossimi, come i grafi HNSW descritti nell'articolo originale, sono veloci perché percorrono un grafo invece di confrontare tutto. Per restare veloci, di norma il grafo deve stare in RAM. Più query al secondo, latenze più strette e filtri sui metadati richiedono più memoria e CPU.

4. Repliche, ambienti e clienti

In produzione si usano in genere due o tre repliche, ognuna con l'indice completo. Aggiungendo un ambiente di test, e magari un indice per cliente per separare i dati, gli stessi vettori si pagano più volte.

Stimare il costo di archiviazione degli embedding

Per stimare la memoria non serve un listino. La formula è: numero di vettori × dimensioni × 4 byte (in float32). I valori seguenti sono dimensioni grezze, senza indice, metadati né repliche.

Esempio: 1.000.000 × 1.536 × 4 = 6.144.000.000 byte, cioè circa 6,1 GB. È solo il punto di partenza. L'indice a grafo memorizza i collegamenti ai vicini di ogni vettore, di solito si conservano anche il testo dei frammenti e i metadati, e il totale va moltiplicato per il numero di repliche. Un archivio che sembrava stare in 6 GB arriva presto a qualche decina di gigabyte di RAM sul cluster.

I costi nascosti: embedding, reindicizzazione e persone

• Generare gli embedding. Ogni frammento passa da un modello di embedding all'importazione, e ogni domanda viene vettorizzata al momento della ricerca. Che si usi un'API o le proprie GPU, è un costo ricorrente.
• Reindicizzare al cambio di modello. I vettori di due modelli diversi non sono confrontabili. Cambiare modello, o anche solo dimensione, significa ricalcolare tutto e ricostruire l'indice, spesso tenendo in servizio quello vecchio durante il passaggio.
• Rifare la suddivisione. Se le risposte sono deboli e si cambia strategia di chunking, si rivettorizza tutto l'archivio. Nei primi mesi succede più di una volta.
• Aggiornamenti e cancellazioni. Tenere i vettori allineati ai documenti richiede una pipeline, e alcuni indici peggiorano dopo molte cancellazioni finché non vengono ricostruiti.
• Backup e trasferimenti. Snapshot e copie tra regioni aggiungono spazio e costi di uscita dei dati.
• Gestione operativa. Taratura dei parametri, controllo della qualità, aggiornamenti e reperibilità hanno bisogno di un responsabile.

C'è poi la conformità. Ai sensi del GDPR, gli embedding calcolati da testi che contengono dati personali, e conservati accanto a quei testi, vanno trattati come dati personali: controllo degli accessi, tempi di conservazione, registro dei trattamenti e luogo di hosting. Il Garante Privacy pubblica indicazioni utili, e l'AI Act aggiunge obblighi propri a seconda dell'uso del sistema.

Quando un database vettoriale non serve

• L'archivio è piccolo. Qualche migliaio di frammenti sta comodamente in memoria e un confronto completo è abbastanza veloce.
• Le domande riguardano termini esatti. Articoli di legge, codici prodotto, codici di errore e nomi propri si trovano spesso meglio con la ricerca full text. Una ricerca ibrida, che unisce parole chiave e significato, batte spesso i soli vettori.
• Usa già PostgreSQL. Un'estensione vettoriale tiene gli embedding accanto ai dati relazionali, con un'unica politica di backup e permessi.
• Vuole risposte, non infrastruttura. Se l'obiettivo è far interrogare i documenti al personale o agli assistenti IA, un servizio gestito elimina database, pipeline di embedding e reindicizzazione.

Quest'ultimo caso è quello di Kopik, una piattaforma di RAG as a service pensata anche per le PMI. Creare una base è gratuito: si caricano file PDF, Word, testo o Markdown, e Kopik li estrae, li suddivide e li indicizza per una ricerca ibrida (full text più ampliamento semantico delle parole chiave). Nessun cluster da dimensionare né dimensioni da scegliere: le domande si pagano con crediti prepagati o con l'abbonamento chat a 12 € al mese con indicatore di consumo. Se vuole che sia Claude a consultare quei documenti, legga come dare a Claude l'accesso ai documenti aziendali.

Checklist prima di confrontare i fornitori

1. Conti i frammenti di oggi e li stimi a 12 mesi.
2. Scelga la dimensione degli embedding e calcoli vettori × dimensioni × 4 byte.
3. Provi la quantizzazione su 50-100 domande reali.
4. Fissi il numero di repliche e di ambienti (produzione, test, per cliente).
5. Stimi le query giornaliere e il picco al secondo, inclusi gli agenti IA che cercano più volte.
6. Metta a budget gli embedding per il caricamento iniziale, gli aggiornamenti e almeno una reindicizzazione completa all'anno.
7. Verifichi dove sono ospitati i dati (UE o no), la cifratura e i log di audit di ogni piano.
8. Quantifichi il tempo che il Suo team dedicherà alla manutenzione.