Databricks wprowadza wyszukiwanie pełnotekstowe i wektorowe do Lakebase Postgres

Databricks 28 września 2026, wprowadziło Lakebase Search, wbudowaną wyszukiwarkę dla swojej bazy danych Lakebase Postgres, udostępnioną poprzez dwa rozszerzenia: lakebasewektor do przybliżonego wyszukiwania najbliższego sąsiada oraz lakebasetext dla wyszukiwania pełnotekstowego BM25. Oba rozszerzenia są powszechnie dostępne w AWS i Azure.

Rozszerzenia umożliwiają programistom uruchamianie wyszukiwania semantycznego, słów kluczowych i hybrydowego bezpośrednio w Postgres, obok danych operacyjnych. Databricks stwierdził, że tradycyjne systemy OLTP nie zostały zaprojektowane pod wymagania wyszukiwania agentów AI, które potrzebują niskich opóźnień, wysokiej precyzji odzyskiwania i często wykonują masywne równoległe zapytania, a dotychczasowe rozwiązanie polegało na podłączeniu samodzielnej wyszukiwarki do głównej bazy danych za pomocą potoku ETL. Firma powiedziała, że zbudowała Lakebase Search w oparciu o opinie setek klientów beta.

Wyniki benchmarków i wdrożenie w Conexiom

Databricks poinformował, że lakebase_wektor zapewnia dwukrotnie wyższą przepustowość niż kolejny najlepszy system w benchmarku VectorDBBench 100M, który wykorzystuje zbiór danych LAION, oraz że jest czterokrotnie tańszy niż dostawca chmurowego Postgres używający pgvector, przed dodatkowymi oszczędnościami wynikającymi z autoskalowania. Firma zgłosiła opóźnienie P99 wynoszące 71 milisekund przy 97 % recall, co oznacza, że silnik skutecznie odtworzył prawdziwych najbliższych sąsiadów w 97 % przypadków, oraz zauważyła, że pgvector i DiskANN testowano jedynie na jednej dużej instancji.

Databricks podał również wynik klienta z Conexiom, który uruchamia hybrydowe wyszukiwanie BM25 na ponad 100 milionach wierszy przy połowie zużycia mocy obliczeniowej w porównaniu z wcześniejszą konfiguracją pgvector. Koszty infrastruktury Conexiom spadły trzykrotnie, a przepustowość wzrosła pięciokrotnie w stosunku do pgvector, jak poinformowała firma.

„Lakebase Search zapewnia nam zupełnie nowy poziom skalowalności w porównaniu z pgvector i odblokowuje BM25 w tej samej bezserwerowej bazie danych,” powiedział Jordan Voves, architekt AI/ML w Conexiom. „Używamy Lakebase, aby łączyć dane z naszymi agentami na dużą skalę.”

Ograniczenia pgvector stojące za projektem

Databricks stwierdził, że pgvector jest najczęściej instalowanym rozszerzeniem w Lakebase Postgres i opisał trzy powtarzające się problemy zgłaszane przez klientów korzystających z niego w dużej skali.

Pierwszym jest koszt, który rośnie wraz z wolumenem danych, a nie z ich użyciem. pgvector przechowuje swój indeks HNSW w pamięci bazy danych, a ponieważ wyszukiwanie HNSW opiera się na losowym dostępie do grafu, wydajność spada o czynnik od 10 do 50, gdy indeks przelewa się na dysk i zapytania zamieniają się w łańcuchy losowych odczytów. Wektor 768‑wymiarowy typu float32 zajmuje około 3,3 KB pamięci po uwzględnieniu połączeń grafowych i narzutu Postgres, więc indeks obejmujący 100 milionów wierszy wymaga około 330 GB RAM, aby pozostać w pamięci, przydzielony w całości niezależnie od tego, czy zapytania go używają.

Drugim problemem jest utrzymanie indeksu. Gdy budowa przelewa się na dysk, indeks pgvector potrzebował prawie 50 godzin na zbudowanie na standardowej instancji w chmurze, jak podał Databricks, a zapisy cierpią na ten sam wąski gardło, ponieważ wstawianie wektora wymaga losowego przeglądania i modyfikacji kilku warstw grafu. Ponieważ HNSW nie posiada globalnego równoważenia, przywrócenie jakości wyszukiwania wymaga pełnego REINDEX, operacji blokującej tabelę i zatrzymującej zapisy produkcyjne.

Trzecim problemem jest brak możliwości równoległego wykonania pojedynczego zapytania. Zapytanie pgvector jest realizowane przez jeden proces backendu Postgres, co pozostawia skanowanie indeksu HNSW bez jakiejkolwiek paralelizacji. Zwiększenie recall wymaga odwiedzania większej liczby węzłów grafu, co dodaje losowe odczyty pamięci i porównania odległości, podnosząc opóźnienie i zmniejszając liczbę zapytań na sekundę, więc zwiększanie przepustowości oznacza dodawanie połączeń do bazy danych lub replik odczytu.

Jak zbudowano Lakebase_vector

Lakebase Postgres oddziela przechowywanie od obliczeń: trwałe dane znajdują się w niskokosztowej chmurowej pamięci obiektowej, podczas gdy RAM i lokalne NVMe służą jako krótkotrwałe pamięci podręczne przechowujące aktywny zestaw roboczy. Na tej podstawie Databricks połączył dwie techniki.

Hierarchiczne grupowanie IVF grupuje wektory w klastry przechowywane jako spójne bloki. Zapytanie ocenia centroidy klastrów w pamięci, a następnie odczytuje tylko kilka bloków, które wydają się obiecujące, jako duże odczyty sekwencyjne zamiast wielu losowych skoków. Kwantyzacja binarna, wykorzystująca metodę RaBitQ, kompresuje każdy wektor do około jednego bitu na wymiar, czyli około 32‑krotnie mniejszego niż float32, dzięki czemu zapytania skanują zwarte kody, aby utworzyć krótką listę kandydatów i ponownie je ocenić względem wektorów o pełnej precyzji.

Ponieważ projekt jest bezstanowy, skaluje się do zera, a w stanie spoczynku użytkownicy płacą wyłącznie za przechowywanie. Databricks zgłosił zmierzone P90 wynoszące 1,13 s dla pierwszego zapytania po skalowaniu do zera na zestawie danych o 100 milionach wektorów, 768 wymiarach, i stwierdził, że 100 milionów wektorów może być obsłużonych na jednej jednostce obliczeniowej Lakebase Compute Unit.

Budowa indeksu trenuje centroidy klastrów jednorazowo na małej losowej próbce; każdy wektor jest następnie przypisywany do najbliższego centroidu, kwantowany i zapisywany do odpowiedniego bloku jako niezależna operacja, dzięki czemu praca rozprzestrzenia się na wszystkie dostępne rdzenie. Databricks powiedział, że jego architektura LTAP przenosi budowanie indeksów z głównej bazy danych na rozproszone silniki, takie jak Spark, skracając czas budowy do minut, i dodał, że w tej funkcji pojawią się kolejne ulepszenia. Ponieważ predykaty są stosowane podczas samego skanowania bloku, zapytania filtrowane unikają nadmiernego pobierania kandydatów i utrzymują wysoką czułość, a pojedyncze zapytanie jest równoległe na rdzeniach CPU.

Wyszukiwanie tekstowe BM25 i zapytania hybrydowe

Databricks powiedział, że standardowe wyszukiwanie tsvector w Postgresie nie zapewnia kontekstu istotności obejmującego cały korpus. lakebase_text ocenia terminy przy użyciu globalnej odwrotnej częstotliwości dokumentów, przyznając większą wagę rzadkim, o wysokim zamiarze, a mniejszą powszechnym słowom wypełniającym. Sprawdza także górne granice wyniku podczas przeglądania indeksu, odrzucając całe bloki postingów, które nie mogą wpłynąć na wynik top‑K, co firma twierdzi, że czyni je szybszymi niż tsvector z indeksami GIN.

Połączenie obu rozszerzeń umożliwia natywne wyszukiwanie hybrydowe w Postgresie: pojedyncze zapytanie może stosować zwykłe predykaty filtrów SQL, łączyć żywe tabele operacyjne i łączyć semantyczne ocenianie wektorów z istotnością słów kluczowych BM25. Databricks powiedział, że system skaluje się od jednego wiersza do miliarda wektorów oraz od jednego zapytania na sekundę do tysięcy bez ręcznego ponownego przydzielania zasobów, opisując projekt jako przeznaczony dla agentów AI, których przepływy pracy mogą wywoływać tysiące równoczesnych żądań pobierania w ciągu kilku sekund.

Databricks pozycjonuje Lakebase Search dla użytkowników, którzy chcą mieć dane operacyjne i wyszukiwania skonsolidowane w jednej bazie danych, podczas gdy Databricks AI Search pozostaje jego zarządzanym silnikiem do pobierania, który działa od razu. Lakebase Search jest dostępny ogólnie na AWS i Azure; istniejący użytkownicy Lakebase mogą włączyć rozszerzenia, a nowi użytkownicy mogą zarejestrować się w Lakebase.