Czy wektory embeddingów należy przechowywać w bazie PostgreSQL dzięki rozszerzeniu pgvector, czy powierzyć to zadanie dedykowanej bazie danych wektorowych? Przewodnik techniczny proponuje odpowiedź na to pytanie za pomocą pomiarów wydajności, a nie argumentów zasadniczych, porównując pgvector z Qdrant.
Dwie architektury, ten sam cel
pgvector to rozszerzenie open source dla PostgreSQL w wersji 0.8.6, kompatybilne z PostgreSQL 13 i nowszymi wersjami, według oficjalnego repozytorium GitHub. Dodaje do bazy typ kolumny dedykowany wektorom oraz wyszukiwania dokładne i przybliżone najbliższych sąsiadów. W praktyce embedding, czyli numeryczna reprezentacja treści w formie wektora, może być przechowywany w tej samej tabeli co dane, do których się odnosi, i zapytany za pomocą standardowego języka SQL. Proponowanych jest pięć funkcji odległości, w tym cosinus i iloczyn skalarny.
Dedykowana baza danych wektorowych to z kolei osobna usługa, wyposażona we własny silnik przechowywania i zaprojektowana wokół wyszukiwania wektorowego. Przewodnik wymienia między innymi Pinecone, Qdrant, Weaviate, Milvus i ChromaDB. Taki wybór architektury oznacza konieczność wdrożenia, monitorowania i tworzenia kopii zapasowych dodatkowego systemu oraz utrzymania jego synchronizacji z bazą zawierającą dane referencyjne.
Pomiary lokalne, a następnie na dużą skalę
Przewodnik proponuje test powtarzalny na laptopie, z Dockerem, Pythonem 3.10 lub nowszym oraz około 8 GB wolnej pamięci RAM. Zestaw danych jest syntetyczny: 100 000 wektorów o wymiarze 1536, czyli rozmiar typowego modelu embeddingów, załadowanych do obu systemów z tymi samymi parametrami indeksu HNSW. Na takim sprzęcie opóźnienia mieszczą się, według autora, w zakresie od kilku do kilkudziesięciu milisekund, z dużymi wahaniami zależnymi od procesora i dostępnej pamięci. Ta wielkość jest jednak zbyt mała, by wyciągać wnioski produkcyjne.
W tej kwestii przewodnik opiera się na badaniu opublikowanym przez Tiger Data. Dotyczy ono 50 milionów embeddingów Cohere o wymiarze 768, testowanych na maszynach AWS r6id.4xlarge (16 vCPU, 128 GB RAM) z zmodyfikowaną wersją narzędzia ANN-Benchmarks. Przewodnik podkreśla ważny punkt: test przeprowadzono z pgvector w połączeniu z pgvectorscale, rozszerzeniem Timescale dodającym inny typ indeksu, StreamingDiskANN, a nie z samym pgvector.
Według tych wyników, przy recall 99%, PostgreSQL z pgvectorscale osiąga 471,57 zapytań na sekundę, w porównaniu do 41,47 dla Qdrant. Mediana opóźnienia jest niemal identyczna: 31,07 ms wobec 30,75 ms. Qdrant wyróżnia się jednak na opóźnieniach ekstremalnych: jego p99 wynosi 38,71 ms, wobec 74,60 ms, a indeks zbudowano w 3,3 godziny, w porównaniu do 11,1 godziny. Według przewodnika oba systemy utrzymują się poniżej 100 ms na wszystkich mierzonych percentylach.
Jaki wybór w zależności od obciążenia
Przewodnik ocenia, że pgvector nadaje się do wolumenów do około 5–10 milionów wektorów, przy umiarkowanej konkurencji zapytań i gdy zespół ma już doświadczenie z PostgreSQL. Podkreśla też spójność transakcyjną między danymi relacyjnymi a wektorami, co pozwala na aktualizację dokumentu i jego wektora w jednej transakcji.
Z kolei dedykowana baza jest uzasadniona, według artykułu, dla wolumenów od kilkuset milionów do kilku miliardów wektorów lub przy ścisłych wymaganiach ekstremalnej latencji podczas bardzo obciążonych wyszukiwań filtrowanych, gdzie Qdrant wykazuje zmierzoną przewagę. Milvus jest wymieniany za przyspieszoną indeksację GPU, a Pinecone za w pełni zarządzaną usługę, bez konieczności wewnętrznej administracji.
