-- Creăm tabela cu o coloană de tip vector (1536 dimensiuni pentru OpenAI)
CREATE TABLE IF NOT EXISTS products (
id SERIAL PRIMARY KEY,
name TEXT NOT NULL,
embedding vector(1536)
);
-- Creăm un index HNSW pentru căutare rapidă (cosine distance)
CREATE INDEX ON products USING hnsw (embedding vector_cosine_ops);
-- Căutăm cele mai similare 5 produse folosind operatorul <=>
SELECT name, 1 - (embedding <=> '[0.012, -0.023, 0.005, ...]') AS similarity
FROM products
ORDER BY embedding <=> '[0.012, -0.023, 0.005, ...]'
LIMIT 5;Când vrei să pui un search semantic sau un RAG pe un proiect personal, te lovești rapid de prețurile absurde de la Pinecone. Vestea bună e că poți rula totul gratuit, direct pe VPS-ul tău de 5 dolari de pe Hetzner sau DigitalOcean. Am testat pgvector, Qdrant și Chroma pe un set de 15.000 de produse și vă zic sincer unde s-a blocat treaba.
pgvector: Extensia care îți salvează bugetul
Dacă ai deja o bază de date PostgreSQL în proiect, n-are absolut niciun sens să te complici cu alt serviciu. Instalezi extensia pgvector și ai terminat povestea.
Am avut un proiect cu vreo 12.000 de vectori generați cu text-embedding-3-small de la OpenAI (dimensiune 1536). Query-urile de căutare prin cosine similarity rulau în mai puțin de 15ms pe o bază de date de test, fără niciun index special.
Trade-off-ul sincer? Când baza crește și ai nevoie de indecși gen HNSW (Hierarchical Navigable Small World), Postgres începe să mănânce RAM ca un nesătul la build-ul indexului. De asemenea, sintaxa de query cu operatorul <=> e destul de ciudată dacă folosești un ORM clasic precum Prisma, unde trebuie să scrii query-uri brute (raw SQL).
Qdrant: Când vrei performanță de top în producție
Scris în Rust, Qdrant e un monstru de viteză. Au și o opțiune de free tier în cloud-ul lor (oferă 1GB de RAM, arhi-suficient pentru vreo 50.000 de vectori medii).
L-am folosit pe un chatbot enterprise și m-a salvat filtrarea lor pe payload. Poți să cauți vectori similari dar să pui filtre de tipul "doar produsele din categoria electronice și care sunt pe stoc". În pgvector faci asta cu un simplu WHERE, dar în alte baze de date vectoriale e un chin. Qdrant rezolvă asta nativ și extrem de rapid.
Partea proastă e că e încă o piesă în infrastructură. Trebuie să o configurezi, să-i faci backup separat și să-i monitorizezi consumul. Dacă ai un server mic, de 1GB RAM total, Qdrant s-ar putea să-ți dea Out Of Memory (OOM) dacă încerci să indexezi vectori mari fără să limitezi resursele din Docker.
Chroma: Bun pentru prototipuri rapide în Python
Chroma e extrem de popular în tutorialele de pe YouTube, mai ales pentru că se integrează perfect cu LangChain și rulează "in-memory" cu doar două linii de cod în Python.
Dar aici e capcana. În momentul în care vrei să-l treci în producție ca serviciu de sine stătător, te lovești de o imagine de Docker destul de greoaie și de o documentație care se schimbă de la o versiune la alta. Am pățit ca un update minor de versiune să-mi crape conexiunea clientului de Node.js.
În plus, backend-ul lor folosește SQLite sub capotă pentru stocarea metadata-ului. La scrieri concurente intense pe un proiect cu peste 8.000 de utilizatori activi, am avut probleme cu blocarea bazei de date (database is locked).
Ce alegi până la urmă?
Regula mea de bază e simplă:
- Ai deja Postgres? Folosește
pgvector. Scapi de infrastructură extra și e extrem de stabil. - Ai nevoie de filtre complexe pe metadate și vrei viteză maximă în producție? Mergi pe
Qdrant(ori self-hosted, ori free tier-ul lor). - Lucrezi doar în Python, vrei un demo rapid pe local și nu te interesează producția pe termen lung?
Chromaîși face treaba în 5 minute.
Voi ce folosiți pentru vectori în proiectele voastre secundare? Ați încercat să puneți pgvector în producție pe bugete de server mici?