Vector DB w 2025 — Qdrant vs Weaviate vs pgvector dla polskiej firmy

RAG wymaga bazy wektorowej. W 2023 to było egzotyczne, w 2025 — komponent stack-u tak oczywisty jak Redis. Ale wybór konkretnego rozwiązania dalej dzieli zespoły. Po 31 wdrożeniach RedAI (od 80-dokumentowych mini-baz po 4,2-milionowe korpusy faktur) mamy konkretne dane. Trzech kandydatów: Qdrant, Weaviate, pgvector. Każdy wygrywa w innym scenariuszu.

Kandydaci w skrócie

• Qdrant — dedykowana baza wektorowa napisana w Rust. Open-source, self-hostowalna, ma chmurę. Szybka, prosta w obsłudze.
• Weaviate — dedykowana baza wektorowa napisana w Go. Open-source z bogatym ekosystemem modułów (text2vec, generative).
• pgvector — rozszerzenie PostgreSQL. Twoje dane wektorowe siedzą obok zwykłych tabel. Mniej featurów, więcej prostoty.

Benchmark — 1 mln embeddingów, 1536 wymiarów

Decyzja — która skala czego wymaga

Mała skala (do 200k embeddingów)

Wszystkie trzy działają. Wybierz pgvector, jeśli masz już PostgreSQL — oszczędzasz operacyjne złożoności. Mniej kontenerów, mniej moving parts, taniej.

Średnia skala (200k–5M)

Qdrant. Najlepszy balans wydajności, latencji i prostoty. Z naszych 31 wdrożeń, 18 to Qdrant w tej skali. Bez awarii w trzy kwartały operacji.

Duża skala (5M+)

Qdrant lub Weaviate, w zależności od ekosystemu. Weaviate jeśli już używacie ich modułów generatywnych, Qdrant jeśli budujecie własny stack.

Filtry i metadata — gdzie się różnią

To często niedoceniany aspekt. W RAG dla biura księgowego trzeba filtrować "tylko faktury klienta X z 2024 roku" przed wyszukaniem wektorowym. Wszystkie trzy bazy to potrafią, ale jakość różna:

• Qdrant — pełnoprawne filtry z indeksami payload. Najszybsze pre-filtering.
• Weaviate — filtry GraphQL, bardziej rozbudowane, ale wolniejsze przy dużej liczbie warunków.
• pgvector — pełna moc SQL (JOIN-y, sub-queries), ale tylko z odpowiednimi indeksami.

Operacje — backup, monitoring, upgrade

Qdrant: snapshoty out-of-the-box, prosty monitoring przez Prometheus. Weaviate: backupy do S3, wbudowane health-checki. pgvector: standardowe procedury PostgreSQL (pg_dump, replikacja, streaming) — to ogromna zaleta, bo wasz DBA już to umie.

Polski kontekst — encoding i sortowanie

Wszystkie trzy bazy są agnostyczne językowo. Polski wpływa głównie przez wybór modelu embeddingowego (multilingual-e5, bge-m3, polski model SpeakLeash). Sama baza nie ma znaczenia. Sortowanie tekstu po polsku (locale pl_PL.UTF-8) ma znaczenie tylko w pgvector — bo tam wektory siedzą obok zwykłych tabel.

Praktyka: hurtownia elektroniki, 12 osób

4,2M embeddingów (opisy produktów, faktury, korespondencja). Wybrali pgvector, bo PostgreSQL już używali. Po 4 miesiącach: p99 latencja wzrosła do 220 ms, recall@10 spadł do 0,91. Przeszliśmy na Qdrant — p99 spadła do 38 ms, recall@10 wrócił do 0,97. Koszt infrastruktury wzrósł o 480 zł/mies., ale UX dla użytkowników znacząco lepszy.

Lista kontrolna wyboru

1. Czy macie już PostgreSQL? Tak → pgvector dla MVP.
2. Czy oczekujecie powyżej 1M embeddingów w roku? Tak → Qdrant od początku.
3. Czy używacie modułów Weaviate (text2vec, generative)? Tak → Weaviate.
4. Czy latencja p99 <50 ms to wymóg? Tak → Qdrant/Weaviate, nie pgvector.
5. Czy operacje musi prowadzić DBA bez wiedzy specjalistycznej? Tak → pgvector.

Podsumowanie

W RedAI domyślną rekomendacją dla nowych wdrożeń jest Qdrant, chyba że klient ma silne argumenty za pgvector (istniejący stack) lub Weaviate (ekosystem modułów). Wybór bazy wektorowej to decyzja na 2-3 lata, warto poświęcić tydzień na PoC. Możemy przeprowadzić benchmark na waszym konkretnym korpusie.