pgvector czy Qdrant — który hostować samodzielnie?

Jeśli już prowadzisz Postgresa (lub chcesz jednej bazy zarówno na dane aplikacji, jak i osadzenia), pgvector to wybór najmniejszego wysiłku — to tylko rozszerzenie. Jeśli masz miliony wektorów lub chcesz dedykowanego silnika z szybkim filtrowaniem, Qdrant jest wart osobnej usługi. Dla większości agentów na starcie pgvector na Postgresie w zupełności wystarcza.

Ile RAM potrzebuje baza wektorowa?

Więcej, niż byś zgadywał, bo dobre wyszukiwanie chce indeksu w pamięci. Zgrubna zasada: kilkaset tysięcy osadzeń mieści się spokojnie w 2 GB; gdy dojdziesz do niskich milionów, planuj 4 GB+ i dostrój indeks. Zacznij od 2 GB, obserwuj pamięć, zmień rozmiar, gdy wyszukiwanie zwalnia.

Dlaczego hostować magazyn wektorowy samodzielnie zamiast zarządzanego?

Dwa powody, dla których ludzie to robią: Twoje osadzenia często zawierają Twoje prywatne dane (notatki, dokumenty, treści klientów), a samodzielny magazyn trzyma to na serwerze, który kontrolujesz. I to stały koszt — zarządzana usługa wektorowa liczy za wektory i zapytania, podczas gdy VPS to jedna miesięczna liczba bez licznika na zapytanie.

Czy baza wektorowa i mój agent mogą działać na tym samym VPS?

Tak, dla małych i średnich obciążeń — współlokowanie agenta i instancji pgvector/Qdrant na jednej maszynie jest proste i tnie latencję do niemal zera. Rozdziel je na osobne serwery dopiero, gdy jeden zaczyna zagłodzać drugi z RAM, co jest miłym problemem na później, nie zmartwieniem na dzień pierwszy.

Czy osadzenia zajmują dużo dysku?

Pojedyncze osadzenie to kilka kilobajtów, więc milion z nich to kilka gigabajtów plus narzut indeksu — znaczące, ale nie ogromne. 25–45 GB dysku obejmuje pokaźny magazyn pamięci dla większości agentów. RAM, nie dysk, to zwykle pierwsze ograniczenie, na które trafiasz.

Hostuj bazę wektorową dla pamięci agenta AI na VPS

Agent AI bez pamięci utknął, przedstawiając się od nowa przy każdej rozmowie. Rozwiązaniem jest baza wektorowa — przechowuje osadzenia Twoich dokumentów, notatek lub przeszłych czatów, by agent mógł przywołać istotne fragmenty na żądanie (to „R” w RAG). Możesz wynająć to jako usługę zarządzaną albo uruchomić samodzielnie na VPS i trzymać dane — które często są Twoimi prywatnymi danymi — na maszynie, którą kontrolujesz. Oto jak i ile to faktycznie kosztuje w RAM.

Dwie dobre opcje

Nie potrzebujesz niczego egzotycznego. Dwie ścieżki obejmują prawie wszystkich:

pgvector — rozszerzenie Postgresa. Jeśli już prowadzisz Postgresa (lub chętnie), to dodaje wyszukiwanie wektorowe do bazy, którą już masz. Jedna usługa, jedna kopia zapasowa, SQL, który znasz. Start najmniejszego wysiłku z dużym zapasem.

Qdrant — dedykowany silnik wektorowy. Sięgnij po niego, gdy masz dużo wektorów (niskie miliony+) lub chcesz szybkiego filtrowania metadanych i dedykowanego API. To osobna usługa do prowadzenia, ale zbudowana dokładnie do tego zadania.

Dla większości agentów stających na nogi pgvector to właściwa pierwsza odpowiedź. Przejdź na Qdrant, gdy go przerośniesz, nie wcześniej.

Rzeczywistość RAM (to część, którą ludzie niedoceniają)

Wyszukiwanie wektorowe jest szybkie, bo indeks żyje w pamięci — więc RAM, nie dysk, to Twoje prawdziwe ograniczenie. Zgrubny przewodnik:

Kilkaset tysięcy osadzeń — wygodnie w 2 GB.
Niskie miliony — planuj 4 GB+ i dostrój indeks.
Dysk to łatwa część: milion osadzeń to tylko kilka GB, więc 25–45 GB obejmuje poważny magazyn.

Więc dobierz rozmiar pod indeks, nie plik. (Ta sama logika co ogólny przewodnik doboru — ciężka rzecz nie jest oczywista, aż zmierzysz.)

Szybki start: pgvector

Na maszynie z Postgresem (Docker jest najłatwiejszy — ten sam wzorzec co samodzielny hosting n8n):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- dopasuj do wymiarów swojego modelu osadzeń
);

-- gdy masz dane, zbuduj indeks dla szybkiego wyszukiwania:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

Twój agent wstawia content + jego osadzenie, potem odpytuje z ORDER BY embedding <=> $query_embedding LIMIT 5, by wyciągnąć najbliższe wspomnienia. To cała pętla.

Wolisz Qdrant? To pojedynczy kontener Docker udostępniający API HTTP/gRPC; tworzysz kolekcję z rozmiarem wektora i upsertujesz punkty. Ten sam pomysł, dedykowany silnik.

Czy może dzielić maszynę z agentem?

Tak — dla małych i średnich magazynów pamięci uruchom bazę wektorową na tym samym VPS co agent. Jest prostsza, a latencja jest w zasadzie zerowa. Rozdziel je na osobne serwery dopiero, gdy jeden zaczyna wypychać drugi z RAM. To późniejsza, miła-do-posiadania decyzja, nie na dzień pierwszy.

Uczciwe zastrzeżenia

RAM to ściana, i cicha. Wyszukiwanie pozostaje szybkie, aż indeks przestaje mieścić się w pamięci, potem się degraduje. Obserwuj pamięć i zmień rozmiar, zanim ugryzie — nie czekaj, aż wolne zapytania Ci powiedzą.
Osadzenia kosztują tokeny do utworzenia. Każdy dokument, który osadzasz, to wywołanie API do modelu osadzeń. Magazyn jest tani w hostowaniu; generowanie wektorów to koszt powracający — istotne dla tego, ile faktycznie kosztuje prowadzenie agenta.
Twórz kopię zapasową. Pamięć Twojego agenta to dane jak każde inne. Jeśli ma znaczenie, zrób migawkę.

W tych granicach samodzielny magazyn wektorowy to czysty sposób, by dać agentowi trwałą pamięć bez wręczania Twoich prywatnych danych osobie trzeciej. Zacznij od pgvector na maszynie 2 GB, miej oko na RAM i wyrastaj na Qdrant lub większy plan dopiero, gdy liczby Ci każą.