-- Creare index optimizat HNSW în PostgreSQL pentru embedding-uri OpenAI
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
content TEXT NOT NULL,
embedding vector(1536)
);
-- Creștem memoria temporar pentru a nu crăpa la indexare
SET maintenance_work_mem = '512MB';
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- Query cu calcul de distanță cosinus
SELECT id, content, 1 - (embedding <=> '[0.012, -0.023, ...]') AS similarity
FROM documents
ORDER BY embedding <=> '[0.012, -0.023, ...]'
LIMIT 5;Când vrei să bagi semantic search sau un pipeline de RAG într-un side-project, primul impuls e să sari direct pe Pinecone sau Weaviate Cloud. Nu face asta dacă nu ai buget alocat. Pe un proiect intern de căutare în documentație tehnică (cam 45.000 de chunks de text generate cu text-embedding-3-small de la OpenAI), am rulat și măsurat trei soluții complet gratuite.
Fiecare are bubele ei, dar una dintre ele e aproape întotdeauna alegerea corectă dacă ai deja o bază de date clasică.
pgvector: dacă ai deja PostgreSQL, ai terminat căutarea
Dacă rulezi deja un Postgres pe un VPS de la Hetzner sau folosești tier-ul gratuit de la Supabase, adăugarea extensiei pgvector e un simplu CREATE EXTENSION vector;. Cel mai mare avantaj aici nu e viteza absolută, ci simplitatea arhitecturală: ții datele relaționale, utilizatorii, permisiunile și vectorii în același loc, fără sincronizări între două baze de date.
Pe dataset-ul meu de 45.000 de vectori de 1536 de dimensiuni, un index HNSW a mâncat în jur de 320 MB de RAM. Timpul de interogare pe distanță cosinus a rămas undeva la 8-15ms pe o mașină modestă cu 2 vCPU.
Trade-off sincer: construirea indexului HNSW pe Postgres e lentă și mănâncă maintenance_work_mem serios. Dacă uiți să crești valoarea aia înainte de CREATE INDEX, procesul îți omoară serverul din Out of Memory.
Qdrant: performanță brută și filtrare avansată
Qdrant e scris în Rust și se simte din prima secundă. Au un free tier managed în cloud de 1GB storage (destul pentru vreo 150k vectori mici fără payload masiv) sau îl poți ridica local prin Docker într-un container care stă lejer în sub 200 MB RAM în repaus.
Unde bate Qdrant pe toată lumea e la filtrarea pe metadate combinată cu vector search. Dacă ai condiții de genul „caută vectori similari, dar doar pentru user_id = 123 și created_at > ieri”, Qdrant face payload-based pre-filtering incredibil de rapid. Pe același set de date, latența a fost constant sub 5ms.
Trade-off sincer: ai încă un serviciu de infrastructură de administrat, încă un endpoint de monitorizat și backup-uri separate de logica ta principală.
Chroma: drăguț pentru prototipuri, problematic la volum
Chroma a prins popularitate prin toate tutorialele de LangChain și LlamaIndex pentru că pornește la cheie în Python cu trei linii de cod, salvând datele local prin SQLite și DuckDB.
Pentru un script de weekend sau o aplicație desktop locală, își face treaba. Dar când l-am pus într-un Docker container și am încercat să inserez 30.000 de vectori în batch-uri fără pauză, consumul de memorie s-a dus inexplicabil la 2.8 GB și serverul a crăpat. Varianta client-server a progresat mult în ultimele versiuni, dar încă se simte ca un proiect gândit pentru Jupyter Notebooks, nu pentru producție continuă.
Ce alegi în practică?
Regula mea e simplă după testele astea:
- Dacă ai deja Postgres în stack: bagă
pgvectorfără să clipești. Filtrele SQL standard bat orice integrare externă. - Dacă construiești un sistem dedicat de căutare hibridă sau search engine cu payload mare: instalează Qdrant.
- Chroma: strict dacă faci demo-uri locale și nu vrei să deschizi Docker.
Voi ce folosiți în side-projects ca să evitați facturile aberante de cloud?