Bazy wektorowe — pgvector, Pinecone, Qdrant czy Weaviate? Jak wybrać do RAG i pamięci AI

Baza wektorowa to magazyn, który przechowuje teksty (dokumenty, fragmenty wiedzy, pamięć agenta) jako embeddingi — wektory liczb — i błyskawicznie znajduje te najbardziej podobne znaczeniowo do zapytania. To fundament każdego systemu RAG i pamięci AI. Którą wybrać? Reguła według skali: do ~10 milionów wektorów najlepszym wyborem jest zwykle pgvector (rozszerzenie Postgresa, który prawdopodobnie już masz) — wektory żyją obok danych aplikacji i nie wprowadzasz nowej infrastruktury. Powyżej 10M, albo gdy wyszukiwanie wektorowe jest głównym obciążeniem, a nie dodatkiem — przejdź na dedykowaną bazę: Qdrant dla wydajności i filtrowania, Weaviate dla hybrid search, Milvus dla skali miliardowej, Pinecone gdy chcesz zero obsługi infrastruktury.

Kompletny przewodnik po bazach wektorowych: czym są i po co Ci w RAG, kiedy wystarczy pgvector w Postgresie, a kiedy potrzebujesz dedykowanej bazy, porównanie pgvector vs Pinecone vs Qdrant vs Weaviate vs Milvus (latency, koszt, skala), różnica między indeksami HNSW i IVFFlat, kod wdrożenia w pgvector, hybrid search i filtrowanie po metadanych oraz typowe błędy migracji.

Budujesz chatbota RAG na firmowej dokumentacji. Działa świetnie na 50 dokumentach w prototypie. Wdrażasz na 50 tysiącach — i nagle wyszukiwanie trwa sekundy, koszty bazy rosną szybciej niż ruch, a filtrowanie po dziale czy dacie nie działa tak, jak myślałeś. Problem nie jest w modelu. Problem jest w warstwie, którą wybrałeś pochopnie na starcie: w bazie wektorowej.

Ten wybór wraca w niemal każdym wpisie tej serii — przy RAG, przy pamięci agenta, przy self-hostingu — ale nigdy nie został opisany osobno. Czas to nadrobić. Ten artykuł pokazuje, jak działają bazy wektorowe, którą wybrać do swojej skali, czym różnią się indeksy, ile to realnie kosztuje i jak wdrożyć wszystko w praktyce — z kodem.

Czym jest baza wektorowa i po co Ci ona

Modele AI nie rozumieją tekstu wprost — zamieniają go na embeddingi, czyli wektory kilkuset–kilku tysięcy liczb, które kodują znaczenie. Zdania o podobnym sensie mają wektory blisko siebie w przestrzeni, nawet jeśli używają zupełnie innych słów. „Jaki jest okres wypowiedzenia" i „po ilu miesiącach mogę rozwiązać umowę" trafią obok siebie, mimo że nie mają wspólnego słowa kluczowego.

Baza wektorowa robi trzy rzeczy:

• Przechowuje embeddingi — wektory wraz z oryginalnym tekstem i metadanymi (źródło, data, dział, uprawnienia)
• Wyszukuje po podobieństwie — dla zapytania zamienionego na wektor znajduje top-K najbliższych wektorów w bazie (similarity search), zwykle miarą kosinusową
• Filtruje po metadanych — łączy wyszukiwanie semantyczne z twardymi warunkami („tylko dokumenty z 2026", „tylko dział HR")

To dokładnie ten mechanizm pobierania, na którym stoi RAG (opisany w artykule o budowie bazy wiedzy) i pamięć semantyczna agenta (artykuł o pamięci AI). Bez bazy wektorowej musiałbyś porównywać zapytanie z każdym dokumentem po kolei — przy tysiącach dokumentów to niewykonalne. Baza wektorowa z indeksem robi to w milisekundach.

pgvector vs dedykowana baza — pierwsza decyzja

Najważniejsza decyzja nie brzmi „Pinecone czy Qdrant", tylko „czy w ogóle potrzebuję dedykowanej bazy wektorowej". Dla większości firm odpowiedź brzmi: jeszcze nie. pgvector — rozszerzenie do PostgreSQL — pozwala trzymać wektory w bazie, którą prawdopodobnie już masz i obsługujesz.

Największą siłą pgvector nie jest wydajność, tylko integracja: wektory żyją obok danych aplikacji. Jedno zapytanie SQL łączy wyszukiwanie semantyczne z joinami do tabel użytkowników, zamówień czy uprawnień. Nie synchronizujesz dwóch systemów, nie utrzymujesz osobnej infrastruktury, nie płacisz za kolejny SaaS. Dla zbiorów poniżej 1M wektorów pgvector z indeksem HNSW dorównuje dedykowanym bazom, a przy odpowiednim tuningu radzi sobie do ~10M.

Dedykowana baza wektorowa zaczyna się opłacać, gdy:

• Przekraczasz ~10M wektorów — przy tej skali dedykowane silniki (Qdrant, Milvus) wygrywają wydajnością o rząd wielkości
• Wyszukiwanie wektorowe jest głównym obciążeniem — nie dodatkiem do aplikacji, ale jej rdzeniem; wtedy warto wyspecjalizowane narzędzie
• Potrzebujesz funkcji, których pgvector nie ma natywnie — zaawansowany hybrid search, skalowanie poziome (sharding), GPU, kwantyzacja wektorów
• Masz bardzo wysokie QPS — tysiące zapytań na sekundę przy wysokim recall

Praktyczna reguła: zacznij od pgvector, migruj na dedykowaną bazę dopiero, gdy konkretne ograniczenie Cię do tego zmusi. Przedwczesna migracja to klasyczny przykład rozwiązywania problemu, którego jeszcze nie masz.

Porównanie: pgvector, Pinecone, Qdrant, Weaviate, Milvus

Gdy już zdecydujesz, że potrzebujesz dedykowanej bazy (albo porównujesz świadomie), oto jak wypadają główni gracze w 2026:

Jak to czytać:

• Pinecone jest najłatwiejszy w obsłudze i opłaca się, gdy tempo developmentu przewyższa koszt infrastruktury — typowo dla startupów. Przy skali enterprise trudno go uzasadnić: ten sam workload na self-hosted Qdrant lub Milvus kosztuje 5–10× mniej
• Qdrant oferuje najniższą latency (~4 ms p50) i najlepszy free tier; świetny, gdy ważne jest filtrowanie po metadanych przy wyszukiwaniu
• Weaviate ma najlepszy hybrid search — łączenie podobieństwa wektorowego z dopasowaniem słów kluczowych w jednym zapytaniu
• Milvus to wybór na skalę miliardową: akceleracja GPU, sharding, ekstremalna przepustowość — ale wymaga najwięcej wiedzy DevOps

Indeksy HNSW vs IVFFlat — co wybrać

Sama baza to nie wszystko — kluczowy jest indeks, który decyduje o kompromisie między szybkością, trafnością (recall) a zużyciem pamięci. W pgvector (i w większości baz) masz dwie główne opcje:

Praktyczne wskazówki:

• HNSW to bezpieczny domyślny wybór dla aplikacji poniżej 1M wierszy — lepszy kompromis prędkość/recall, działa na pustej tabeli, dobrze znosi aktualizacje
• IVFFlat rozważ przy skali, gdy masz miliony wierszy ładowanych wsadowo i bardziej zależy Ci na szybkiej budowie indeksu i niższym zużyciu pamięci niż na maksymalnej prędkości zapytań
• Krytyczna pułapka produkcyjna: indeks IVFFlat nie należy do migracji schematu — należy do skryptów uruchamianych po załadowaniu danych. IVFFlat musi „nauczyć się" centrów klastrów na istniejących danych; zbudowany na pustej tabeli daje fatalny recall

Ile to realnie kosztuje

Koszt różni się dramatycznie wraz ze skalą i modelem hostingu. Orientacyjne wartości dla typowych konfiguracji:

Kluczowa obserwacja: przy 10M wektorów różnice są niewielkie (kilkadziesiąt dolarów), ale przy 100M przepaść się otwiera. Pinecone potrafi dobić do $700+/msc, podczas gdy self-hosted Milvus lub pgvector zostają poniżej $100. To dlatego managed SaaS opłaca się na starcie (oszczędzasz czas DevOps, gdy zespół jest mały), a self-hosting wygrywa przy skali (oszczędzasz pieniądze, gdy ruch rośnie).

Uwaga na ukryte koszty managed — rachunki za bazy wektorowe regularnie przekraczają budżet 2,5–4×, gdy nie pilnujesz wymiarowości embeddingów, liczby replik i nieużywanych indeksów. Embedding o 3072 wymiarach zajmuje dwa razy więcej niż 1536 — przy 100M wektorów to realna różnica w rachunku.

Jak wdrożyć — pgvector w praktyce

Najprostsza, produkcyjna konfiguracja: PostgreSQL z pgvector, tabela z embeddingami, indeks HNSW i zapytanie similarity search z filtrowaniem po metadanych. Cały setup to kilkanaście linii SQL:

-- 1. Wlacz rozszerzenieCREATE EXTENSION IF NOT EXISTS vector;-- 2. Tabela: tekst + embedding + metadane obok siebieCREATE TABLE documents (    id          bigserial PRIMARY KEY,    content     text NOT NULL,    dzial       text,    created_at  timestamptz DEFAULT now(),    embedding   vector(1536)   -- wymiar zalezy od modelu embeddingow);-- 3. Indeks HNSW (domyslny wybor do ~1M wierszy)CREATE INDEX ON documents    USING hnsw (embedding vector_cosine_ops);-- 4. Wyszukiwanie semantyczne + filtr po metadanych w jednym zapytaniu--    $1 = wektor zapytania z modelu embeddingowSELECT id, content, 1 - (embedding <=> $1) AS podobienstwoFROM documentsWHERE dzial = 'HR'                    -- twardy filtr po metadanych  AND created_at > now() - interval '1 year'ORDER BY embedding <=> $1             -- <=> to dystans kosinusowyLIMIT 5;Trzy rzeczy warte uwagi:- **Operator <=> to dystans kosinusowy** — pgvector ma też <-> (euklidesowy) i <#> (iloczyn skalarny); dla embeddingów tekstowych zwykle używasz kosinusowego- **Filtr WHERE działa razem z wyszukiwaniem** — to przewaga pgvector: łączysz semantykę z twardymi warunkami SQL bez żonglowania dwoma systemami- **vector(1536) to wymiar embeddingu** — musi pasować do modelu (OpenAI text-embedding-3-small: 1536, large: 3072); zmiana modelu = przebudowa kolumny

Wektory generujesz osobno — wywołaniem modelu embeddingów (OpenAI, Cohere, lub lokalnego przy self-hostingu z artykułu o Ollama/vLLM) — i wstawiasz do kolumny embedding. Reszta to zwykły SQL.

Hybrid search i filtrowanie po metadanych

Czyste wyszukiwanie wektorowe ma słaby punkt: gubi dokładne dopasowania. Gdy użytkownik szuka konkretnego numeru umowy „ORD-2026-0042" albo nazwy własnej, semantyka nie pomaga — potrzebujesz dopasowania słowa kluczowego. Rozwiązaniem jest hybrid search: połączenie wyszukiwania wektorowego (znaczenie) z wyszukiwaniem pełnotekstowym lub BM25 (dokładne słowa), a wyniki łączy się algorytmem typu Reciprocal Rank Fusion.

• Weaviate ma najlepszy natywny hybrid search spośród porównywanych baz — to jego główna przewaga
• Qdrant obsługuje hybrid search przez sparse + dense vectors
• pgvector łączysz z wbudowanym full-text search Postgresa (tsvector) — działa, ale wymaga ręcznego sklejenia wyników
• Filtrowanie po metadanych to osobna, równie ważna funkcja — ograniczenie wyszukiwania do dokumentów danego działu, daty czy poziomu uprawnień; krytyczne dla bezpieczeństwa (user nie powinien dostać w wynikach dokumentu, do którego nie ma dostępu)

Pisałem szerzej o hybrid search i rerankingu w artykule o zaawansowanym RAG — to tam te techniki dają największy skok jakości wyszukiwania.

Typowe błędy i migracja

• Przedwczesna migracja na dedykowaną bazę — postawienie Pinecone/Qdrant dla 50 tysięcy wektorów, które spokojnie zmieściłyby się w pgvector; dodajesz infrastrukturę i koszt bez korzyści
• IVFFlat na pustej tabeli — indeks zbudowany przed załadowaniem danych daje fatalny recall; buduj IVFFlat po wstawieniu danych, w skrypcie post-load, nie w migracji
• Niedopasowany wymiar embeddingu — kolumna vector(1536) i model zwracający 3072 wymiary to błąd przy wstawianiu; zmiana modelu embeddingów wymaga przebudowy kolumny i reindeksacji
• Ignorowanie kosztu wymiarowości — większe embeddingi to liniowo większy koszt pamięci i przechowywania; przy dużej skali rozważ mniejszy model embeddingów lub kwantyzację
• Brak filtrowania uprawnień — wyszukiwanie zwracające dokumenty bez sprawdzenia, czy użytkownik ma do nich dostęp, to wyciek danych; filtr po metadanych uprawnień jest obowiązkowy
• Mieszanie pamięci epizodycznej z semantyczną w jednym indeksie — opisane w artykule o pamięci AI; degraduje jakość wyszukiwania

Migracja z pgvector na dedykowaną bazę, gdy nadejdzie czas, jest prosta: eksportujesz wektory z metadanymi, importujesz do nowej bazy, przepinasz warstwę retrievalu w aplikacji. Ponieważ embeddingi już masz policzone, nie musisz ich generować od nowa — migrujesz dane, nie przeliczasz ich.

Checklist wyboru i wdrożenia bazy wektorowej

1. 1.Zacznij od pgvector, jeśli masz < 10M wektorów i już używasz Postgresa — nie dodawaj infrastruktury bez potrzeby
2. 2.Przejdź na dedykowaną bazę, gdy przekraczasz ~10M wektorów lub wyszukiwanie wektorowe jest głównym obciążeniem
3. 3.Wybierz dedykowaną według potrzeby: Qdrant (wydajność, filtrowanie), Weaviate (hybrid search), Milvus (skala 100M+), Pinecone (zero DevOps)
4. 4.Użyj indeksu HNSW jako domyślnego do ~1M wierszy — najlepszy kompromis prędkość/recall
5. 5.IVFFlat tylko przy dużych, wsadowo ładowanych zbiorach — i buduj go PO załadowaniu danych, nie w migracji schematu
6. 6.Dopasuj wymiar kolumny do modelu embeddingów (1536 / 3072) — niezgodność to błąd wstawiania
7. 7.Zaplanuj koszt według skali: managed na starcie (oszczędność czasu), self-host przy skali (oszczędność 5–10×)
8. 8.Pilnuj ukrytych kosztów: wymiarowość embeddingów, repliki, nieużywane indeksy — rachunki potrafią przekroczyć budżet 2,5–4×
9. 9.Dodaj filtrowanie po metadanych uprawnień — użytkownik nie może dostać w wynikach dokumentu, do którego nie ma dostępu
10. 10.Rozważ hybrid search, jeśli liczą się dokładne dopasowania (numery, nazwy własne), nie tylko semantyka
11. 11.Nie migruj przedwcześnie — rób to, gdy konkretne ograniczenie Cię zmusi, nie „na zapas"
12. 12.Przy migracji eksportuj policzone embeddingi — nie przeliczaj ich od nowa

Najważniejsze wnioski

Baza wektorowa to fundament RAG i pamięci AI — przechowuje teksty jako embeddingi i znajduje najbardziej podobne znaczeniowo. Najważniejsza decyzja to nie „który dostawca", tylko „czy w ogóle potrzebuję dedykowanej bazy": dla większości firm i zbiorów < 10M wektorów pgvector w Postgresie jest najlepszym startem, bo wektory żyją obok danych aplikacji. Dedykowaną bazę wybierz przy skali lub specjalnych wymaganiach: Qdrant (wydajność, ~4 ms), Weaviate (hybrid search), Milvus (skala miliardowa), Pinecone (zero DevOps). Używaj indeksu HNSW domyślnie; IVFFlat tylko przy dużych zbiorach wsadowych i nigdy na pustej tabeli. Planuj koszt według skali (managed na starcie, self-host 5–10× taniej przy skali), dopasuj wymiar embeddingu do modelu, dodaj filtrowanie uprawnień i nie migruj przedwcześnie.

---

Pomagam firmom wybrać, wdrożyć i zoptymalizować bazę wektorową pod RAG i pamięć AI — od decyzji pgvector vs dedykowana, przez dobór indeksów i modelu embeddingów, po hybrid search, filtrowanie uprawnień i optymalizację kosztów. Napisz do mnie — zaczynam od bezpłatnej 30-minutowej analizy Twojego przypadku.