-- Activare extensie și creare tabelă cu vectori OpenAI (1536 dim)
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE IF NOT EXISTS document_embeddings (
id BIGSERIAL PRIMARY KEY,
content TEXT NOT NULL,
metadata JSONB,
embedding vector(1536)
);
-- Index HNSW pentru căutare rapidă de similaritate Cosine
CREATE INDEX ON document_embeddings
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- Căutare top 5 cele mai similare documente
SELECT id, content, 1 - (embedding <=> '[0.012, -0.023, ...]'::vector) AS similarity
FROM document_embeddings
WHERE metadata->>'category' = 'tech'
ORDER BY embedding <=> '[0.012, -0.023, ...]'::vector
LIMIT 5;Am observat o grămadă de dev-i care își fac un side-project de RAG și sar direct la Pinecone sau Milvus Cloud, iar după două săptămâni se trezesc cu facturi inutile sau limite atinse. Am testat intensiv trei alternative gratuite (pgvector, Qdrant și Chroma) pe vreo două proiecte personale și o aplicație internă unde am indexat ~15.000 de documente de tehnice.
Iată concluziile mele pragmatice, fără pitch-uri de marketing, ca să știi ce să alegi în funcție de ce infrastructură ai deja.
pgvector: Când ai deja Postgres și vrei zero batai de cap
Dacă proiectul tău folosește deja Supabase, Neon sau un Postgres clasic într-un container, pgvector e prima opțiune la care trebuie să te uiți. Nu ai servicii noi de configurat, nu ai SDK-uri ciudate de integrat — e doar o extensie SQL.
Am avut cazul la un proiect de cautare semantică unde am indexat 15k de embeddings de la OpenAI (1536 de dimensiuni). Cu un index HNSW (vector_cosine_ops), timpii de răspuns au fost constant sub 15-20ms.
Trade-off sincer: E impecabil până la vrei câteva sute de mii de vectori. Dacă depășești pragul de 500k vectori mari și ai un server mic cu 2GB RAM, Postgres va începe să facă swap masiv pentru că indexul HNSW trebuie să stea în RAM. De asemenea, dacă faci filtering complex pe JSON-uri alături de vector search, sintaxa SQL devine puțin stufoasă.
Qdrant: Performanță maximă și filtrare avansată
Qdrant e scris în Rust și e, după părerea mea, cel mai matur vector DB dedicat la ora actuală. Au un free tier generos pe cloud (1GB cluster), dar adevărata frumusețe e că îl poți rula local în Docker și consumă sub 100MB RAM la pornire.
L-am folosit când am avut nevoie de filtrat payload-uri complexe (ex: „găsește-mi vectorii similari cu X, dar doar dacă au tag-ul Y și date.status == 'active'”). Filtrarea la Qdrant e nativă și se întâmplă în timpul căutării vectoriale, nu după (post-filtering), ceea ce reduce latența la query de vreo 3 ori comparativ cu alte opțiuni.
Trade-off sincer: DX-ul (Developer Experience) e puțin mai riguros. Trebuie să definești scheme clare de payload dacă vrei indecși de filtrare și e un serviciu în plus de monitorizat în stack-ul tău.
Chroma: Excelent pentru PoC rapid în Python, problematic în prod
Chroma este visul oricărui Pythonist când începe un script în Jupyter Notebook. Faci pip install chromadb, scrii 4 linii de cod și ai o bază de date vectorială stocată pe disc într-un fișier SQLite. Zero setup de infrastructură.
Totuși, când am încercat să o trec pe un server separat ca microserviciu API, lucrurile au început să scârțâie. Clientul de Python/JS mai dă erori ciudate de conexiune, iar consumul de memorie crește nejustificat la inserții mari în batch.
Trade-off sincer: Perfect pentru prototipat în 30 de minute la un hackathon. N-aș pune-o însă într-o aplicație cu mai mult de 2-3 useri concurenți.
Ce să alegi până la urmă?
- AI deja Postgres în stack? Instalează
pgvector. Scutești timp și nu adaugi complexitate. - Faci un proiect de la zero, vrei scale și filtrare pe metadata? Mergi pe Qdrant (Docker local sau free cloud).
- Vrei doar să testezi rapid o idee în Python? Folosește Chroma, dar fii pregătit să migrezi când crește proiectul.
Voi ce soluție folosiți pentru vectori în proiectele personale?