eduardweb.
AI & LLMsIntermediar#rag#ai#pgvector#qdrant#vector-database

Vector DB-uri gratuite pentru side-projects: Qdrant vs Chroma vs pgvector

De Teodor Pascu, 11 aug. 2026 · 5 vizualizări · 3 like-uri

Postat acum 5 zile
python
from qdrant_client import QdrantClient
from qdrant_client.models import Filter, FieldCondition, MatchValue

client = QdrantClient(url="https://your-cluster.qdrant.tech", api_key="YOUR_KEY")

# Query rapid cu payload filter nativ
results = client.search(
    collection_name="tech_docs",
    query_vector=[0.023, -0.412, 0.118], # vectorul tău OpenAI / Cohere
    query_filter=Filter(
        must=[
            FieldCondition(
                key="category",
                match=MatchValue(value="backend")
            )
        ]
    ),
    limit=5
)

Dacă faci un side-project bazat pe LLM-uri sau RAG, prima dilemă e unde arunci embedding-urile fără să arzi bani pe Pinecone sau alți vendori scumpi. Am avut cazul lunile trecute cu o aplicație unde am indexat în jur de 12.000 de documente tehnice (aprox. 85.000 de chunks cu vectori de 1536 dimensiuni). Am trecut prin pgvector, Chroma și Qdrant, iar diferențele de DX și performanță pe infrastructură ieftină sunt uriașe.

pgvector: Perfect dacă ai deja Postgres, dar atenție la resurse

Ideea de a nu mai adăuga o bază de date în plus în stack e genială. Dacă folosești deja Supabase, Neon sau un Postgres self-hosted pe un VPS ieftin, extinderea pgvector e la un CREATE EXTENSION distanță.

Trade-off-ul mare apare la indexare și consumul de RAM. Când am trecut de 50.000 de vectori pe un container cu 512MB RAM, generarea indexului HNSW făcea crash cu OOM (Out of Memory) instant. Dacă schimbi pe IVFFlat ca să salvezi memorie, scade acuratețea căutării și ajungi la latențe de peste 200ms la query-uri legate de filtrare SQL clasică.

Merge brici pentru proiecte mici (sub 20k vectori) unde ai deja legături strânse între datele relaționale și vectori. Peste limita asta, începe bătaia de cap cu tuning-ul de Postgres.

Chroma: Excepțional pentru POC-uri, greoi în producție

Chroma e prima opțiune pe care o încerci în Python. Dai pip install chromadb, rulează un SQLite local pe fundal și în 5 minute ai un RAG funcțional în Jupyter Notebook.

Problema apare când vrei să-l scoți din modul embedded și să-l pui pe un server decuplat. Modul client/server din Chroma a crescut mult în ultima vreme, dar mi se pare încă fragil la restarturi și gestionarea persistenței pe disc. Dacă nu lucrezi în Python sau JS, suportul pentru alte SDK-uri e destul de slab. Pentru un prototype rapid e excelent. Pentru ceva ce trebuie să stea sus 24/7 fără mentenanță, am căutat altceva.

Qdrant: Câștigătorul clar pe tier-ul gratuit

M-am oprit la Qdrant și nu cred că îl mai schimb curând. Este scris în Rust, extrem de eficient cu resursele și oferă un Cloud Free Tier generos (1 cluster permanent gratuit, 1GB RAM, suficient pentru vreo 100k vectori de 1536 dim).

Ce mă încântă cel mai mult este modul în care gestionează payload filtering-ul. La pgvector sau Chroma, filtrările după metadate făcute înainte de vector search încetinesc masiv interogarea. În Qdrant, indicii pe payload sunt nativi și extrem de rapizi. La proiectul de 85k vectori, latența medie pe căutare hibridă cu filtrare pe user_id și category a fost de 18ms pe clusterul lor gratuit.

Ce să alegi până la urmă?

Concluzia mea după câteva săptămâni de teste:

  1. Ai deja Supabase/Postgres și sub 20.000 de vectori? Rămâi pe pgvector.
  2. Vrei doar să testezi o idee rapid în Python pe laptop? Chroma.
  3. Construiești un produs care trebuie să meargă repede, să aibă filtrări avansate și să nu-ți mănânce RAM-ul? Pune Qdrant în Docker local și folosește Cloud-ul lor gratis în prod.

Voi ce folosiți pe proiectele personale de AI în perioada asta? Ați întâmpinat probleme de RAM cu HNSW în Postgres?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.