-- Setări optime pentru pgvector pe servere cu resurse mici (ex. 2GB RAM)
-- Reduce consumul de memorie în timpul construirii indexului HNSW
SET maintenance_work_mem = '256MB';
-- Creăm indexul HNSW optimizat pentru memorie scăzută
CREATE INDEX ON items
USING hnsw (embedding vector_cosine_ops)
WITH (
m = 8, -- Număr mai mic de conexiuni per nod (implicit e 16)
ef_construction = 32 -- Limitează spațiul de căutare la construire
);
-- Query de căutare hibridă (vectorial + filtru relațional)
SELECT id, title, 1 - (embedding <=> '[0.012, -0.043, ...]') AS similarity
FROM items
WHERE category_id = 42
ORDER BY embedding <=> '[0.012, -0.043, ...]'
LIMIT 5;Am observat că mulți colegi sar direct pe Pinecone când își încep un side-project cu AI, iar după două săptămâni își ating limita gratuită sau se trezesc cu factura. Am trecut prin exact aceeași poveste anul trecut, când lucram la un proiect personal de căutare semantică pe vreo 40.000 de documente tehnice. Voiam neapărat cost zero pe infrastructură, așa că am luat la mână cele mai populare trei opțiuni gratuite: pgvector, Qdrant și Chroma.
pgvector: Comoditate maximă, dar atenție la RAM
Dacă folosești deja PostgreSQL în proiect, pgvector pare alegerea evidentă. Dai un CREATE EXTENSION vector; și ești gata. Nu trebuie să administrezi un serviciu nou, iar join-urile între datele relaționale și embeddings se fac nativ într-un singur query SQL.
Am pus pgvector pe un VPS ieftin de 4€ la Hetzner (2GB RAM). Cât timp am avut sub 10.000 de vectori (dimensiune 1536, generați cu OpenAI), totul a mers brici chiar și fără index. Problema apare când volumul crește și vrei performanță de producție. Când am rulat generarea indexului HNSW (m=16, ef_construction=64), procesul de Postgres a crăpat instant cu Out Of Memory.
Trade-off: Este perfect dacă ai deja un Postgres pe un server decent (minimum 4GB RAM) și sub 50.000 de vectori. Dacă ești pe un VPS ieftin, crearea indexului HNSW îți va dărâma baza de date.
Qdrant: Campionul la self-hosting și free tier
Dacă vrei ceva dedicat, Qdrant e scris în Rust și se simte rapiditatea asta din prima secundă. L-am ridicat în Docker pe același server de 4€, iar la pornire consumă sub 50MB RAM.
Cel mai mare avantaj la Qdrant este opțiunea lor de Cloud Free Tier: îți oferă un cluster de 1GB RAM pe viață, fără să-ți ceară cardul de credit. În 1GB îți intru lejer în jur de 100.000 de vectori dacă activezi scalar quantization, fără să pierzi sesizabil din acuratețe. În plus, filtrările complexe după metadate (payload filtering) sunt extrem de rapide.
Trade-off: Ai încă un serviciu de mentionat și un API nou de învățat (gRPC sau REST), dar SDK-urile lor de Python și TypeScript sunt impecabile.
ChromaDB: Excelent pentru weekend, problematic în producție
Chroma este vizibil construit pentru prototipare rapidă. Dai pip install chromadb, scrii zece linii de cod și ai un RAG funcțional direct în memorie sau salvat pe disc într-un SQLite local.
L-am folosit la două hackathoane și își face treaba de minune. Totuși, când am încercat să mut un proiect bazat pe Chroma pe un container în server, am dat peste bătăi de cap cu persistența datelor și concurența la scriere. Când ai mai multe worker-e de API care încearcă să scrie simultan, SQLite-ul subiacent blochează procesele.
Trade-off: E cea mai rapidă cale de la idee la demo, dar devine rigid și greu de gestionat când vrei să scalezi sau să rulezi un setup distribuit.
Ce alegi în funcție de caz?
Dacă ai deja Postgres pe un server măcar mediu și vrei să păstrezi totul simplu, mergi pe pgvector. Dacă vrei doar un script Python pe laptopul tău de test, Chroma e cel mai comod. Însă pentru un side-project serios, cu costuri zero pe termen lung, recomandarea mea fermă este Qdrant (ori pe cloud-ul lor moca, ori Docker self-hosted).
Voi ce folosiți pentru vectori în proiectele personale și ce limite de memorie ați lovit până acum?