-- Configurare optimă HNSW pentru ~50k vectori în pgvector
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
content TEXT NOT NULL,
metadata JSONB,
embedding vector(1536)
);
-- Creăm indexul HNSW cu parametri ajustați pentru recall bun
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- La nivel de sesiune, mărim ef_search pentru precizie mai mare
SET hnsw.ef_search = 40;
-- Interogare combinată cu filtrare pe metadata
SELECT id, content, 1 - (embedding <=> '[0.012, -0.023, ...]') AS similarity
FROM documents
WHERE metadata->>'category' = 'engineering'
ORDER BY embedding <=> '[0.012, -0.023, ...]'
LIMIT 5;Pentru un side-project unde indexam vreo 45.000 de fragmente de documentație tehnică, am refuzat din start să dau 70$/lună pe Pinecone. Am preferat să văd cât pot stoarce dintr-un VPS amărât de la Hetzner cu 2 vCPU și 4 GB RAM. Am testat pgvector, Chroma și Qdrant în condiții reale de query-uri concurente și consum de resurse.
pgvector: Alegerea logică dacă ai deja PostgreSQL
Dacă aplicația ta rulează deja pe Postgres, să instalezi o bază de date separată doar pentru embeddings este adesea o greșeală de arhitectură. pgvector rezolvă căutarea semantică prin extensia nativă și nu mai ai dureri de cap cu sincronizarea ID-urilor între două storage-uri diferite.
La 45.000 de vectori cu 1536 dimensiuni (embeddings de la OpenAI), un index HNSW a adăugat în jur de 320 MB în RAM. Căutările cu cosine distance au răspuns constant în sub 15ms.
Partea proastă? Când vrei filtrare complexă pe metadate combinate cu vector search, Postgres începe să transpire. Dacă query-planner-ul decide să facă filter scan înainte de index scan, latența sare la sute de milisecunde. Trebuie să tunezi manual work_mem și parametrii hnsw.ef_search, altfel riști să degradezi performanța tranzacțiilor clasice.
Chroma: Simplu de pornit, dureros când crește
Chroma este probabil cel mai prietenos motor când vrei să scrii trei linii de Python într-un notebook și să funcționeze pe loc. Sub capotă folosește SQLite și DuckDB, deci ai zero infrastructură de administrat la început.
Dar am pățit o problemă clasică de fiabilitate: la volum mediu, consumul de memorie scapă de sub control. După ce am încărcat setul complet de date și am început să trimit cereri paralele dintr-un worker Celery, procesul a sărit de 1.8 GB RAM. La un restart de container, timpul de re-indexare și blocajele de lock pe SQLite mi-au demonstrat că Chroma e excelent pentru demo-uri de hackathon, dar riscant dacă vrei să lași proiectul pornit săptămâni întregi fără mentenanță.
Qdrant: Câștigătorul tăcut scris în Rust
Qdrant m-a surprins plăcut. Vine ca un singur binar sau un container Docker minimalist care pornește în 50 MB de RAM.
Marele lui avantaj tehnic este payload-ul stocat direct lângă vectori. Spre deosebire de alte soluții, Qdrant optimizează căutarea filtrată folosind un index pe metadate înainte să traverseze graful HNSW, fără să piardă din recall. Cu aceiași 45.000 de vectori, a consumat doar 210 MB RAM și a răspuns la interogări în 4-6ms.
În plus, au un cluster gratuit de 1 GB în cloud-ul lor gestionat, fără să ceară card de credit. E mai mult decât suficient pentru câteva sute de mii de vectori de dimensiune mică.
Trade-off-ul? E o bază de date separată. Ai un serviciu în plus de monitorizat, de configurat backup-uri (snapshot-uri) și de actualizat periodic.
Ce să alegi până la urmă?
Dacă ai deja o bază Postgres în producție și sub 50k vectori, instalează pgvector și optimizează indexul HNSW. Dacă pornești de la zero, construiești un API separat pentru RAG sau ai nevoie de filtre complexe pe metadate, pune Qdrant în Docker și nu te mai uita înapoi. Pe Chroma l-aș lăsa doar pentru scripturi locale.
Voi ce folosiți acum pe proiectele mici de AI? Mai are rost o bază dedicată de vectori sau a devenit pgvector noul standard?