-- Activăm extensia și creăm tabela cu vectori de 1536 dimensiuni
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id SERIAL PRIMARY KEY,
content TEXT,
embedding vector(1536)
);
-- Creăm indexul HNSW pentru căutare rapidă (distanță cosine)
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
-- Interogare simplă pentru cei mai apropiați 5 vecini
SELECT content, 1 - (embedding <=> $1) AS similarity
FROM documents
ORDER BY embedding <=> $1
LIMIT 5;Ne-am trezit toți că avem nevoie de vector databases pentru că AI-ul e noul standard, dar pentru un side-project nu vrei să plătești 50$ pe lună la Pinecone doar ca să testezi o idee. Am trecut prin asta recent când am vrut să fac un motor de căutare semantică pe un set de 50.000 de documente. Hai să vedem ce merită cu adevărat folosit pe tier-ul moca sau self-hosted fără să-ți mănânce tot timpul și toți banii.
pgvector – Când vrei zero bătăi de cap cu infrastructura
Dacă ai deja un Postgres pe undeva (un Supabase moca sau o instanță mică pe Render/Railway), pgvector e cea mai logică alegere. Nu trebuie să pornești alt serviciu, nu înveți alt API de interogare și scrii totul în SQL-ul pe care îl știi deja.
Am testat asta pe o bază de date mică de vreo 10k vectori de dimensiune 1536 (standardul pentru embeddings de la OpenAI). Cu un index HNSW (Hierarchical Navigable Small World), interogările de similaritate rulau lejer sub 15ms. Pe un VPS ieftin de 5$ pe lună, am reușit să înghesui baza de date plus aplicația de Node.js fără nicio problemă, dar a trebuit să setez atent memoria.
- Trade-off: Devine nasol când ai resurse extrem de limitate pe instanța de Postgres. Indexul HNSW se încarcă complet în RAM pentru a fi rapid. Dacă ai o bază de date cu doar 512MB RAM pe tier-ul free, s-ar putea să-ți crape instanța din cauza OOM (Out Of Memory) exact când îți e lumea mai dragă, adică la build-ul indexului.
Qdrant – Performanță pură pe resurse puține
Scris în Rust, Qdrant e preferatul meu când am nevoie de performanță pură și stabilitate fără costuri mari. Ei oferă un free tier în cloud-ul lor (cu 1GB de RAM și vreo 0.5 vCPU), ceea ce este arhi-suficient pentru a stoca în jur de 20.000-30.000 de vectori medii.
Ce m-a impresionat cel mai mult la Qdrant este footprint-ul de memorie. Pe când alte soluții pornesc destul de greu, Qdrant pornește în Docker cu mai puțin de 50MB RAM în idle. Filtrarea hibridă (keyword + vector) e un alt punct forte. La majoritatea proiectelor de RAG (Retrieval-Augmented Generation) nu vrei doar căutare semantică pură, ci vrei să zici: "caută-mi chestia asta, dar doar în documentele din categoria tech ale utilizatorului X". Qdrant face asta nativ și extrem de rapid prin payload filtering.
- Trade-off: Trebuie să le înveți API-ul lor specific (care e destul de diferit de SQL-ul clasic) și ai de gestionat încă o conexiune externă în aplicația ta.
Chroma – Bun pentru prototipuri rapide în Python, dar atât
Chroma e promovat peste tot în tutorialele de pe YouTube și în documentația de la LangChain. E extrem de simplu de pornit: dai un pip install chromadb, rulează in-memory direct în scriptul tău și în 5 minute ai gata proiectul.
Dar adevărul e că pentru producție, chiar și pe un side-project mic, mi s-a părut destul de fragil. Docker image-ul lor oficial e destul de greoi și am avut probleme cu coruperea bazei de date sqlite pe care o folosește în spate la restarturi mai bruște ale containerului.
- Trade-off: E excelent ca să validezi o idee într-o după-amiază pe mașina locală, dar n-aș lăsa un serviciu live pe el pe termen lung.
Concluzia mea
Dacă ai deja Postgres în stack și proiectul tău are sub 50.000 de vectori, mergi pe pgvector și optimizează indexul. Dacă vrei performanță maximă, filtrare complexă pe metadate și vrei să ții baza de date vectorială complet separată de cea relațională, Qdrant pe free tier e câștigătorul detașat.
Voi ce folosiți pentru proiectele personale de RAG? V-ați lovit și voi de probleme de RAM cu indexurile HNSW pe servere mici?