Jak wybrać bazę wektorową: Qdrant, pgvector i kryteria decyzji

Firma z 500 tys. fragmentów dokumentów i istniejącym Postgresem stoi przed pytaniem, które zadajemy sobie regularnie: czy nie proście dorzucić pgvector i skończyć temat w dwa dni, czy od razu postawić Qdrant? Odpowiedź zależy od kilku kryteriów, które rzadko pojawiają się razem w jednym artykule. Poniżej zebraliśmy je w jednym miejscu.

pgvector to rozszerzenie PostgreSQL, które dodaje typ danych vector i operatory podobieństwa (L2, cosinus, iloczyn skalarny). Wektory siedzą w tej samej bazie co reszta danych transakcyjnych (razem z tabelami klientów, zamówień i dokumentów). To duża zaleta operacyjna: jeden backup, jedno uprawnienie, jeden monitoring.

Dedykowana baza wektorowa (Qdrant, Weaviate, Milvus) to osobny proces zaprojektowany wyłącznie do przechowywania i przeszukiwania wektorów. Jej silnik indeksowania (zazwyczaj HNSW) jest zoptymalizowany pod kątem przybliżonego wyszukiwania sąsiedztwa (ANN) przy bardzo niskim opóźnieniu nawet na dziesiątkach milionów wektorów.

Różnica nie jest binarna; to spektrum kompromisów. pgvector od wersji 0.7.0 obsługuje indeks HNSW (wcześniej tylko IVFFlat), co znacząco zmniejszyło lukę wydajnościową. Przy 100-200 tys. wektorów i kilku zapytaniach na sekundę ta luka jest dziś pomijalna.

Skala korpusu. pgvector z indeksem HNSW trzyma się dobrze do ok. 1-2 mln wektorów na przeciętnym serwerze (16 GB RAM, 8 rdzeni). Powyżej tego progu czas budowania indeksu i zużycie pamięci zaczynają konkurować z innymi workloadami bazy. Qdrant zarządza pamięcią per-kolekcja i może trzymać część indeksu na dysku (mmap), skalując się do setek milionów wektorów bez wymiany serwera.

Filtrowanie metadanych (payload filtering). To punkt, w którym pgvector najczęściej przegrywa w praktyce. Filtrowanie WHERE category = 'hr' AND status = 'active' przed wyszukiwaniem wektorowym w pgvector to w rzeczywistości filtr post-ANN lub pełny skan z filtrem pre-ANN. Obydwa kosztują. Qdrant buduje odwrócone indeksy na polach payload i łączy je ze ścieżką HNSW, więc must: [{ key: "category", match: { value: "hr" } }] nie spowalnia zapytania. Jeśli Twój RAG musi izolować fragmenty po dziale, klientcie lub poziomie dostępu, filtrowanie payload jest kryterium krytycznym.

Zapytania hybrydowe (wektor + pełnotekst). pgvector nie ma wbudowanego BM25; trzeba go złożyć z tsvector Postgresa i scalić wyniki ręcznie (RRF lub własna logika). Qdrant od wersji 1.10 ma natywną obsługę wyszukiwania hybrydowego z rerankowaniem w ramach jednego wywołania API. Dla systemów, gdzie użytkownicy wpisują zarówno pytania naturalne, jak i numery dokumentów czy kody, hybryda jest ważna. Szczegóły opisujemy w artykule o hybrydowym wyszukiwaniu BM25 i wektorach.

Self-hosting vs SaaS i wymagania RODO. Obie opcje da się postawić na własnym serwerze. pgvector jest częścią Postgresa, więc jeśli masz już on-prem bazę i politykę retencji, dodanie rozszerzenia nie zmienia modelu zagrożeń. Qdrant Cloud (SaaS) wymaga umowy powierzenia danych (art. 28 RODO) i oceny DPO w zakresie data-residency. Dane embeddingów to nie PII, ale jeśli payload zawiera treści klientów, region przechowywania ma znaczenie. Qdrant Community Edition wdrożony lokalnie ma dokładnie taki sam profil RODO jak pgvector na własnym serwerze. Więcej o infrastrukturze zgodnej z RODO w artykule o self-hosted LLM a RODO.

Złożoność operacyjna i TCO. pgvector dodaje zero nowych komponentów do stosu: jeden serwis, jeden backup, jeden team. Qdrant to osobna usługa (container lub proces), własne metryki, własna aktualizacja. W małym zespole bez DevOps to realna różnica: nie tylko koszt licencji, ale czas utrzymania. Z drugiej strony Qdrant eksponuje gotowe endpointy Prometheus i dashboard kolekcji, co upraszcza observability przy dużych woluminach.

pgvector ma sens, gdy już masz Postgresa w firmie, Twój korpus mieści się w 500 tys. do 1 mln fragmentów, zapytania są proste (bez złożonego payload filtering) i nie chcesz dodawać nowego komponentu do infrastruktury. Wdrożenie sprowadza się do CREATE EXTENSION vector, dodania kolumny i zbudowania indeksu HNSW. Zespół może to zrobić w ciągu jednego dnia. Przy takim zakresie latencja zapytań wynosi 20-80 ms, co dla większości wewnętrznych asystentów wiedzy jest absolutnie wystarczające.

pgvector jest też naturalnym wyborem przy wyszukiwaniu semantycznym, gdy dane osobowe nie mogą opuszczać bazy transakcyjnej: embeddingen i payload zostają w tym samym silniku z tym samym modelem uprawnień.

Sygnały, że czas na Qdrant lub inną dedykowaną bazę:

• Korpus przekracza 2 mln fragmentów i czas budowania indeksu HNSW w pgvector przekracza okno maintenance.
• Potrzebujesz filtrowania payload przed wyszukiwaniem ANN, np. izolacja klientów w systemie multi-tenant, filtry po statusie dokumentu lub poziomie dostępu.
• Wdrażasz hybrydowe wyszukiwanie (wektor + BM25) i nie chcesz utrzymywać osobnej logiki scalania wyników.
• Chcesz izolować kolekcje per produkt lub per klient bez wpływu na wydajność zapytań innych kolekcji.
• Planujesz wiele równoczesnych operacji zapisu (reindeksacja przyrostowa co godzinę) i nie chcesz, żeby obciążały główną bazę transakcyjną.

Przy skalowaniu powyżej 5-10 mln fragmentów dedykowana baza to praktycznie jedyna sensowna opcja. Opisujemy to szerzej w artykule o przygotowaniu danych firmowych pod AI.

Jeśli zaczynacie od pgvector i po kilku miesiącach rośniecie powyżej progu, migracja jest prostsza niż się wydaje. Wektory to liczby zmiennoprzecinkowe. Eksport z pgvector do formatu JSON i reimport do Qdrant to kwestia jednego skryptu ETL. Schemat payload mapujecie raz. Cały proces dla 2 mln wektorów trwa 2-4 godziny. Wzorzec dual-index (stary pgvector + nowy Qdrant działają równolegle, ruch przenoszony stopniowo) minimalizuje ryzyko, podobnie jak przy migracji z API na własny model AI.

Tak, przy zbiorach do 1-2 mln fragmentów i indeksie HNSW (pgvector 0.7+) jest to w pełni produkcyjne rozwiązanie. Wiele firm wdraża RAG właśnie na pgvector, bo nie wymaga nowego komponentu infrastruktury. Ograniczenia pojawiają się przy zaawansowanym payload filtering i dużej skali; w tych przypadkach warto ocenić Qdrant.

Przy 500 tys. wektorów różnica jest pomijalna (oba mieszczą się w 20-60 ms na typowym serwerze). Przy 5 mln wektorów Qdrant z segmentami na dysku (mmap) utrzymuje 30-80 ms, podczas gdy pgvector może wchodzić w zakres 200-500 ms przy braku wystarczającego RAM. Zależy to silnie od konfiguracji serwera i parametrów ef_construction / m indeksu HNSW.

Tak, Qdrant Community Edition uruchamiany on-premises ma taki sam profil RODO jak pgvector na własnym serwerze: dane nie opuszczają infrastruktury, nie ma telemetrii wstecznej do producenta (w domyślnej konfiguracji). Qdrant Cloud (SaaS) wymaga osobnej oceny data-residency i umowy powierzenia. Kluczowe jest, że w payloadzie kolekcji nie powinny znajdować się dane osobowe w formie niezaszyfrowanej, niezależnie od wybranej bazy.

Qdrant Community Edition to oprogramowanie open-source bez opłat licencyjnych. Koszty wdrożenia to czas zespołu (1-3 dni na konfigurację, integrację API i testy), serwer (przy 2 mln wektorów BGE-M3 1024-dim potrzeba ok. 8-12 GB RAM dla indeksu HNSW) i czas utrzymania. Przy kolekcjach powyżej 10 mln wektorów warto rozważyć Qdrant Cloud lub dedykowaną maszynę. Kalkulator całkowitego kosztu wdrożenia znajdziesz w kalkulatorze ROI.

Tak i ma to sens w architekturze, gdzie dane transakcyjne (krótkie opisy, metadane) są w pgvector, a duże kolekcje dokumentów w Qdrant. Wzorzec dual-index jest też przydatny przy migracji: nowe fragmenty trafiają do Qdrant, stare zostają w pgvector do czasu pełnego reimportu. Oba systemy można odpytywać równolegle i scalać wyniki przez reranking.