import { QdrantClient } from '@qdrant/js-client-rest';
const client = new QdrantClient({ url: process.env.QDRANT_URL, apiKey: process.env.QDRANT_API_KEY });
// Căutare semantică cu filtru pe payload (ex: doar docu-uri de la userul X)
const searchResult = await client.search('tech_docs', {
vector: [0.023, -0.012, 0.089, /* ...1536 dim */],
limit: 5,
filter: {
must: [
{ key: 'userId', match: { value: 'usr_8192' } },
{ key: 'category', match: { value: 'database' } }
]
}
});
console.log(searchResult.map(res => ({ id: res.id, score: res.score, text: res.payload?.text })));De ce nu plătesc Pinecone pentru un pet project
Luna trecută am lansat un micro-tool RAG pentru căutare semantică în documente tehnice. Aveam în jur de 50.000 de vectori (embeddings de la OpenAI, text-embedding-3-small, 1536 dimensiuni). Când m-am uitat la prețurile de la Pinecone sau Milvus cloud, mi-am dat seama că dădeam mai mult pe DB decât pe VPS.
Așa că am luat la frecat opțiunile moca sau self-hosted: pgvector, Qdrant și ChromaDB. Iată ce am învățat pe pielea mea.
1. pgvector: Fără infrastructură nouă
Dacă folosești deja PostgreSQL (pe Supabase, Neon sau pe un VPS ieftin), pgvector e opțiunea firească. Nu instalezi un serviciu nou, nu gestionezi încă o cheie API, ai tranzacții ACID și poți să faci JOIN direct între vectori și datele relaționale ale utilizatorului.
Am încărcat cei 50k vectori pe o instanță Neon free tier. Cu un index HNSW, timpul de căutare a fost sub 18ms.
Trade-off-ul? Indexul HNSW mănâncă RAM generos. Dacă depășești 200k-300k de vectori de dimensiune mare pe o instanță cu 512MB RAM, PostgreSQL o să-ți dea OOM fără ezitare la build-ul indexului.
2. Qdrant: Rapid, Rust, free tier generos
Dacă ai nevoie de filtru avansat pe metadata (de exemplu: "caută doar în documentele din PDF-ul X create după 2023"), Qdrant este absolut genial. Este scris în Rust, e extrem de stabil și pornește într-un container Docker care consumă sub 80MB RAM în idle.
În plus, au un cluster cloud gratuit de 1GB RAM (fără card de credit), unde mi-au încăpat lejer cei 50k vectori cu tot cu payload. Latența p99 a fost de 4ms pe căutare, simțitor mai rapidă decât pgvector.
3. Chroma: Excelent pentru Jupyter, dubios în producție
ChromaDB e iubit de comunitatea de Python pentru că faci pip install chromadb și în 3 linii de cod ai o bază de date funcțională local. Pentru un script rapid sau un POC e impecabil.
Problema apare când vrei să-l pui pe un server cu cereri concurente. Fiind încă la început ca arhitectură server-side, am avut blocaje la scriere și crash-uri de memorie când 2 worker-i de Node.js încercau să scrie simultan prin REST API. Pentru mine a picat testul de stres.
Verdictul meu după teste
Regula mea simplă după acest experiment este:
- Ai deja Postgres pe proiect? Folosește
pgvector. Economisești timp, devops zero. - Ai un proiect dedicat de AI / căutare complexă? Mergi pe
Qdrant(ori Docker pe VPS-ul tău de 4$, ori cloud-ul lor moca). - ChromaDB? Păstrează-l doar pentru notebook-uri de analiză de date.
Voi ce folosiți pentru vectori când nu aveți buget de enterprise? Ce experiențe ați avut cu HNSW pe Postgres?