Bazy wektorowe: Qdrant vs Weaviate vs pgvector vs Milvus

Gdy firma decyduje się wdrożyć RAG (Retrieval-Augmented Generation) nad dokumentacją firmową, pierwsza techniczna pytanie brzmi: gdzie przechowujemy wektory? Odpowiedź nie jest neutralna — wybór wpłynie na latencję odpowiedzi, miesięczne koszty infrastruktury, złożoność utrzymania oraz to, co będzie możliwe, a co niemożliwe, gdy wolumen danych się podwoi. W praktyce widzimy, że zespoły najczęściej sięgają po jedno z czterech rozwiązań: pgvector, Qdrant, Weaviate i Milvus. Każde ma inny zakres, inne mocne strony i inny kontekst, w którym ma sens.

Ten artykuł nie jest starciem benchmarkowym (publicznie dostępne benchmarki są z natury zależne od sprzętu, wymiarowości i wzorca obciążenia). To rama decyzyjna — jak wybrać na podstawie tego, czego firma naprawdę potrzebuje.

Co mają wspólnego wszystkie cztery

Wszystkie cztery rozwiązania obsługują wyszukiwanie approximate nearest neighbor (ANN) z indeksem HNSW, filtrowanie według metadanych i integrację ze standardowymi modelami embeddingów. Wszystkie są open-source (Apache 2.0 lub odpowiednik) z możliwością self-host lub zarządzanego wariantu chmurowego. Typowy wymiar embeddingu 1 024 lub 1 536 nie stanowi problemu dla żadnego z nich.

Różnica zaczyna się, gdy napotykamy skalę, wymagania co do spójności, istniejącą infrastrukturę lub potrzebę wyszukiwania hybrydowego (wektor + słowo kluczowe). W tych punktach cztery ścieżki się rozchodzą.

pgvector — gdy już masz Postgres

pgvector to rozszerzenie PostgreSQL. Nie istnieje jako samodzielna baza danych — działa wewnątrz istniejącej instancji PG. To jednocześnie jego najmocniejszy argument i główne ograniczenie.

Kiedy ma sens:

Jeśli firma obsługuje PostgreSQL, a wolumen wektorów nie przekracza rzędu kilkudziesięciu milionów, pgvector jest legitymowanym wyborem produkcyjnym. Zaleta jest fundamentalna: wektory, dane strukturalne i metadane żyją w jednej bazie danych, w ramach jednej transakcji, z jednym procesem tworzenia kopii zapasowych. Nie ma potrzeby synchronizacji między dwoma systemami, nie trzeba budować dodatkowej infrastruktury.

Wersja pgvector z początku 2026 roku dodała obsługę wektorów rzadkich i znacznie poprawiła wydajność indeksu IVFFlat. Z indeksem HNSW i odpowiednią konfiguracją baza danych na typowym serwerze obsłuży od 5 000 do 15 000 QPS przy zbiorze około 10 milionów wektorów o wymiarze 1 024. Dla zdecydowanej większości wdrożeń RAG B2B nad dokumentacją wewnętrzną jest to wystarczające.

Gdzie ma ograniczenia:

Przy zbiorze powyżej 50 milionów wektorów PG zaczyna napotykać ograniczenia architektury — rowstore zoptymalizowany pod obciążenia transakcyjne, a nie pod czysty throughput ANN. Wydajność spada, a skalowanie wymaga albo shardingu, albo przejścia na inne rozwiązanie. Kolejne ograniczenie: pgvector nie ma natywnego wyszukiwania hybrydowego — łączenie wyszukiwania wektorowego i pełnotekstowego wymaga ręcznego budowania pipeline, np. przez tsvector i ręczne RRF (Reciprocal Rank Fusion).

Typowy profil projektu: wewnętrzna baza wiedzy lub obsługa klienta, zbiór 1–5 milionów wektorów, zespół zarządzający istniejącym Postgresem i niechętny rozbudowie infrastruktury.

Qdrant — wydajność i self-host na jednym węźle

Qdrant to baza danych zbudowana od podstaw z myślą o wyszukiwaniu wektorowym. Napisana w Rust, z naciskiem na wydajność i proste wdrożenie self-host — binarka lub kontener Docker, bez zewnętrznych zależności.

Kluczowa właściwość wyróżniająca Qdrant w 2026 roku: natywna obsługa multi-vector w stylu ColBERT (late interaction), czyli możliwość przechowywania kilku wektorów dla jednego dokumentu i wyszukiwania przez ich interakcję. Umożliwia to retrieval na poziomie state-of-the-art bez zewnętrznego serwera rerankera — Qdrant obsługuje late interaction bezpośrednio w indeksie. Dla projektów, w których liczy się precyzja i nie chcemy budować osobnego serwisu reranking, to znacząca przewaga.

Charakterystyka wydajnościowa: przy 10 milionach wektorów, 1 024 wymiarach i obciążeniu około 1 000 QPS latencja P99 wynosi około 12 ms. Skaluje dobrze do setek milionów wektorów na jednym węźle przy odpowiedniej ilości RAM, ewentualnie przez zarządzaną usługę Qdrant Cloud dla większych instalacji.

Wyszukiwanie hybrydowe: Qdrant obsługuje wektory rzadkie (w stylu BM25) jako funkcję pierwszej klasy — gęsty wektor i rzadki wektor są przeszukiwane w jednym przebiegu, bez ręcznego mieszania wyników. Dla typowego scenariusza enterprise RAG (dokumentacja techniczna, katalogi produktów, instrukcje serwisowe) jest to idealne rozwiązanie — precyzyjne słowa kluczowe (numery części, kody, specyficzne terminy) przechwytuje gałąź rzadka, semantykę przechwytuje gałąź gęsta.

Kiedy ma sens:

Zespół chce rozwiązania self-host, przewidywalnej latencji, natywnego wyszukiwania hybrydowego i nie chce zarządzać rozproszonym klastrem. Zbiór może liczyć od milionów do setek milionów wektorów. Operatorzy z jedną osobą odpowiedzialną za infrastrukturę preferują proste wdrożenie.

Gdzie ma ograniczenia:

Przy naprawdę dużych zbiorach (miliardy wektorów) natywna dystrybucja jest ograniczona w porównaniu z Milvusem. Ekosystem konektorów integracyjnych jest mniejszy niż u Weaviate.

Weaviate — modułowe wyszukiwanie hybrydowe

Weaviate ma inną filozofię niż Qdrant: każda funkcja to moduł — generowanie embeddingów, indeksowanie słów kluczowych, reranking, wejście multimodalne. Odbiera to prostotę, ale daje dużą elastyczność bez pisania własnego kodu.

Kluczowa właściwość: natywne wyszukiwanie hybrydowe (BM25 + gęsty wektor + filtr metadanych) jako funkcja pierwszej klasy w API zapytań. Indeks BM25 i indeks wektorowy są zintegrowane w jednym planerze zapytań z automatyczną fuzją RRF. Weaviate wyróżnia się też bogatym API zapytań GraphQL, docenianym przez zespoły potrzebujące złożonego filtrowania (multi-tenant, prawa dostępu, hierarchiczne metadane).

Wydajność: orientacyjnie 25 000–50 000 QPS przy 10 milionach wektorów, latencja P99 około 16 ms. Koszty wariantu chmurowego (Weaviate Cloud) są wyższe niż Qdrant, ale zespół otrzymuje zarządzany reranking, monitoring i SLA.

Kiedy ma sens:

Wdrożenie multi-tenant (wielu klientów/działów w jednej instancji z izolowanymi danymi), potrzeba zaawansowanego filtrowania, zespół doceniający zarządzaną usługę z bogatszym ekosystemem. Dobry wybór także dla projektów z treścią multimodalną, gdzie moduł Weaviate do embeddingów obrazów oszczędza pisanie własnego kodu.

Gdzie ma ograniczenia:

Modularna architektura dodaje złożoność operacyjną — więcej konfiguracji, więcej punktów awarii. Dla prostego przypadku użycia RAG Weaviate jest przerostem formy nad treścią. Podejście schema-first (definiowanie typów przed indeksowaniem) może spowalniać prototypowanie.

Milvus — ekstremalnie duża skala

Milvus jest z pierwszej linii kodu zaprojektowany z myślą o dystrybucji. Działa na Kubernetes, z etcd do koordynacji, magazynem kompatybilnym z S3 do persystencji i oddzielnymi komponentami do ingestion, indeksowania i zapytań. Ta architektura jest narzutem dla małych projektów — i zaletą dla dużych.

Przy zbiorach liczących miliardy wektorów Milvus osiąga przepustowość 100 000+ QPS przy poziomym skalowaniu. Akcelerowane GPU wyszukiwanie ANN dodatkowo zmniejsza latencję przy dużych indeksach. Wersja zarządzana — Zilliz Cloud — przejmuje obciążenie operacyjne.

Kiedy ma sens:

Zbiór powyżej 100 milionów wektorów, wysokoprzepustowe obciążenie (personalizacja e-commerce, systemy rekomendacyjne, wyszukiwanie wektorowe w katalogu liczącym miliardy pozycji), zespół z zasobami DevOps do obsługi stosu Kubernetes.

Gdzie ma ograniczenia:

Dla typowego enterprise RAG z milionami wektorów Milvus to zbędny narzut. Minimalna instalacja produkcyjna wymaga kilku komponentów — klastra etcd, MinIO/S3, węzłów zapytań, węzłów danych. Dla jednoosobowego zespołu to za dużo infrastruktury do utrzymania. Wyszukiwanie hybrydowe istnieje, ale jest mniej płynne niż w Qdrant lub Weaviate.

Rama decyzyjna: trzy pytania przed wyborem

Zamiast porównania w tabeli (gdzie każda komórka wymaga kontekstu) zalecamy odpowiedź na trzy pytania w kolejności:

1. Jaki jest rozmiar zbioru teraz i za 2 lata?

• Do 5 milionów wektorów i istniejący Postgres → wypróbuj najpierw pgvector. Unikniesz nowej infrastruktury.
• Od 5 milionów do setek milionów → Qdrant lub Weaviate według poniższych kryteriów.
• Miliardy wektorów lub 100 000+ QPS → Milvus / Zilliz Cloud.

2. Ile osób zarządza infrastrukturą?

• Jeden programista lub mały zespół → Qdrant (proste wdrożenie self-host, binarka/Docker, minimalne zależności).
• Zespół z zasobami DevOps preferujący zarządzaną usługę → Weaviate Cloud lub Zilliz Cloud.
• Zespół natywny dla Kubernetes z doświadczeniem w systemach rozproszonych → Milvus.

3. Jaka jest struktura zapytań?

• Czysto semantyczne wyszukiwanie → każda z tych baz danych.
• Hybrydowe (precyzja słów kluczowych + semantyka) → Qdrant (rzadkie + gęste natywnie) lub Weaviate (BM25 + gęste natywnie). W przypadku pgvector wyszukiwanie hybrydowe trzeba złożyć ręcznie.
• Multi-tenant z izolowanymi danymi, złożone filtrowanie → Weaviate ma najbardziej zaawansowany planer zapytań.
• ColBERT / multi-vector late interaction → Qdrant w 2026 roku jako jedyny z czterech natywnie.

Liczby wydajnościowe w kontekście

Publicznie dostępne benchmarki (np. ann-benchmarks.com i inne publiczne porównania) wskazują orientacyjnie:

Przy obciążeniu około 1 000 QPS na zbiorze 10 milionów wektorów o 1 024 wymiarach:

• pgvector: maksymalnie 5 000–15 000 QPS, latencja P99 zmienna w zależności od sprzętu
• Qdrant: 30 000–80 000 QPS, P99 około 12 ms
• Weaviate: 25 000–50 000 QPS, P99 około 16 ms
• Milvus: 100 000+ QPS przy poziomym skalowaniu, P99 około 18 ms (konfiguracja rozproszona)

Liczby te są silnie orientacyjne — rzeczywiste wyniki zależą od wymiarowości wektorów, strategii indeksowania (parametrów HNSW), sprzętu (pamięć, CPU/GPU), wzorca obciążenia oraz tego, czy mamy do czynienia z obciążeniem single-tenant czy multi-tenant. Benchmark z innego projektu to tylko punkt wyjścia do własnych pomiarów.

Miesięczne koszty zarządzanych wariantów chmurowych przy typowym obciążeniu enterprise RAG (10 milionów wektorów, ~1 000 QPS) oscylują w rzędzie kilku tysięcy euro — ze znaczącymi różnicami w zależności od dostawcy i regionu. Self-host na własnym serwerze obniża koszty zmienne, ale dodaje stałe koszty operacyjne.

Gdzie pgvector pozytywnie zaskakuje

Jeden z najczęstszych mitów w środowisku firm SK/EU: „pgvector to tylko rozwiązanie przejściowe na PoC". W praktyce tak nie jest. U klientów z branży produkcyjnej i logistycznej widzieliśmy wdrożenia RAG na 2–3 milionach wektorów działające produkcyjnie na pgvector bez problemów, gdzie jedyną motywacją był istniejący klaster PostgreSQL i zespół bez przepustowości na nową infrastrukturę.

Klucz do dobrej wydajności pgvector w produkcji: indeks HNSW (nie IVFFlat), właściwa konfiguracja maintenance_work_mem przy budowaniu indeksu i partycjonowanie, gdy zbiór rośnie. Z tymi ustawieniami pgvector poradzi sobie z większością enterprise wewnętrznych scenariuszy RAG bez migracji.

Gdzie pgvector naprawdę nie wystarcza: zaawansowane wyszukiwanie hybrydowe, multi-vector / retrieval ColBERT oraz zbiory liczące dziesiątki milionów rekordów, gdzie wydajność warstwy retrieval ma krytyczne znaczenie dla UX (latencja poniżej 20 ms).

Integracja z frameworkami RAG

Wszystkie cztery bazy danych mają integrację pierwszej klasy w LlamaIndex i LangChain. LlamaIndex posiada natywne QdrantVectorStore, WeaviateVectorStore, PGVectorStore i MilvusVectorStore ze spójnym interfejsem — migracja między bazami to refaktoryzacja na poziomie jednej linii konfiguracji (nie całego pipeline).

W kwestii wyboru frameworka i oceny jakości pipeline RAG odsyłamy do artykułu RAG pipeline — 3 ustawienia jakości — tam szczegółowo omówiono strategie chunkowania, ulepszanie embeddingów i reranking, które są niezależne od wyboru bazy wektorowej.

Model embeddingów to osobna decyzja — w kwestii jego wyboru zob. Jak wybrać model embeddingów, a w kwestii kombinacji BM25 i wektorów w wyszukiwaniu hybrydowym zob. Hybrid search (BM25 + wektory + reranking).

Najczęstsze pytania

Czy mogę zacząć od pgvector i później migrować do Qdrant?

Tak, i jest to powszechny wzorzec. Abstrakcja vector store w LlamaIndex jest dostatecznie cienką warstwą — migracja wymaga ponownego zaindeksowania wektorów (reindeksowania dokumentów) i zmiany konfiguracji store. Logika pipeline, chunking i model embeddingów pozostają bez zmian. Jeśli oryginalne teksty i metadane przechowujesz w relacyjnej bazie danych, reindeksowanie to najczęściej skrypt, a nie miesiące pracy.

Czy Qdrant jest naprawdę szybszy niż Weaviate przy moim obciążeniu?

Zależy od wzorca obciążenia. Qdrant wykazuje przewagę w scenariuszach single-tenant z jednorodnym typem zapytań. Weaviate może być porównywalnie lepszy przy złożonym filtrowaniu multi-tenant, gdzie jego planer zapytań optymalizuje przecięcie filtra wektorowego i pełnotekstowego. Zalecamy przeprowadzenie własnego benchmarku na reprezentatywnej próbce danych — godzina pomiarów na własnym korpusie jest cenniejsza niż jakikolwiek publiczny benchmark.

Czy potrzebujemy Milvusa, jeśli mamy 50 milionów wektorów?

Prawdopodobnie nie. Qdrant i Weaviate radzą sobie z setkami milionów wektorów na dobrze skonfigurowanym serwerze z jednym węzłem. Milvus jest uzasadniony przy zbiorach liczących miliardy rekordów lub przy potrzebie 100 000+ QPS, gdzie architektura rozproszona naprawdę przynosi oszczędności. Przy 50 milionach wektorów Milvus to raczej narzut niż rozwiązanie.

Czy wybór bazy wektorowej wpłynie na jakość odpowiedzi RAG?

Bezpośrednio — w niewielkim stopniu. Jakość odpowiedzi zależy przede wszystkim od jakości chunkowania, modelu embeddingów i rerankera, a nie od tego, która baza danych przechowuje wektory. Pośrednio — tak: jeśli baza wektorowa ma wysoką latencję lub niski recall przy filtrowanym wyszukiwaniu, do modelu generatywnego trafiają gorsze fragmenty kontekstu. Wybór bazy wpływa przede wszystkim na wydajność, koszty i obciążenie operacyjne — nie na samą logikę pipeline retrieval.

Czy pgvector działa z polskim tekstem?

Tak — baza wektorowa jest językowo agnostyczna. Przechowuje i przeszukuje wektory niezależnie od języka. Właściwości językowe są odpowiedzialnością modelu embeddingów, a nie bazy danych. Dla języka polskiego polecamy wielojęzyczne modele takie jak BGE-M3 lub Qwen3-Embedding — więcej w artykule Jak wybrać model embeddingów.

*MP Industrial Solutions pomaga firmom zaprojektować i wdrożyć infrastrukturę RAG dopasowaną do rzeczywistego obciążenia — od oceny, czy pgvector nie wystarczy, po produkcyjne wdrożenie Qdrant lub Weaviate na serwerach on-prem. Jeśli rozważasz wdrożenie lub mierzysz się z problemami wydajnościowymi istniejącej warstwy wektorowej, chętnie umówimy się na wstępną rozmowę bez zobowiązań.*