🧙 Maestro Yoda Cap. 22 · Agenti, tool use, RAG

Puntata 239

Puntata 239 — Vector database: Pinecone, Weaviate, pgvector, Qdrant

Livello: 🧙 Maestro Yoda · Capitolo 22 · Agenti, tool use, RAG

I vector DB sono il “MongoDB del 2023” — partita una corsa all’oro, decine di startup, finanziamenti enormi, hype. Nel 2026 il polverone si è posato: rimangono tre o quattro nomi che valgono davvero, e Postgres si è preso una grossa fetta del mercato facendo finta di niente.

un magazzino enorme con scaffali tridimensionali infiniti. Ogni scaffale ha un numero che è un vettore (es. [0.31, -0.78, 0.12, …]). Un drone vola velocissimo cercando “gli scaffali più vicini” a una richiesta. Sotto: “k-NN su miliardi di punti, in millisecondi”

Cos’è un vector DB

Un database specializzato per memorizzare e interrogare vettori densi (embedding) ad alta dimensionalità (tipicamente 256-4096 dim).

L’operazione core è la k-Nearest Neighbors search:

“Dato un vettore query Q, trovami i k vettori in DB più simili a Q (per cosine similarity, dot product, o Euclidean distance).”

Naive su 10M vettori a 1024 dim: ~40 GB di RAM, ~10s per query. Inutilizzabile.

I vector DB usano indici approssimati (ANN — Approximate Nearest Neighbor) che ridanno il top-k in millisecondi, accettando un 5-10% di error rate. Algoritmi popolari:

  • HNSW (Hierarchical Navigable Small World): standard de facto, fast & accurate.
  • IVF (Inverted File Index): partiziona lo spazio, ottimo per dataset enormi.
  • PQ (Product Quantization): comprime i vettori per ridurre RAM.
  • DiskANN: ottimizzato per spillover su disco SSD.

Sotto il cofano usano librerie tipo FAISS (Meta), Annoy (Spotify), ScaNN (Google).

Le funzionalità che un vector DB serio offre

Oltre alla k-NN search:

  1. Metadata filtering: filtra per tag/attributi ({"user_id": 42, "lang": "it"}).
  2. Hybrid search: combina dense (vector) con sparse (BM25 keyword).
  3. CRUD vettoriale: insert, update, delete in real-time (non solo bulk indexing).
  4. Multi-tenancy: namespace o “collections” separate per cliente.
  5. Replication & sharding: production-grade availability.
  6. Authentication & RBAC: chi può leggere/scrivere cosa.
  7. Backup & restore: ovvio ma rilevante.
  8. Quantization built-in: scalar/binary quantization per ridurre footprint.
  9. Geospatial / payload search: per use case oltre il semantico puro.

I “playground vector DB” del 2023 spesso mancavano metà di queste. Le opzioni serie nel 2026 le hanno tutte.

Le opzioni serie 2026

Pinecone (managed cloud)

  • Tipo: SaaS managed, closed source.
  • Forza: zero ops, scale verso miliardi di vettori, API stabilissima.
  • Limite: vendor lock-in, costo elevato a scala.
  • Pricing: serverless ~$0.33/GB/mese + $0.05 per WCU/RCU; pod-based su request.
  • Quando: vuoi production-ready fuori dalla scatola, non vuoi gestire infra, hai budget.

Weaviate (managed + open source)

  • Tipo: open source (BSD-3), versione SaaS managed (Weaviate Cloud Services).
  • Forza: hybrid search nativa, modulare (vectorizer pluggabili), GraphQL-style API.
  • Limite: API un po’ verbosa, learning curve.
  • Pricing: open source gratis self-hosted; managed da $25/mese.
  • Quando: vuoi flessibilità + opzione di andare cloud.

Qdrant (managed + open source)

  • Tipo: open source (Apache 2.0), versione SaaS managed (Qdrant Cloud).
  • Forza: performance ottima, scritto in Rust, payload filtering forte, hybrid search.
  • Limite: community più piccola di Weaviate fino al 2024 (cresciuta forte 2025).
  • Pricing: open source gratis; managed da $25/mese (free tier 1 GB).
  • Quando: vuoi performance + open source + tooling moderno.

pgvector (Postgres extension)

  • Tipo: open source (PostgreSQL License), estensione di Postgres.
  • Forza: usi Postgres che hai già, transazionalità ACID, joini con altre tabelle relazionali, nessun nuovo servizio da gestire.
  • Limite: performance ok ma non al top per dataset enormi (>100M vettori).
  • Pricing: il costo del tuo Postgres.
  • Quando: hai già Postgres, dataset <50M vettori, ami semplicità. Nel 2026 è la scelta più popolare nelle startup pragmatiche.

Milvus (open source enterprise)

  • Tipo: open source (Apache 2.0), Zilliz Cloud managed.
  • Forza: scale a miliardi, distribuzione enterprise-grade.
  • Limite: deployment self-host complesso, overkill per piccoli use case.
  • Quando: hai dataset >100M vettori e team SRE.

Altri (cenni)

  • Chroma: lightweight, ottimo per prototipi locali, in-memory. Non scale enterprise.
  • LanceDB: serverless, file-based (S3 + Parquet), interessante per data lake.
  • Marqo, Vespa, Vald: nicchie specifiche.
  • Elasticsearch dense_vector: ES ha vettori da v8.0+. Se hai già ES, valuta.
  • MongoDB Atlas Vector Search: stessa logica se hai già Mongo.
  • Redis Search vector: per cache + retrieval ibrido.

La storia in 30 secondi (per contesto)

  • 2022: nascono i puri-play vector DB (Pinecone già esistente, Weaviate, Qdrant, Chroma). Boom dovuto a ChatGPT.
  • 2023: round di funding enormi. Pinecone valutata $750M, Weaviate $200M, Qdrant $50M.
  • 2024: Postgres si sveglia con pgvector che diventa production-ready. Molte startup migrano da Pinecone → pgvector per semplicità.
  • 2025: shakeout. Alcune startup vector DB pivotano o vengono acquisite. Il mercato si stabilizza su ~5 player serii.
  • 2026: tre realtà coesistono: managed cloud (Pinecone) per chi vuole zero ops, open source self-hosted (Qdrant/Weaviate) per chi vuole controllo, pgvector per chi vuole semplicità.

Come scegliere nel 2026: tre domande

1. Quanti vettori avrai a 1 anno?

  • <10M → pgvector. Punto.
  • 10-100M → Qdrant / Weaviate self-hosted o cloud.
  • >100M → Pinecone / Milvus / Vespa.

2. Hai già Postgres in prod?

  • Sì → pgvector quasi sempre. Riduci servizi, sfrutta backup esistenti, transazionalità.
  • No e non vuoi adottarlo → vector DB dedicato.

3. Vuoi gestire l’infra?

  • Sì → self-hosted (Qdrant, Weaviate, Milvus).
  • No → managed (Pinecone, Weaviate Cloud, Qdrant Cloud, Zilliz).

Esempio: pgvector in 4 righe

CREATE EXTENSION vector;
CREATE TABLE docs (id bigserial PRIMARY KEY, content text, embedding vector(1024));
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);
SELECT content FROM docs ORDER BY embedding <=> $1::vector LIMIT 5;

$1 è il vettore della query. <=> è l’operatore cosine distance. Hai un sistema RAG funzionante in 5 minuti se Postgres c’è già.

Esempio: Qdrant con Python

from qdrant_client import QdrantClient
from qdrant_client.http.models import VectorParams, Distance, PointStruct

client = QdrantClient(host="localhost", port=6333)
client.create_collection(
    "docs",
    vectors_config=VectorParams(size=1024, distance=Distance.COSINE)
)

client.upsert(
    "docs",
    points=[
        PointStruct(id=1, vector=[0.1, 0.2, ...], payload={"source": "doc1.pdf"}),
    ]
)

results = client.search(
    "docs",
    query_vector=[0.1, 0.2, ...],
    limit=5,
    query_filter={"must": [{"key": "source", "match": {"value": "doc1.pdf"}}]}
)

API simile per Pinecone (pinecone.Index().query()) e Weaviate (client.collections.get('docs').query.near_vector(...)).

Indexing strategies

Trade-off classico: velocità di build vs velocità di query vs uso RAM vs accuracy.

HNSW (la default moderna)

  • Build time: medio (1-10 min per 1M vettori).
  • Query time: <10 ms per top-10 su 10M.
  • RAM: vettori + grafo (~40 byte/vettore overhead).
  • Accuracy: 95-99% (regolabile via ef_search).

Parametri principali:

  • M (default 16): connessioni per nodo. Più = più RAM, più accuracy.
  • ef_construction (default 200): qualità build.
  • ef_search (default 50): qualità query (tunable a runtime).

IVF (per dataset enormi)

Partiziona lo spazio in N cluster, cerca solo nei cluster vicini. Più scalabile per >100M vettori, meno accurate per query “fuori distribuzione”.

Quantization (per ridurre RAM)

  • Scalar quantization: float32 → int8 (4× meno RAM, ~1% accuracy loss).
  • Binary quantization: float32 → 1 bit/dim (32× meno RAM, 5-15% accuracy loss).
  • Product quantization: split + codebook (variabile, intermedio).

Pattern 2026: scalar quantization default, binary se hai dataset enormi.

Costi: numeri di scala

A 10M vettori, 1024-dim, ~40 GB raw:

ProviderCosto mensile (stima)
Pinecone Serverless$200-500
Weaviate Cloud Standard$150-400
Qdrant Cloud Standard$100-300
pgvector su Supabase Pro$25 + storage
Self-hosted Qdrant su 1 VM 64GB$80-150 (Hetzner)

Spesso il costo embedding (per generare i vettori) supera quello di storage:

  • OpenAI text-embedding-3-small: $0.02 per 1M token → 10M chunk × 500 token = 5B token = $100.
  • Open source (BAAI/bge, NomicEmbed, multilingual-e5) self-hosted: gratis ma GPU/CPU time.

Glossario lampo

  • ANN (Approximate Nearest Neighbor) — algoritmi che trovano i top-k vicini sacrificando accuracy esatta per velocità.
  • HNSW — Hierarchical Navigable Small World, l’algoritmo ANN più popolare nel 2026.
  • pgvector — estensione Postgres per vettori + indici HNSW/IVF. Diventata default delle startup pragmatiche.
  • Hybrid search — combinazione di dense (vector) e sparse (BM25) retrieval per migliorare recall.
  • Payload filtering — applicare filtri su metadata (es. user_id, lang, date_range) in combinazione con la vector search.

Take-away

La domanda “quale vector DB?” è meno importante di “quale embedding model?” e “quale chunking?”. La maggior parte degli use case sotto i 50M vettori sta benissimo su pgvector. Sopra, Qdrant o Weaviate. Pinecone solo se hai budget e zero voglia di ops. Diffida di chi ti vende un vector DB come “il differenziatore competitivo” — nel 2026 è una commodity con 3-4 leader maturi.

➡️ Prossima puntata: embeddings — sceglierli, valutarli, mixarli.