pgvector vs Pinecone vs Qdrant vs Weaviate pentru RAG

Ai stabilit deja că ai nevoie de RAG, nu doar de un LLM cu context mai mare. Următoarea decizie e mai greu de schimbat din mers decât pare: unde stochezi și cauți, de fapt, vectorii. Migrarea între vector database-uri, odată ce ai mii de documente indexate și un pipeline care rulează în producție, nu e o simplă schimbare de configurare — vezi mai jos exact de ce.

Piața s-a consolidat în jurul a patru opțiuni care acoperă marea majoritate a proiectelor RAG reale: pgvector, Pinecone, Qdrant și Weaviate. Fiecare pornește dintr-o filozofie diferită — extensie peste baza de date pe care o ai deja, serviciu complet gestionat, motor open-source rapid, sau căutare hibridă nativă — și niciuna nu e „cea mai bună" universal. Articolul de față trece prin toate patru, cu ce contează concret la fiecare, apoi un cadru de decizie pe care îl poți aplica direct pe cazul tău.

Ce face, de fapt, un vector database într-un sistem RAG

Un LLM nu „știe" ce conține documentul tău — știe doar ce i-ai pus în context. RAG rezolvă asta căutând, la fiecare întrebare, cele mai relevante fragmente din documentele tale și punându-le în prompt. Căutarea aia are nevoie de un motor construit special pentru ea, nu de o interogare SQL obișnuită.

De ce nu ține o căutare exactă

O bază de date relațională clasică găsește rânduri care se potrivesc exact sau parțial pe text — WHERE titlu LIKE '%contract%'. Un vector database face altceva: transformă fiecare fragment de text într-un șir de numere (embedding) care codifică sensul lui, apoi găsește fragmentele ale căror numere sunt „aproape" de numerele întrebării tale, în spațiul matematic al acelor vectori. Rezultatul: găsești fragmente relevante semantic chiar dacă nu conțin niciun cuvânt din întrebare.

Ce contează cu adevărat la alegere

Viteza brută a unei singure interogări atrage atenția în benchmark-uri, dar rareori e ce te blochează în practică. Contează mai mult: câte din rezultatele relevante chiar le găsești (recall — metricile de evaluare RAG intră în detaliu pe asta), cât de bine filtrezi pe metadate în același timp cu căutarea semantică (ex. „doar documentele din ultimele 90 de zile"), cât efort operațional cere sistemul zi de zi, și cât costă, de fapt, la volumul tău — nu la volumul de test din marketingul furnizorului.

Benchmark-urile publicate de fiecare furnizor merită citite cu circumspecție: fiecare rulează pe hardware, dimensiuni de embeddings și tipare de interogare alese să-l avantajeze. Un test propriu, cu datele și tiparul tău real de interogări, pe câteva mii de documente, spune mai mult decât orice tabel de pe site-ul unui furnizor — iar la scara majorității proiectelor B2B, diferența de latență dintre opțiuni contează mult mai puțin decât efortul de operare sau costul lunar.

pgvector: vector search direct în Postgres

Ce este și cum funcționează

pgvector e o extensie pentru PostgreSQL, nu un sistem separat. Adaugă un tip de coloană pentru vectori și indexare dedicată (HNSW și IVFFlat), direct în baza de date pe care probabil o ai deja. Vectorii stau în același rând cu restul datelor produsului — nu mai ai un al doilea sistem de sincronizat, nici o rețea nouă de autentificat.

Când e alegerea corectă

Dacă stack-ul tău rulează deja pe Postgres, pgvector e aproape întotdeauna primul lucru de încercat: e gratuit, nu adaugă niciun serviciu nou de operat, și moștenești direct tranzacțiile, join-urile și controlul de acces pe care Postgres le are deja construite. Practic, rămâne rapid și predictibil până undeva pe la 10 milioane de vectori — suficient pentru majoritatea aplicațiilor B2B, care rareori depășesc câteva sute de mii sau milioane de fragmente indexate.

Unde cedează

Peste acel prag, sau la volum foarte mare de interogări simultane, Postgres începe să ceară tuning manual pe care un motor construit special pentru căutare vectorială nu-l cere din prima — parametri de index, memorie dedicată, uneori partiționare. Nu e că „nu merge"; e că efortul de întreținere crește vizibil, iar la un moment dat un motor dedicat costă mai puțin timp de inginerie decât Postgres împins la limită.

Ecosistemul din jur

pgvector moștenește tot ce vine cu Postgres, nu doar coloana de vectori. Supabase îl împachetează direct într-un Postgres găzduit, cu API generat automat pe deasupra; Neon și alte servicii Postgres serverless îl suportă la fel, fără configurare suplimentară. Practic, nu alegi doar o bibliotecă de căutare — moștenești migrări, backup-uri, monitorizare și control de acces deja construite, ceva ce niciun motor nou, oricât de rapid, nu are din prima zi.

Pinecone: managed, serverless, zero operare

Cum se calculează factura

Pinecone nu are servere de administrat — plătești pe baza a trei componente de utilizare: spațiul de stocare, unitățile de citire (fiecare interogare) și unitățile de scriere (fiecare adăugare sau actualizare de vector). Nu vezi și nu poți ajusta parametrii interni ai indexului; în schimb, nu trebuie să te ocupi de scalare, replicare sau upgrade-uri.

Free tier și cost realist la scară mică

Planul gratuit („Starter") acoperă aproximativ 100.000 de vectori la 1536 de dimensiuni, fără card de credit — suficient pentru un prototip sau o aplicație mică de test. De la planul plătit încolo, stocarea costă în jur de 0,33 USD/GB pe lună, iar pentru o aplicație mică-medie, factura lunară ajunge de regulă undeva între 50 și 200 USD. Cifra crește neliniar odată ce volumul de interogări urcă: o interogare cu filtre pe metadate consumă mai multe unități de citire decât una simplă, nu doar una singură.

Reranking gestionat

Pe lângă căutarea de bază, Pinecone oferă și un pas opțional de reranking gestionat — reordonarea rezultatelor inițiale cu un model mai precis, dar mai lent, aplicat doar pe primele câteva zeci de candidați. Scutește un serviciu separat de reranking pe care altfel ai fi nevoit să-l operezi tu, dar adaugă încă o componentă de cost la fiecare interogare care îl folosește — merită comparat cu costul total descris în cât costă, de fapt, un sistem RAG înainte să-l activezi implicit peste tot.

Compromisul

Viteza și lipsa de operare au un preț care crește repede la scară mare, iar opacitatea indexului taie din opțiunile de optimizare fină pe care le-ai avea cu un motor open-source. Pentru echipe mici, fără cineva dedicat pe infrastructură, asta e adesea un schimb bun; pentru volum mare de interogări, merită calculat costul înainte de a te angaja.

Qdrant: open-source, Rust, cel mai bun raport preț-performanță

Self-hosted vs. Qdrant Cloud

Rulat pe infrastructura ta, Qdrant e complet gratuit — licență Apache 2.0, fără cost de licențiere, plătești doar mașina pe care rulează. Qdrant Cloud, varianta gestionată, are un nivel gratuit real (nu un trial cu limită de timp) și, de acolo încolo, facturează pe resursele clusterului — CPU, memorie, disk —, nu pe fiecare interogare sau scriere în parte. Diferența față de Pinecone contează mai ales la volum mare de scrieri: un sistem care scrie des, cum e memoria unui agent AI care actualizează contextul la fiecare pas, nu vede costul crescând per operație, fiindcă plătești pentru cluster, nu per scriere.

Filtrarea pe metadate — punctul forte

Qdrant, scris în Rust, e construit cu accent pe filtrare rapidă combinată cu căutarea semantică: „găsește documente similare cu acesta, dar doar din categoria X, actualizate în ultima lună". E genul de interogare pe care multe sisteme RAG reale o folosesc constant, nu o excepție.

Quantization — cum reduci costul de memorie

Costul unui vector database la scară vine, în mare parte, din memoria RAM necesară pentru index. Qdrant suportă quantization scalară și binară — o compresie a vectorilor care poate reduce memoria necesară cu 75-97%, cu o pierdere de acuratețe de regulă acceptabilă pentru RAG. Practic, aceeași infrastructură ține de câteva ori mai mulți vectori decât fără compresie, ceea ce explică de ce Qdrant rămâne ieftin chiar și la volum mare.

Când alegi Qdrant în locul lui Pinecone

Când vrei viteză și cost previzibil la scară, ai (sau poți avea) capacitate de operare minimă — self-hosted înseamnă, practic, un docker run pentru a ajunge la ceva utilizabil în producție —, și nu vrei să depinzi de un singur furnizor fără varianta de a rula, la nevoie, pe infrastructura ta.

Weaviate: căutare hibridă nativă și multi-tenancy

BM25 și vector, într-o singură interogare

Weaviate integrează căutarea pe cuvinte-cheie (BM25) și căutarea vectorială ca funcție de bază a query engine-ului, nu ca un pipeline separat pe care îl asamblezi tu. Pentru multe cazuri RAG, hibridul contează: căutarea pur semantică ratează potriviri exacte de termen (un cod de produs, un nume propriu), iar căutarea pur pe cuvinte-cheie ratează sinonime și parafrazări.

Multimodal — text și imagine

Modulul CLIP integrat gestionează nativ căutarea text-imagine, fără un pipeline separat de embeddings pentru fiecare tip de conținut. Dacă produsul tău are nevoie de căutare „găsește imagini similare cu aceasta" alături de căutare pe text, Weaviate scutește o bucată reală de inginerie.

Query Agent și RAG agentic

Pentru sisteme RAG agentice — unde un agent AI decide singur când și ce să caute, în mai mulți pași succesivi, nu într-o singură interogare fixă — Weaviate oferă un Query Agent dedicat, gândit să gestioneze interogări multi-pas fără orchestrare manuală separată. Contează un detaliu practic la buget: fiecare pas dintr-un lanț de recuperare consumă separat din cotă, deci un flux agentic cu cinci pași reali per întrebare de utilizator înseamnă cinci interogări facturate, nu una.

Curba de învățare

Modelul de schemă și interfața de interogare (GraphQL, în variantele mai vechi ale API-ului) cer mai mult timp de acomodare decât pgvector sau Qdrant. Pentru un proiect text-only, pornit de la zero, complexitatea suplimentară rareori se justifică; pentru multi-tenancy real (mulți clienți izolați în același sistem) sau conținut multimodal, investiția chiar merită.

Tabel comparativ și cum alegi, în practică

Testul rapid, în patru întrebări

1. Ai deja Postgres, iar volumul rămâne sub aproximativ 10 milioane de vectori? Pornește cu pgvector — e cea mai scurtă cale de la zero la producție.
2. Vrei zero infrastructură de gestionat și ești dispus să plătești pentru asta pe măsură ce crești? Pinecone e construit exact pentru situația asta.
3. Ai nevoie de viteză mare, filtrare complexă pe metadate și vrei opțiunea de a rula pe infrastructura ta? Qdrant oferă raportul cel mai bun între cost și control.
4. Ai nevoie de căutare hibridă (cuvinte-cheie + semantic) din start, de izolare curată între mulți clienți, sau de căutare pe imagini alături de text? Weaviate scutește cea mai multă inginerie pentru exact aceste cazuri.

Două sau mai multe răspunsuri „da" pe același rând indică, de regulă, alegerea corectă; dacă răspunsurile se împart pe mai multe rânduri, contează care nevoie e mai presantă acum, nu peste un an.

Un exemplu aplicat

O firmă B2B cu 300.000 de documente interne — contracte, documentație tehnică, corespondență cu furnizorii —, o echipă de trei dezvoltatori și un stack deja pe Next.js și Postgres. Aplicat pe testul de mai sus: (1) da, are Postgres și volumul rămâne mult sub 10 milioane de vectori; (2) nu neapărat prioritate — echipa poate opera puțină infrastructură suplimentară dacă are sens; (3) filtrarea pe metadate contează, dar nu la nivelul unui produs de search dedicat, cu mii de interogări pe secundă; (4) nu are nevoie de căutare hibridă sau multimodal, doar text. Răspunsul iese clar: pgvector, fără nicio ezitare — orice altă opțiune ar adăuga un sistem nou de operat, pentru un beneficiu pe care firma asta nu-l valorifică încă. Peste doi ani, dacă volumul crește de zece ori sau apare nevoia de căutare hibridă, discuția se redeschide — dar nu se rezolvă azi cu o alegere „ca să fie sigur".

Cât de blocat rămâi de alegerea inițială

Ce te ține blocat, de fapt

Nu API-ul de interogare e problema — majoritatea au operații similare (adaugă vector, caută similar, filtrează). Ce te ține blocat e indexul construit: mutarea la alt sistem înseamnă, de regulă, re-generarea embeddings-urilor și re-indexarea completă, nu doar o copiere de date. La un volum mare de documente, asta e timp de procesare real, nu o schimbare de configurare de-o oră — pentru câteva sute de mii de documente, re-indexarea completă poate dura de la câteva ore la o zi întreagă, în funcție de rate-limit-ul modelului de embeddings folosit și de câtă procesare paralelă rulezi.

Un al doilea cost, mai puțin vizibil: perioada de tranziție. Dacă sistemul rămâne în producție cât timp reindexezi, ai nevoie fie de o fereastră de mentenanță, fie de o rulare în paralel a ambelor sisteme până când noul index e complet și verificat — nu doar „gata", ci confirmat că întoarce aceleași rezultate relevante ca vechiul sistem, pe un eșantion de întrebări reale.

Cum reduci riscul de la început

Păstrează textul sursă și embeddings-urile generate undeva independent de vector database (ex. într-un storage simplu, alături de metadatele originale), nu doar în interiorul sistemului ales. Dacă vreodată schimbi motorul, re-indexezi din datele proprii, fără să depinzi de un export complet și fiabil din sistemul vechi — un pas pe care nu toate vector database-urile îl fac la fel de curat.

Întrebări frecvente

Pot combina mai multe vector database-uri în același proiect?

Da, deși rar are sens de la început. Un tipar real: pgvector pentru datele operaționale de zi cu zi, plus un motor dedicat pentru un caz specific cu volum mare — dar complexitatea suplimentară de întreținut trebuie să merite clar beneficiul, nu doar „ca să fim siguri".

Dacă rulez deja pe MongoDB, are sens să adaug un vector database separat?

Nu neapărat — MongoDB Atlas are propria căutare vectorială integrată, cu aceeași logică de „nu adăuga un sistem nou dacă îl ai deja pe cel existent" ca la pgvector. Ghidul de RAG cu Next.js și Vercel AI SDK arată exact cum arată implementarea pe stack-ul ăsta, pas cu pas.

Cât de mare trebuie să fie un proiect ca să justifice Pinecone sau Weaviate față de o opțiune gratuită?

Nu e strict despre mărime, ci despre cât de mult din operare vrei să faci tu. O echipă de doi oameni, fără nimeni dedicat pe infrastructură, poate prefera Pinecone chiar și la volum mic, doar ca să elimine o grijă operațională. Invers, o echipă cu experiență DevOps poate rula Qdrant self-hosted la volum mare fără nicio problemă reală.

Contează dimensiunea embeddings-urilor la alegerea vector database-ului?

Da, indirect — dimensiuni mai mari (ex. 1536, tipic pentru multe modele de embeddings) înseamnă mai multă memorie și stocare per vector, deci cost mai mare la orice furnizor. Modelele mai noi de embeddings, cu dimensiuni mai mici dar calitate comparabilă, pot reduce costul de stocare fără să sacrifice recall-ul. Pentru cum se generează, de fapt, aceste vectori și de ce alegerea modelului contează, vezi cum funcționează embeddings și de ce contează pentru RAG.

Merită să testez toate patru înainte de a decide?

Pentru un proiect mic, un test rapid cu două opțiuni (de regulă pgvector și una dintre celelalte trei) e suficient ca să simți diferența de efort operațional. Un test complet cu toate patru rareori merită timpul, mai ales că răspunsul depinde mai mult de stack-ul și echipa ta decât de un benchmark generic.

Schimbarea vector database-ului mai târziu e un proiect mare?

Depinde de volum, dar rareori e trivial. Dacă ai păstrat embeddings-urile sursă separat (vezi secțiunea de mai sus), migrarea înseamnă re-indexare, nu re-generare de la zero — mult mai rapid. Fără acel pas de precauție, o migrare la volum mare poate însemna zile de procesare, nu ore.

Dacă ești încă la etapa de decizie pe stack, nu doar pe vector database, ghidul de implementare RAG cu Next.js și Vercel AI SDK arată o variantă completă, de la embeddings până la răspunsul generat. Restul categoriei de implementare și stack tehnic intră în detaliu pe alte piese ale aceluiași puzzle, iar serviciile AI și RAG sunt pasul următor dacă vrei ca alegerea asta să fie făcută pentru tine, pe cazul tău concret.