-- Creăm tabela cu coloană de tip vector (1536 dimensiuni, specific OpenAI)
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE articole (
id serial PRIMARY KEY,
titlu text,
embedding vector(1536)
);
-- Căutare rapidă folosind distanța de cosinus (<=>)
SELECT id, titlu, 1 - (embedding <=> '[0.002, -0.015, 0.008]') AS similitudine
FROM articole
ORDER BY embedding <=> '[0.002, -0.015, 0.008]'
LIMIT 5;Salutare! Dacă te-ai jucat în ultima vreme cu LLM-uri și RAG (Retrieval-Augmented Generation), sigur te-ai lovit de problema stocării vectorilor. Pentru un side-project, să dai 70$ pe lună pe Pinecone e o nebunie curată, așa că am testat alternativele gratuite pe care le poți rula pe un VPS ieftin sau chiar pe calculatorul tău.
Am pus la bătaie trei soluții pe care le-am folosit în proiecte reale în ultimul an: pgvector, Qdrant și Chroma. Fiecare vine cu avantaje clare, dar și cu niște minusuri ascunse de care te lovești doar când începi să adaugi date reale.
pgvector: Când ai deja un Postgres în spate
Am avut un proiect cu 12.000 de articole de blog unde trebuia să implementez o căutare semantică simplă. În loc să complic infrastructura cu un nou serviciu în Docker, am activat extensia pgvector pe baza de date existentă. E genial de simplu pentru că nu ai de învățat un API nou. Faci query-uri SQL clasice, join-uri cu tabelele de utilizatori și ai totul într-un singur loc.
Dar există un trade-off major de care m-am lovit repede. La peste 50.000 de vectori de dimensiune 1536 (standardul de la OpenAI), Postgres începe să gâfâie serios dacă nu îi configurezi un index HNSW. Iar când construiești indexul ăla, consumul de RAM explodează pe server. Practic, pe un VPS de 4GB RAM, procesul de indexare mi-a blocat temporar restul aplicației. Dacă ai date puține, e perfect; dacă vrei să scalezi la milioane de vectori, Postgres devine o gaură neagră de resurse.
Qdrant: Performanță de Rust pe servere de doi lei
Dacă ai nevoie de viteză pură și resurse puține, Qdrant e preferatul meu. L-am instalat pe cel mai ieftin VPS de la Hetzner (vreo 4 euro pe lună) pentru un proiect de monitorizare de știri în timp real. În standby, containerul lor oficial de Docker mănâncă sub 60MB RAM. Este scris în Rust și se simte asta la fiecare query.
Ce îmi place la el este cum gestionează filtrarea hibridă. Poți să cauți vectori similari și să pui în același query un filtru pe metadate (de exemplu: "doar articole din categoria tech scrise în ultimele 24 de ore"). În pgvector, genul ăsta de query hibrid poate deveni extrem de lent. În Qdrant e aproape instantaneu datorită modului în care își indexează payload-ul. Partea proastă? Setup-ul inițial e puțin mai anevoios și API-ul lor, deși bine documentat, are o curbă de învățare dacă ești obișnuit doar cu bazele de date relaționale.
Chroma: Regele prototipurilor rapide în Python
Chroma e adorat de comunitatea de AI pentru că pornește din două linii de cod: import chromadb și gata, ai baza de date în memorie. E ideal pentru hackathoane, scripturi locale sau când vrei să validezi o idee rapid într-un notebook Jupyter.
Dar am pățit-o cu el când am încercat să-l mut în producție. Am vrut să scalez un scraper de documente și, pe la 30.000 de PDF-uri indexate, containerul de Docker pur și simplu a început să dea crash-uri din cauza lipsei de memorie (OOM). Managementul memoriei în Chroma (fiind un wrapper peste SQLite și hnswlib în spate) încă mi se pare destul de fragil pentru chestii serioase. E bun ca să începi, dar nu aș risca să-l folosesc pentru ceva ce rulează 24/7 cu trafic real.
Concluzia mea simplă
Dacă ai deja Postgres în stack și volumul de date e mic (sub 50k de înregistrări), mergi pe pgvector fără să clipești. Scapi de bătăi de cap cu deployment-ul și infrastructura nouă. Dacă proiectul tău e centrat complet pe căutare vectorială, ai date multe sau vrei să rulezi ieftin pe un server mic, Qdrant e regele neîncoronat. Pe ce variantă mergeți pentru proiectele voastre actuale?