Alternative a Pinecone per piccoli team: pgvector, motori open source e basi di conoscenza ospitate

Le alternative a Pinecone più concrete per un piccolo team sono quattro: aggiungere l'estensione pgvector al database Postgres che già usa, sfruttare la ricerca full-text integrata in Postgres, ospitare in proprio un motore vettoriale open source (Qdrant, Weaviate, Milvus o Chroma) oppure affidare l'intera ricerca documentale a una base di conoscenza ospitata. Pinecone resta un servizio gestito apprezzato; la scelta dipende soprattutto dal database che ha già, dal volume dei documenti e da quanta infrastruttura vuole mantenere. Ecco un confronto oggettivo, i criteri per decidere e una lista di controllo per migrare.

Perché un piccolo team cerca alternative

Pinecone è un database vettoriale completamente gestito: Lei invia gli embedding, il servizio li indicizza e risponde alle ricerche per similarità senza che debba amministrare server. Per molti prodotti è la scelta giusta. Quando una PMI o una startup valuta altre strade, di solito è per il proprio contesto e non per la qualità del servizio.

• Un responsabile del trattamento in più. Ogni servizio che conserva estratti dei Suoi documenti richiede, secondo il GDPR, un accordo sul trattamento dei dati, una voce nel registro dei trattamenti e, se i dati escono dallo Spazio economico europeo, una base giuridica per il trasferimento.
• I dati sono già in Postgres. Se documenti, utenti e permessi stanno lì, tenere i vettori nello stesso database evita sincronizzazioni e consente filtri con semplici join SQL.
• Volumi contenuti. Un assistente interno interroga spesso poche migliaia di documenti: a questa scala qualunque opzione è abbastanza veloce.
• Costi prevedibili. Molti team preferiscono usare risorse che già pagano, o un modello in cui la spesa segue l'uso reale.
• I vettori non sempre servono. Su contratti, procedure o documentazione tecnica, una buona ricerca per parole chiave trova spesso il passaggio giusto.

La domanda utile non è «qual è il database vettoriale più economico?», ma «qual è l'architettura di ricerca più semplice che risponde correttamente alle domande dei nostri utenti?». Per vedere dove si gioca la qualità, segua una domanda reale in come funziona il RAG passo dopo passo.

Opzione 1: Postgres con pgvector

pgvector è un'estensione open source che aggiunge a Postgres un tipo di colonna vettoriale e operatori di distanza (euclidea, prodotto scalare, coseno). Supporta la ricerca esatta e quella approssimata con indici HNSW e IVFFlat, ed è disponibile nella maggior parte dei servizi Postgres gestiti.

In un confronto pgvector vs Pinecone, il punto di forza di pgvector è la vicinanza: vettori, metadati e regole di accesso condividono lo stesso database, lo stesso backup e la stessa transazione. «I dieci passaggi più simili tra i documenti che questo cliente può vedere, pubblicati dopo gennaio» diventa una singola query SQL. In cambio, la messa a punto spetta a Lei: parametri degli indici, memoria, manutenzione e il momento in cui una tabella molto grande inizia a pesare sul carico transazionale.

Opzione 2: la ricerca full-text di Postgres

Postgres offre da anni la ricerca full-text: colonne tsvector, indici GIN, dizionari per lingua (italiano compreso) che riducono le parole alla radice e funzioni di ordinamento. Nessun modello di embedding da chiamare, niente da reindicizzare se cambia il modello.

Rende al meglio quando l'utente usa le parole del documento: numero di articolo, nome di un modulo, codice di errore. Fatica di più con le parafrasi, quando la domanda parla di «ferie» e il regolamento aziendale di «permessi retribuiti». Il divario si riduce ampliando la richiesta con sinonimi e termini collegati prima della ricerca.

Opzione 3: motori vettoriali open source

• Qdrant: motore scritto in Rust, noto per il filtraggio sui metadati associati ai vettori insieme alla ricerca per similarità; per iniziare basta un singolo container.
• Weaviate: database vettoriale scritto in Go, con ricerca ibrida integrata che combina punteggi per parole chiave (BM25) e vettoriali, più moduli opzionali che calcolano gli embedding.
• Milvus: pensato per volumi molto grandi e installazioni distribuite, progetto della LF AI & Data Foundation; potente ma più impegnativo da gestire.
• Chroma: database di embedding leggero, molto usato per i prototipi, con una modalità integrata che gira dentro un'applicazione Python.

Tutti e quattro possono girare sui Suoi server, ad esempio in un data center italiano, e ciascun progetto offre anche una versione cloud gestita dall'azienda che lo sviluppa. L'hosting in proprio elimina la questione del fornitore ma aggiunge attività operative: aggiornamenti, backup, monitoraggio. Un'istanza singola di Qdrant o Chroma è sostenibile per un piccolo team; un cluster Milvus raramente lo è.

Opzione 4: una base di conoscenza ospitata

Un database vettoriale è solo un tassello di un sistema RAG. Bisogna estrarre il testo dai PDF, suddividerlo, indicizzarlo, recuperare i passaggi e generare una risposta con le fonti. Una base di conoscenza ospitata si occupa dell'intera catena: Lei carica i documenti e interroga via API.

Kopik funziona così, con un approccio diverso da quello di Pinecone: non usa un database vettoriale né embedding. Ogni base è indicizzata per una ricerca ibrida, full-text più ampliamento semantico delle parole chiave della domanda, così una richiesta sulle «ferie» raggiunge anche i passaggi sui «permessi retribuiti». Può creare gratuitamente una base privata caricando file PDF, Word, testo o Markdown e interrogarla dal sito, tramite un'API REST con chiavi o tramite un server MCP da client come Claude, Cursor o ChatGPT; il protocollo è spiegato in cos'è MCP. Le risposte citano i passaggi usati, e una modalità «passaggi» restituisce solo gli estratti.

Confronto e criteri di scelta

1. Di cosa ha bisogno davvero? Ricerca per similarità nel Suo prodotto o risposte su documenti? Il secondo caso non richiede di gestire alcun database.
2. Dove sono oggi i dati? Se sono in Postgres, provi pgvector o il full-text prima di aggiungere un servizio.
3. Che volume ha? Conti i frammenti, non i documenti. Sotto qualche milione, le opzioni semplici bastano.
4. Chi lo gestisce? Se nessuno nel team vuole mantenere un motore di ricerca, scelga un servizio gestito.
5. Quali obblighi valgono? GDPR, indicazioni del Garante Privacy sui responsabili del trattamento e, a seconda dell'uso, l'AI Act: ogni fornitore in più va documentato.
6. Come misurerà la qualità? Scriva 30 domande reali con risposta nota e provi ogni opzione su di esse.

Migrare da Pinecone senza perdere qualità

1. Conservi il testo di origine. Esporti il testo dei frammenti e i metadati, non solo i vettori: cambiando modello di embedding dovrà ricalcolare tutto, perché vettori di modelli diversi non sono confrontabili.
2. Congeli un set di valutazione. Salvi le domande di prova e i passaggi che Pinecone restituisce oggi.
3. Mantenga la stessa metrica. Coseno prima, coseno dopo, in pgvector o nel nuovo motore; altrimenti l'ordinamento peggiora senza che nessuno se ne accorga.
4. Riscriva i filtri. Namespace e filtri sui metadati diventano clausole WHERE, filtri sul payload o collezioni separate. Verifichi che un cliente non possa mai vedere i frammenti di un altro.
5. Faccia girare i due sistemi in parallelo per una settimana e confronti i passaggi restituiti.
6. Passi al nuovo sistema, poi faccia pulizia. Tenga il vecchio indice in sola lettura per qualche giorno, poi lo elimini e aggiorni il registro dei trattamenti.