-- Căutare vectorizată în pgvector cu filtru pe tenant
-- Necesită index HNSW creat în prealabil
SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM document_chunks
WHERE tenant_id = 'tenant_123'
ORDER BY embedding <=> $1
LIMIT 5;Am lucrat recent la o aplicație de căutare semantică peste niscai documentații tehnice — vreo 120.000 de chunks procesate cu text-embedding-3-small. Primul impuls când faci ceva cu RAG e să pui Pinecone sau Milvus cloud, dar la un side-project n-ai chef să bagi cardul pentru 15-20$ pe lună.
Așa că am luat la frecat variantele gratuite (self-hosted pe un VPS Hetzner de 6 Euro sau free tier): pgvector, Qdrant și Chroma. Fiecare vine cu bubele și plusurile lui.
pgvector: Când ai deja Postgres și lene de servicii noi
Dacă aplicația ta folosește deja Supabase, Neon sau un Postgres clasic, pgvector e prima opțiune la care te gândești. Dai un CREATE EXTENSION vector; și ești gata.
Cât timp am avut sub 30.000 de vectori, a mers impecabil. Îmbinarea de date relaționale cu date vectoriale într-un singur query SQL e aur curat: faci JOIN direct pe utilizator și adaugi clauza de distanță.
Unde se rupe filmul? La indexare. Când am ajuns la 100k vectori și am activat indexul HNSW pe VPS-ul meu cu 2GB RAM, procesul de indexare a mâncat toată memoria și kernel-ul Linux a ucis Postgres-ul (OOM Killer). Dacă vrei viteze sub 20ms la volum mare, pgvector cere resurse serioase de RAM doar pentru indecși.
Qdrant: Racheta scrisă în Rust
L-am ridicat în Docker în mai puțin de 2 minute (qdrant/qdrant:latest). În plus, au și un free cloud tier de 1GB storage care e mai mult decât suficient pentru side-projects.
Ce m-a dat pe spate la Qdrant e modul în care gestionează filtrările complexe pe payload. În RAG, rar cauți doar similaritate semantică; aproape mereu vrei "similaritate DAR doar pentru tenant_id = 42 și status = active". Qdrant face asta nativ în timpul căutării pe vectori (payload indexation), nu ca un filtru aplicat ulterior.
Căutările îmi scot de regulă 12-15ms pentru top 5 rezultate. Trade-off-ul? Setup-ul inițial de schemă și colecții cere puțin mai mult boilerplate în TypeScript sau Python față de alternativele mai simpliste.
Chroma: Rapid pentru MVP, dubios în producție
Chroma e drăguț dacă scrii doar Python și vrei un duckdb local pentru vectori. E senzațional pentru Jupyter Notebooks și prototipat rapid în 10 minute.
M-am lovit de el când am încercat să rulez Chroma în mod client-server pe un container separat. Clientul de Node.js avea momente când pierdea conexiunea, iar consumul de memorie crescuse suspect la un dataset de doar 50k vectori. În plus, persistența pe disk a dat chix o dată la un restart brusc al containerului.
Verdictul meu
Dacă ai deja Postgres și dataset sub 50k vectori, rămâi pe pgvector. Nu-ți complica viața cu alt stack.
Dacă vrei ceva dedicat, cu latență minimă, filtrare avansată și o interfață web de administrare inclusă, mergi 100% pe Qdrant. E soluția pe care am rămas și pentru proiectul actual.
Chroma e ok doar dacă faci un script rapid în Python de weekend și nu vrei să instalezi nimic altceva.
Voi ce folosiți pe proiectele personale? Ați încercat pgvector cu mai mult de 1 milion de înregistrări fără să spargeți banca?