Database Vettoriali a Confronto 2026: Pinecone vs Qdrant vs Weaviate vs Milvus

Aggiornato: 11 Giugno 2026

Un database vettoriale è un sistema di archiviazione specializzato che indicizza embedding ad alta dimensionalità per ricerca semantica e RAG. Nel 2026 le quattro scelte dominanti sono Pinecone (managed serverless), Qdrant (Rust, ottimo rapporto prezzo/prestazioni), Weaviate (named vectors e multi-tenancy nativa) e Milvus (scala miliardi di vettori con sharding distribuito). La scelta si gioca su tre assi: latenza p99, costo per milione di vettori e quanto controllo operativo vuoi cedere.

Onestamente, dopo aver portato in produzione una mezza dozzina di sistemi RAG nell'ultimo anno, posso dirti che la decisione "giusta" cambia parecchio in base al carico e al team. Questa guida confronta i quattro database su benchmark reali, prezzi aggiornati al 2026 e pattern di integrazione veri (non i soliti hello-world).

• Pinecone serverless è la scelta più semplice per chi vuole zero ops, ma il prezzo per query scala male oltre i 10M vettori con alta frequenza.
• Qdrant offre il miglior rapporto prezzo/prestazioni nel 2026 grazie al motore in Rust e alla quantizzazione binaria che riduce la memoria fino all'80%.
• Weaviate vince quando servono named vectors (più embedding per documento) o multi-tenancy SaaS con migliaia di tenant isolati.
• Milvus 2.4+ è imbattibile sopra il miliardo di vettori grazie all'architettura distribuita e al supporto GPU per indicizzazione.
• Hybrid search (dense + sparse BM25/SPLADE) è ormai tabella di marcia: Qdrant e Weaviate lo offrono nativamente, Pinecone via sparse-dense vectors.
• Per progetti sotto i 5M di vettori e budget limitato, pgvector su PostgreSQL gestito resta competitivo.

Tabella di confronto rapido

Caratteristica	Pinecone	Qdrant	Weaviate	Milvus
Modello deploy	Solo managed (serverless)	Self-hosted + Cloud	Self-hosted + Cloud	Self-hosted + Zilliz
Linguaggio core	Rust (proprietario)	Rust (open source)	Go (open source)	C++/Go (open source)
Indice ANN	Proprietario (graph)	HNSW + quantizzazione	HNSW + flat + dynamic	HNSW, IVF, DiskANN, GPU
Hybrid search	Sparse-dense vectors	Nativo (BM25, SPLADE)	Nativo (BM25F)	Sparse vector 2.4+
Multi-tenancy	Namespaces	Collections + payload	Tenant nativo (migliaia)	Database + partitions
Filtering metadata	Buono	Eccellente (indici payload)	Buono	Buono
Costo a 10M vettori/mese	~$280 (s1.x1)	~$90 self-host / $150 cloud	~$120 cloud	~$200 Zilliz / $50 self-host
Latenza p99 tipica	30–80 ms	15–50 ms	25–70 ms	20–60 ms

I prezzi sono stime indicative per cluster con embedding a 1536 dimensioni, ~50 QPS sostenuti, replica singola; consulta i listini ufficiali per il calcolo esatto. Le latenze sono valori che vedo regolarmente in produzione con dataset bilanciati e HNSW configurato per recall ≥ 0.95.

Come funziona un database vettoriale

Un database vettoriale memorizza array di numeri in virgola mobile (gli embedding) prodotti da un modello come text-embedding-3-large di OpenAI o voyage-3 di Voyage AI. Ogni vettore tipicamente ha tra 384 e 3072 dimensioni e rappresenta il significato semantico di un testo, immagine o audio. La ricerca non confronta uno-a-uno (sarebbe O(n) sul dataset), ma usa un Approximate Nearest Neighbor (ANN) come HNSW (Hierarchical Navigable Small World) per trovare i k vettori più simili in tempo sub-lineare.

Le tre operazioni che ogni vector DB deve gestire bene sono: upsert (inserimento idempotente con ID), search con filtro su metadata, e delete per garbage collection di documenti obsoleti. La metrica più usata resta la cosine similarity, ma per embedding già normalizzati il dot product è matematicamente equivalente e leggermente più veloce. La documentazione introduttiva di Pinecone contiene un'ottima spiegazione visiva del concetto se vuoi approfondire i fondamentali.

Indici ANN: HNSW, IVF e quantizzazione

HNSW costruisce un grafo gerarchico di vettori dove i nodi superiori sono "hub" che indirizzano la ricerca verso cluster densi più in basso. È lo standard de facto per dataset fino a ~100M vettori. Sopra quella soglia, IVF (Inverted File) o DiskANN (sviluppato da Microsoft) vincono perché tengono solo l'indice in RAM mentre i vettori restano su SSD. La quantizzazione (scalare a int8, prodotto, o binaria) riduce la memoria di 4x–32x con una perdita di recall accettabile (1–3%) se l'embedding è ben distribuito.

Pinecone nel 2026: serverless e Assistant

Pinecone resta il database vettoriale più maturo come esperienza managed. Nel 2026 l'offerta serverless è GA da oltre un anno, fatturata per storage (~$0.33/GB-mese) più read units e write units. Il vantaggio principale è che non gestisci nodi, repliche o sharding: scali da zero a centinaia di milioni di vettori senza toccare la configurazione. Il punto debole è il costo a frequenza alta: oltre i 50 QPS sostenuti, l'opzione p1 o s1 dedicata torna più conveniente del serverless.

Pinecone Assistant (lanciato fine 2025) sposta il database verso un'esperienza più "RAG-as-a-Service": tu carichi i documenti, lui gestisce chunking, embedding e retrieval. Utile per prototipi, ma in produzione perdi il controllo sul chunking che è proprio dove si gioca la qualità del recall. Per architetture serie sui pattern di ingestion ti rimando alla nostra guida sulle pipeline RAG di produzione.

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="YOUR_KEY")

pc.create_index(
    name="docs-2026",
    dimension=1536,
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="us-east-1"),
)
index = pc.Index("docs-2026")

# Upsert con metadata e namespace
index.upsert(
    vectors=[
        {"id": "doc-1", "values": embedding,
         "metadata": {"lang": "it", "category": "rag"}}
    ],
    namespace="tenant-acme",
)

# Query con filtro metadata
res = index.query(
    vector=query_embedding,
    top_k=5,
    namespace="tenant-acme",
    filter={"lang": {"$eq": "it"}},
    include_metadata=True,
)

Qdrant: il vincitore prezzo/prestazioni

Qdrant è il database vettoriale che più frequentemente raccomando ai clienti nel 2026, specialmente quando il budget è un vincolo reale. Scritto in Rust, gira benissimo in self-hosted su una VM da 16GB (gestisce comodamente 5–10 milioni di vettori con quantizzazione scalare attiva). La quantizzazione binaria introdotta nella 1.10 è particolarmente efficace: riduce la memoria di 32x e su embedding OpenAI mantiene un recall del 95%+ con re-scoring sui top-100 candidati.

Il sistema di filtri di Qdrant è il più potente del lotto. Puoi creare indici dedicati su campi del payload (stringhe, numeri, geo, booleani) e Qdrant li usa prima della ricerca ANN, evitando il classico problema del "post-filtering" che svuota i risultati quando hai filtri selettivi. Questo è cruciale per casi d'uso multi-tenant o filtri temporali stretti. Le note sull'indicizzazione nella documentazione ufficiale spiegano i dettagli operativi.

from qdrant_client import QdrantClient
from qdrant_client.http.models import (
    Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue
)

client = QdrantClient(url="http://localhost:6333")

client.create_collection(
    collection_name="docs",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

# Indice payload per filtering veloce
client.create_payload_index(
    collection_name="docs",
    field_name="tenant_id",
    field_schema="keyword",
)

client.upsert(
    collection_name="docs",
    points=[
        PointStruct(
            id=1, vector=embedding,
            payload={"tenant_id": "acme", "lang": "it"},
        )
    ],
)

# Filtered search (pre-filtering nativo)
hits = client.search(
    collection_name="docs",
    query_vector=query_embedding,
    query_filter=Filter(
        must=[FieldCondition(key="tenant_id", match=MatchValue(value="acme"))]
    ),
    limit=5,
)

Weaviate: named vectors e multi-tenancy

Weaviate ha due feature che gli altri non hanno con la stessa maturità: i named vectors e la multi-tenancy nativa. Con i named vectors un singolo oggetto può avere più embedding indipendenti (es. uno per il titolo, uno per il corpo, uno per le immagini) e tu interroghi quello che ti serve a runtime. È la soluzione più pulita per ricerca multi-modale o per A/B test fra modelli di embedding diversi sugli stessi documenti.

La multi-tenancy di Weaviate è progettata per SaaS che servono migliaia di tenant: ogni tenant ha indici fisicamente separati, può essere "hot" (in RAM), "warm" (su disco), o "cold" (offload completo), e si attiva/disattiva con una API call. In ambienti dove il 90% dei tenant è inattivo il 90% del tempo, questo risparmia memoria in modo drammatico. Per la parte di valutazione del retrieval, vale la pena combinare Weaviate con framework di osservabilità LLM come Langfuse per tracciare query, latenze e qualità nel tempo.

import weaviate
from weaviate.classes.config import Configure, Property, DataType

client = weaviate.connect_to_local()

client.collections.create(
    name="Document",
    multi_tenancy_config=Configure.multi_tenancy(enabled=True),
    vectorizer_config=[
        Configure.NamedVectors.text2vec_openai(
            name="title_vec", source_properties=["title"]),
        Configure.NamedVectors.text2vec_openai(
            name="body_vec", source_properties=["body"]),
    ],
    properties=[
        Property(name="title", data_type=DataType.TEXT),
        Property(name="body", data_type=DataType.TEXT),
    ],
)

docs = client.collections.get("Document").with_tenant("acme")
docs.data.insert({"title": "RAG in produzione", "body": "..."})

# Query specifica per named vector
res = docs.query.near_text(
    query="pipeline RAG",
    target_vector="body_vec",
    limit=5,
)

Milvus: scala a miliardi di vettori

Milvus è la scelta quando il dataset supera il miliardo di vettori o quando serve indicizzazione su GPU. L'architettura distribuita separa nettamente i ruoli (proxy, query node, data node, index node) e ogni componente scala orizzontalmente in modo indipendente. Su Zilliz Cloud (il managed ufficiale dei creatori) ho visto cluster gestire 5 miliardi di vettori con p99 sotto i 100ms, scenario impensabile per Pinecone o Qdrant senza sharding manuale.

Il prezzo della scala è la complessità operativa: Milvus self-hosted richiede etcd, Pulsar/Kafka, MinIO/S3 e una buona dose di tuning. Per dataset sotto i 100M vettori è oggettivamente over-engineered. La 2.4 ha introdotto il supporto sparse vector per hybrid search e DiskANN che permette di tenere i vettori su SSD NVMe abbassando il costo RAM. Le release notes ufficiali di Milvus documentano tutte le novità per versione.

Hybrid search: dense + sparse

Sinceramente, nel 2026 la ricerca puramente densa (solo embedding semantici) è considerata insufficiente per la maggior parte dei casi RAG in produzione. Le query con nomi propri, codici prodotto, acronimi o termini rari falliscono perché l'embedding "diluisce" il segnale lessicale. La soluzione è hybrid search: combinare similarità densa con un punteggio sparse (BM25 o SPLADE) e fondere i risultati con Reciprocal Rank Fusion (RRF) o weighted sum.

Qdrant e Weaviate supportano hybrid nativamente da oltre un anno. Pinecone richiede di inviare due vettori (uno denso, uno sparse generato lato client con un modello come SPLADE-v3). Milvus 2.4+ supporta vettori sparse come tipo first-class. In benchmark interni, l'hybrid search migliora il recall@10 del 15–25% rispetto al solo denso su corpora tecnici o domain-specific.

# Esempio hybrid search con Qdrant
from qdrant_client.http.models import (
    SparseVector, Prefetch, FusionQuery, Fusion
)

results = client.query_points(
    collection_name="docs",
    prefetch=[
        Prefetch(query=dense_vector, using="dense", limit=20),
        Prefetch(query=SparseVector(indices=ids, values=vals),
                 using="sparse", limit=20),
    ],
    query=FusionQuery(fusion=Fusion.RRF),
    limit=10,
)

Quale database vettoriale scegliere nel 2026

La risposta breve, basata su decine di progetti che ho visto andare in produzione: parti da Qdrant self-hosted se hai un team che sa gestire Docker e un PostgreSQL. Passa a Pinecone serverless se vuoi zero operations e il tuo dataset cresce in modo imprevedibile. Scegli Weaviate se la tua app è multi-tenant SaaS con isolamento per cliente. Considera Milvus/Zilliz solo sopra i 500M vettori o con requisiti GPU. Per dataset sotto i 5M vettori, pgvector su Supabase o RDS è ancora una scelta sensata e ti evita un sistema in più.

Checklist di valutazione concreta

1. Dimensione del dataset oggi e a 12 mesi. Se sopra 100M vettori, scarta Pinecone serverless per costo e considera Milvus o Qdrant cluster.
2. Frequenza di query. Sopra 100 QPS sostenuti, valuta deployment dedicato in tutti i casi.
3. Multi-tenancy. Se hai >100 tenant, Weaviate è la soluzione meno dolorosa.
4. Hybrid search. Se serve dal day-one, Qdrant o Weaviate; con Pinecone aggiungi complessità lato client.
5. Compliance e residenza dati. Self-hosted obbligatorio? Esce Pinecone (managed only).
6. Skill team. Senza esperienza Kubernetes, evita Milvus self-hosted.

Integrazione in una pipeline RAG

Indipendentemente dal database scelto, il pattern di integrazione in una pipeline RAG segue gli stessi passi: ingest (chunking + embedding + upsert), retrieval (query embedding + ANN search + re-ranking opzionale), e generation (LLM con contesto recuperato). Il vector DB è solo lo strato di retrieval; la qualità finale dipende molto di più dal chunking, dal modello di embedding e dal prompt template. Per pattern di orchestrazione e tool-use, dai un'occhiata alla guida sugli agenti IA con LangGraph e CrewAI.

Un consiglio operativo: tieni l'astrazione del vector store sottile. LangChain e LlamaIndex offrono interfacce uniformi (VectorStore, BaseRetriever) che permettono di switchare il backend con poche righe. Questo è importante perché lo spazio si muove velocemente e il database "migliore" oggi potrebbe non esserlo fra 18 mesi.

Domande frequenti

Qual è il miglior database vettoriale nel 2026?

Non esiste un singolo "migliore". Per managed semplice scegli Pinecone, per il miglior rapporto prezzo/prestazioni Qdrant, per multi-tenancy SaaS Weaviate, per scala miliardaria Milvus. La maggior parte dei progetti sotto i 50M vettori sta benissimo con Qdrant.

Pinecone vs Qdrant: quale costa meno?

Qdrant self-hosted è quasi sempre più economico (~60–70% in meno) per workload sostenuti. Pinecone serverless vince solo se hai traffico molto variabile e poche query: paghi quasi zero quando l'app è inattiva.

I database vettoriali sono open source?

Qdrant, Weaviate, Milvus e Chroma sono open source (Apache 2.0 o BSL). Pinecone è completamente proprietario e solo managed. pgvector è un'estensione open source di PostgreSQL ed è una buona porta d'ingresso al vector search.

Posso usare PostgreSQL come database vettoriale?

Sì, con l'estensione pgvector (e pgvectorscale per indici ottimizzati). Funziona bene fino a circa 5–10 milioni di vettori. Oltre quella soglia la latenza p99 degrada e conviene migrare a un database vettoriale dedicato.

Come si confrontano le prestazioni dei database vettoriali?

I benchmark più affidabili sono ann-benchmarks (open source) e quelli pubblicati da Qdrant. Misura sempre recall@k e latenza p99 sul TUO dataset e con il TUO modello di embedding: la distribuzione dei vettori cambia drasticamente le performance reali rispetto a benchmark sintetici.