-- Setare index HNSW pe pgvector cu parametri optimizati pentru memorie
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
content TEXT,
metadata JSONB,
embedding vector(1536)
);
-- Atentie la m si ef_construction: valori prea mari rup RAM-ul!
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- Căutare cu filtru pe metadata
SELECT content, 1 - (embedding <=> '[0.012, -0.043, ...]') AS similarity
FROM documents
WHERE metadata->>'category' = 'backend'
ORDER BY embedding <=> '[0.012, -0.043, ...]'
LIMIT 5;Salutare! Dacă te-ai apucat de vreun side-project cu LLM-uri sau un sistem RAG, sigur ai dat de dilemă: ce bază de date cu vectori folosești fără să arunci banii pe planurile scumpe de Pinecone? Am trecut prin asta recent când am construit o aplicație de căutare semantică pe un set de ~80.000 de documente tehnice. Am testat pgvector, Chroma și Qdrant, iar diferențele de consum și latență m-au surprins.
pgvector: Zero infrastructură nouă, dar atenție la RAM
Dacă ai deja un Postgres în proiect, instinctul e să tragi CREATE EXTENSION vector; și să mergi mai departe. Așa am făcut și eu pe o instanță mică de VPS de 5$. Este genial din punct de vedere al simplității: folosești aceleași tranzacții, același ORM și ai JOIN-uri directe cu datele relaționale.
Cârligul apare la indexare. Până pe la 10.000 - 20.000 de vectori, căutarea secvențială (exact search) e ok. Când am urcat la 80.000 de embedding-uri de 1536 de dimensiuni (OpenAI) și am construit un index HNSW, consumul de RAM pe Postgres a sărit instant cu 1.2 GB.
Trade-off: Excelent pentru proiecte mici unde ai deja Postgres. Totuși, dacă ai resurse limitate pe server, un index HNSW neconfigurat atent îți poate dărâma baza de date.
Chroma: Regele prototipurilor rapide
Chroma e prima alegere când vrei să pui pe picioare un script Python sau un demo local în JS în 10 minute. Rulează în memorie sau persistă datele într-un SQLite local.
L-am folosit la un hackathon intern. Experiența de DX (Developer Experience) e excelentă: n-ai nevoie de servere, n-ai nevoie de Docker. Îi dai pip install chromadb, i-ai pasat textul și își generează singur embedding-urile dacă îi dai un API key.
Trade-off: Când vrei să duci aplicația pe un server de producție și ai nevoie de mod client-server persistent, Chroma începe să arate limitările unei unelte gândite primar pentru dezvoltare locală. Gestionarea memoriei în modul server devine opacă și suportul pentru filtrări hibride complexe e încă în urmă.
Qdrant: Performanță curată și un free-tier generos
Qdrant e scris în Rust și se vede din prima secundă în consumul de resurse. Au un Cloud Free Tier permanent cu 1GB RAM și 0.5 vCPU, suficient lejer pentru ~100.000 de vectori dacă folosești scalar quantization.
Ce m-a câștigat la Qdrant a fost viteza pe căutări cu filtre complexe pe payload (de exemplu: "caută paragrafe similare, dar DOAR din articolele scrise în 2024 și tagged cu 'backend'"). În timp ce pgvector chinuie planificatorul de interogări când combini WHERE pe JSONB cu ORDER BY vector, Qdrant face asta nativ fără vreo scădere de latență (sub 15ms la teste).
Trade-off: Adaugi un serviciu extern în stack, un API nou de învățat și un efort suplimentar de sincronizare dacă datele primare trăiesc tot într-o bază relațională.
Ce alegi până la urmă?
Regula mea de deget după ultimele luni:
- AI deja Postgres și sub 20k vectori? Mergi pe pgvector fără ezitare.
- Vrei un POC/demo rapid local de pe laptop? Chroma e cel mai rapid.
- Construiești un produs RAG cu filtrare hibridă și vrei performanță fără să plătești de la început? Qdrant Cloud (sau self-hosted în Docker) e opțiunea cea mai matură.
Voi ce folosiți pe side-project-urile de AI? Ați rămas pe Postgres sau preferați baze dedicate?