Databricks Lakebase Search rzuca wyzwanie odrębnemu stosowi wyszukiwania

Databricks udostępnił Databricks Lakebase Search w wersji ogólnej na AWS i Azure, umieszczając dwa silniki wyszukiwania w swojej zarządzanej usłudze Postgres. Wydanie z 28 września obsługuje wyszukiwanie wektorowe i ranking słów kluczowych BM25 bez konieczności korzystania z oddzielnej bazy danych wyszukiwania. Podważa to znaną architekturę AI: Postgres przechowuje rekordy operacyjne, a inny system indeksuje ich kopie na potrzeby wyszukiwania.

Firma twierdzi, że jej nowe rozszerzenie wektorowe może przeszukiwać 100 milionów wektorów przy 97% recall i opóźnieniu P99 wynoszącym 71 milisekund. Deklaruje również dwukrotnie większą przepustowość niż kolejny najlepszy system w swoim benchmarku oraz czterokrotnie niższy koszt niż chmurowy Postgres z pgvector. Wyniki są znaczące, ale testy przeprowadził Databricks i nie opublikował pełnej niezależnej walidacji.

Szersza historia nie dotyczy kolejnego indeksu wektorowego. Databricks Lakebase Search jest próbą sprawienia, by operacyjny Postgres obsługiwał wyszukiwanie semantyczne, słów kluczowych i hybrydowe w skali agentów. Jeśli architektura sprawdzi się przy rzeczywistych obciążeniach produkcyjnych, część zespołów będzie mogła usunąć usługę wyszukiwania i otaczające ją potoki danych. Presja dotknie zarówno wdrożenia pgvector, jak i dedykowane systemy wyszukiwania, które uzasadniały swoją złożoność lepszą skalowalnością.

Databricks Lakebase Search przenosi wyszukiwanie do Postgresa

Wydanie zmienia wyszukiwanie z dołączonej usługi w zarządzaną funkcję operacyjnej bazy danych.

Ogłoszenie techniczne przedstawia dwa rozszerzenia Postgresa. lakebase_vector obsługuje przybliżone wyszukiwanie najbliższych sąsiadów, które znajduje wektory bliskie zapytaniu bez porównywania każdego możliwego rekordu. lakebase_text zapewnia BM25, metodę rankingu uwzględniającą częstotliwość terminów, długość dokumentu i rzadkość terminu w całym zbiorze.

Oba rozszerzenia są ogólnie dostępne dla projektów Lakebase na AWS i Azure. Deweloperzy mogą zainstalować dowolne z nich lub połączyć je na potrzeby wyszukiwania hybrydowego. To połączenie jest istotne, ponieważ wyszukiwanie wektorowe i po słowach kluczowych rozwiązuje różne problemy.

Wyszukiwanie wektorowe porównuje embeddingi, czyli numeryczne reprezentacje znaczenia. Może dopasować zapytanie takie jak „szybki samochód sportowy” do rekordów wspominających konkretny model auta, nawet jeśli te dokładne słowa nie występują. Wyszukiwanie po słowach kluczowych pozostaje lepsze dla identyfikatorów, nazw, kodów błędów, numerów produktów i innych terminów, których dosłowna forma niesie znaczenie.

Wyszukiwanie hybrydowe uruchamia obie metody i łączy ich rankingi. Agent wsparcia AI może użyć podobieństwa semantycznego, aby znaleźć koncepcyjnie powiązane incydenty, jednocześnie zachowując dokładne dopasowanie konkretnego kodu błędu. Agent e-commerce może zinterpretować intencję kupującego bez utraty wskazanego numeru modelu.

Operacje te działają obok rekordów transakcyjnych zamiast na oddzielnie zsynchronizowanej kopii. Deweloper może filtrować wyniki wyszukiwania na podstawie bieżących pól, takich jak tenant, status zapasów, prawa dostępu lub stan przepływu pracy. Databricks twierdzi, że lakebase_vector stosuje filtry podczas skanowania bloków indeksu, ograniczając potrzebę pobierania szerokiego zestawu kandydatów i późniejszego odrzucania nieautoryzowanych lub nieistotnych wierszy.

Ten projekt jest odpowiedzią na trwały problem systemów wyszukiwania. Najświeższa wersja rekordu często znajduje się w bazie danych aplikacji, podczas gdy wersja możliwa do przeszukiwania pojawia się później za pośrednictwem potoku ekstrakcji. Nawet krótkie opóźnienie może narazić agenta na usunięte dokumenty, nieaktualne uprawnienia lub zapasy, które już nie istnieją.

Utrzymywanie wyszukiwania blisko danych operacyjnych skraca to okno synchronizacji. Może również zmniejszyć liczbę systemów, które inżynierowie muszą monitorować, zabezpieczać i naprawiać. Zmiana jest szczególnie istotna dla zespołów budujących przeszukiwalną bazę wiedzy, gdzie kontrola dostępu i zmiany w dokumentach muszą pozostawać zgodne z wynikami wyszukiwania.

Lakebase Search nie eliminuje wszystkich etapów przemieszczania danych. Embeddingi nadal muszą być generowane, treść źródłowa może pochodzić spoza Postgresa, a tabele lakehouse wymagają synchronizacji przed obsługą zapytań. Różnica polega na tym, że aplikacje mogą odpytywać powstałe indeksy za pomocą znanych typów i operatorów Postgresa.

Databricks wiąże tę funkcję również z szerszą platformą lakehouse. Jego dokumentacja produktu wyjaśnia, jak tabele Unity Catalog mogą być synchronizowane z Lakebase. W trakcie tego procesu kolumna embeddingów może stać się wektorem Postgresa, podczas gdy tekst źródłowy może stać się tsvector, zoptymalizowaną reprezentacją PostgreSQL dla wyszukiwania tekstowego.

Bezpośrednia zmiana jest zatem konkretna. Lakebase oferuje teraz natywne zarządzane indeksy do wyszukiwania opartego na znaczeniu i dokładnych terminach, a aplikacje mogą odpytywać je obok pól operacyjnych. Napięcie zaczyna się wraz z pytaniem, co ta konsolidacja zastępuje.

Agenci AI wywierają presję na odrębny potok wyszukiwania

Obciążenia agentowe sprawiają, że błędy synchronizacji i niewykorzystywana infrastruktura są trudniejsze do uzasadnienia.

Tradycyjna architektura wyszukiwania zazwyczaj zawiera co najmniej dwa magazyny danych. Postgres rejestruje transakcje i stan aplikacji. Silnik wyszukiwania lub baza wektorowa otrzymuje przekształcone kopie przez potok ekstrakcji, transformacji i ładowania.

Taki podział może dobrze działać na dużą skalę, ale tworzy obowiązki operacyjne. Zespoły muszą wykrywać nieudane aktualizacje, ponownie przetwarzać brakujące rekordy, koordynować zmiany schematu, zachowywać semantykę usuwania oraz odtwarzać uprawnienia bazy danych w innym systemie. Potrzebują też planu odbudowy indeksów bez przerywania działania aplikacji.

Agenci AI wzmacniają te obowiązki, ponieważ wyszukiwanie staje się częścią pętli decyzyjnej. Zwykła strona wyszukiwania może tolerować niedoskonały wynik, gdy użytkownik przegląda alternatywy. Agent może podjąć działanie natychmiast po pobraniu rekordu, przez co aktualność i autoryzacja stają się bardziej istotne.

Agent zarządzający kontami ilustruje ten problem. Może semantycznie przeszukiwać notatki ze spotkań, dopasować dokładny identyfikator umowy i filtrować wyniki według bieżących uprawnień użytkownika. Jeśli te trzy sygnały znajdują się w różnych systemach, aplikacja musi je uzgodnić, zanim model będzie mógł bezpiecznie odpowiedzieć.

Ten sam problem występuje w handlu. Agent zakupowy może interpretować niejednoznaczne zapytanie za pomocą embeddingów, lecz dostępność i ograniczenia regionalne pochodzą z szybko zmieniających się kolumn operacyjnych. Przeszukiwanie nieaktualnej kopii może dać przekonującą odpowiedź dotyczącą niedostępnego produktu.

Gwałtowne skoki użycia tworzą kolejne źródło presji. Korporacyjne wyszukiwanie używane przez ludzi często podlega przewidywalnym godzinom pracy. Agenci mogą generować wiele równoległych wywołań wyszukiwania podczas planowania, weryfikowania i poprawiania zadania. Jedno żądanie użytkownika może uruchomić kilka wyszukiwań zamiast jednego.

Databricks zaprojektował Lakebase Search z myślą o tym nierównomiernym zapotrzebowaniu. Lakebase oddziela trwałe przechowywanie od mocy obliczeniowej, utrzymując dane w magazynie obiektowym i wykorzystując pamięć oraz lokalne NVMe jako pamięci podręczne. Moc obliczeniowa wyszukiwania może zostać wstrzymana w okresie bezczynności i wznowiona po nadejściu kolejnego zapytania.

Firma podaje opóźnienie P90 pierwszego zapytania wynoszące 1,13 sekundy po skalowaniu do zera na indeksie zawierającym 100 milionów wektorów o 768 wymiarach. Twierdzi również, że ten sam zbiór może być obsługiwany przez jedną Lakebase Compute Unit. Są to pomiary firmy, a nie uniwersalne oczekiwania, ale pokazują zamierzony model działania.

Jednosekundowe zimne zapytanie nie będzie odpowiednie dla każdej aplikacji interaktywnej. Może jednak być akceptowalne dla rzadko używanego wewnętrznego agenta, jeśli pozwala uniknąć ciągłego działania dużego klastra wyszukiwania. Zespoły mogą utrzymywać aktywną moc obliczeniową, gdy liczy się opóźnienie, i pozwalać cichszym środowiskom na wstrzymanie.

Tworzenie indeksów również odchodzi od głównej ścieżki transakcyjnej. Databricks twierdzi, że może trenować centroidy na próbce, rozdzielać przypisywanie i kwantyzację wektorów, a następnie zapisywać niezależne bloki indeksu. Przyszłe przeniesienie tych zadań do rozproszonych silników, takich jak Spark, jest częścią kierunku firmy, choć ogłoszenie sugeruje oczekiwanie na tę szerszą funkcję.

Ma to znaczenie, ponieważ duże kompilacje indeksów konkurują z obciążeniami transakcyjnymi, gdy zużywają te same zasoby procesora, pamięci i magazynu. Przeniesienie tej pracy poza główną bazę danych może zmniejszyć zakłócenia. Zmienia także model kosztowy: zamiast utrzymywać stale przydzielony serwer indeksu, płaci się za aktywną moc obliczeniową wyszukiwania i trwałe przechowywanie.

Celem presji nie jest każde wdrożenie dedykowanego wyszukiwania. Duże zespoły wyszukiwania często potrzebują wyspecjalizowanych analizatorów, niestandardowych potoków rankingu, zaawansowanej obserwowalności lub funkcji rozwijanych przez lata. Lakebase wywiera natomiast presję na powszechną architekturę, w której drugi system istnieje głównie dlatego, że wyszukiwanie w Postgresie przestało komfortowo się skalować.

To rozróżnienie utrzymuje ogłoszenie w realistycznych ramach. Databricks nie twierdzi, że jedna baza danych powinna obsługiwać każde obciążenie wyszukiwania. Twierdzi, że więcej aplikacji AI może odłożyć, uprościć lub uniknąć podziału.

Lakebase Vector Search celuje w model pamięciowy pgvector

Główna rywalizacja to oparte na magazynie Lakebase Search kontra wymagające dużej pamięci indeksy pgvector na dużą skalę.

Pgvector uczynił Postgresa praktycznym punktem wyjścia dla wyszukiwania semantycznego. Dodaje typy wektorowe, operatory odległości, wyszukiwanie dokładne i indeksy przybliżone, nie zmuszając deweloperów do korzystania z nieznanego interfejsu bazy danych. Pozostaje open source i jest szeroko dostępny w hostowanych usługach Postgres.

Jego standardowe opcje przybliżone obejmują HNSW i IVFFlat. HNSW tworzy wielowarstwowy graf łączący pobliskie wektory. Oferuje korzystną równowagę między szybkością a recall, ale konstrukcja grafu wymaga czasu, a indeks zużywa znaczną ilość pamięci. IVFFlat grupuje wektory w listy i przeszukuje najbardziej obiecujące grupy, zmniejszając koszty pamięci i budowy, choć zwykle oferuje niższą wydajność zapytań.

Własne wytyczne pgvector opisują te kompromisy. Zauważają, że indeksy HNSW budują się znacznie szybciej, gdy graf mieści się w maintenance_work_mem. Ostrzegają również, że zwiększanie liczby kandydatów wyszukiwania poprawia recall kosztem szybkości zapytań.

Databricks twierdzi, że ograniczenia te stają się trudniejsze, gdy graf HNSW przekracza pamięć jednej maszyny. Pobieranie łańcucha węzłów grafu ze zdalnego magazynu obiektowego może generować wiele małych, losowych odczytów. Projekt zoptymalizowany pod kątem pamięci rezydentnej staje się mniej wydajny, gdy aktywny zestaw danych jest zimny.

Wyszukiwanie wektorowe Lakebase wykorzystuje hierarchiczne klastrowanie z odwróconym plikiem, aby zmienić ten wzorzec dostępu. Wektory są grupowane w ciągłe bloki. Zapytanie najpierw ocenia centroidy klastrów, a następnie odczytuje bloki powiązane z najbardziej obiecującymi klastrami.

Rozszerzenie łączy ten układ z binarną kwantyzacją RaBitQ, która kompresuje każdy wektor do około jednego bitu na wymiar na potrzeby wstępnej oceny kandydatów. Databricks opisuje tę reprezentację jako około 32 razy mniejszą niż standardowy 32-bitowy wektor zmiennoprzecinkowy. System następnie ponownie klasyfikuje ograniczony zestaw kandydatów, wykorzystując wektory o pełnej precyzji.

Mechanizm ten sprawia, że indeks lepiej współpracuje zarówno z magazynem obiektowym, jak i lokalnym cache. Zimne zapytanie odczytuje kilka istotnych bloków zamiast podążać za setkami połączeń grafu. Ciepłe zapytanie może skanować kompaktowe kody binarne, zachowując jednocześnie mniejszy aktywny ślad w pamięci.

Databricks twierdzi, że pojedynczy indeks lakebase_ann może przechowywać ponad miliard wektorów. W dokumentacji firma podaje również, że budowanie indeksów jest od 50 do 100 razy szybsze niż HNSW. Liczby te opisują implementację firmy i nie należy automatycznie odnosić ich do każdego schematu, modelu embeddingów ani rozkładu filtrów.

W głównym benchmarku użyto 100 milionów wektorów ze zbioru danych LAION. Według Databricks Lakebase osiągnął dwukrotnie większą przepustowość niż kolejny najlepszy testowany system. Firma podała 97% recall przy P99 na poziomie 71 milisekund, co oznacza, że 99% zmierzonych zapytań zakończyło się w tym czasie opóźnienia, zwracając prawdziwych sąsiadów z deklarowaną skutecznością.

Benchmark posłużył też do sformułowania twierdzenia o czterokrotnie niższym koszcie względem nienazwanego dostawcy chmurowego Postgresa korzystającego z pgvector. Databricks zaznacza, że pgvector i DiskANN testowano na pojedynczych dużych instancjach. To zastrzeżenie ogranicza wartość porównania, ponieważ architektura, konfiguracja, sprzęt, współbieżność i założenia cenowe mogą istotnie zmienić wyniki.

Benchmark może pokazać, że dane podejście zasługuje na ocenę, ale nie rozstrzyga decyzji zakupowej. Databricks nie wykazał, że każde obciążenie pgvector powinno zostać zmigrowane. Mniejsze indeksy mogą wygodnie mieścić się w pamięci, a istniejąca instalacja pgvector może być tania, przenośna i łatwa w obsłudze.

Pgvector obsługuje również binary quantization, indeksowanie półprecyzyjne, skany iteracyjne, partycjonowanie i konfigurowalny wysiłek wyszukiwania. Zespoły z dostrojonymi wdrożeniami mają więcej opcji, niż sugeruje prosty wykres bazowy. Rozszerzenie open source działa w wielu środowiskach Postgresa, podczas gdy Lakebase Search należy do zarządzanej usługi Databricks.

Kompatybilność ogranicza jednak koszt migracji. Databricks twierdzi, że lakebase_vector wykorzystuje typy wektorów, operatory odległości i składnię zapytań pgvector. Aplikacja może zachować znajomy SQL, tworząc indeks lakebase_ann zamiast indeksu HNSW lub IVFFlat.

To celowy ruch konkurencyjny. Databricks nie prosi deweloperów o porzucenie modelu programowania pgvector. Oferuje inny silnik przechowywania i indeksowania pod w dużej mierze tym samym interfejsem.

Przykład klienta dostarcza jednego praktycznego sygnału. Conexiom przekazał Databricks, że prowadzi hybrydowe wyszukiwanie BM25 w ponad 100 milionach wierszy, wykorzystując połowę zasobów obliczeniowych wcześniejszej konfiguracji pgvector. Ten przykład jest użyteczny, ponieważ opisuje obciążenie operacyjne, pozostaje jednak wybraną przez dostawcę wypowiedzią klienta bez niezależnie opublikowanej metodologii.

Argumenty za wyszukiwaniem wektorowym Lakebase są najsilniejsze, gdy kolekcja jest duża, zapotrzebowanie na zapytania jest nieregularne, a filtry operacyjne mają znaczenie. Słabną, gdy zespoły priorytetowo traktują przenośność infrastruktury, mają przewidywalne stale aktywne zapotrzebowanie lub już spełniają cele opóźnień dzięki pgvector.

Natywne BM25 zmienia równanie wyszukiwania pełnotekstowego

Cichsza część premiery może być ważniejsza niż benchmark wektorowy.

Wiele produktów do wyszukiwania AI nadmiernie akcentuje embeddingi. Dopasowanie semantyczne pomaga, gdy użytkownicy i dokumenty wyrażają tę samą ideę innymi słowami. Jest mniej niezawodne, gdy zapytanie zawiera dokładny identyfikator, który model embeddingów traktuje jako słaby lub nieznany.

Rozważmy agenta szukającego „CVE-2026-1234”, numeru konta klienta albo konkretnej nazwy komponentu. Wyszukiwanie podobieństwa może zwrócić powiązane koncepcyjnie rekordy, pomijając znaczenie dokładnego ciągu. Ranking słów kluczowych dostarcza osobny sygnał wyszukiwania, który zachowuje dosłowne dopasowania.

Rozszerzenie lakebase_text w Lakebase dodaje indeks lakebase_bm25 zgodny z wartościami PostgreSQL tsvector i operatorami zapytań tekstowych. BM25 uwzględnia częstotliwość terminów w całej kolekcji oraz długość dokumentu, pomagając rzadkim terminom wnosić większy wkład niż terminom powszechnym.

PostgreSQL już zapewnia rozbudowaną funkcjonalność pełnotekstową. Potrafi analizować dokumenty, normalizować słowa, usuwać stop words, budować indeksy GIN i klasyfikować wyniki za pomocą ts_rank lub ts_rank_cd. Oficjalna dokumentacja rankingu wskazuje, że wbudowane funkcje rankingu wykorzystują częstotliwość leksykalną, bliskość i informacje strukturalne.

Funkcje te nie korzystają jednak z globalnych statystyk kolekcji w taki sam sposób jak BM25. Różnica ma znaczenie, gdy produkt potrzebuje trafności charakterystycznej dla wyszukiwarek, a nie prostego dopasowania. Zespoły historycznie dodawały własną logikę rankingu lub przenosiły tekst do dedykowanego silnika.

Databricks twierdzi, że lakebase_text wykorzystuje Block-Max WAND do wyszukiwania top-K. Algorytm ten pomija obszary, które nie mogą wygenerować wyniku konkurencyjnego wobec obecnie najwyższych ocen. Zamiast w pełni oceniać każdy pasujący dokument, silnik koncentruje pracę na kandydatach, którzy mogą wejść do żądanego zestawu wyników.

Podejście to uzupełnia wyszukiwanie wektorowe. Zapytanie do wsparcia technicznego mogłoby korzystać z lakebase_bm25 dla dokładnego tekstu błędu i z lakebase_ann dla semantycznie podobnych opisów incydentów. Reciprocal rank fusion może następnie połączyć obie uporządkowane listy bez zakładania, że ich surowe wyniki mają tę samą skalę.

W tym miejscu Databricks Lakebase Search staje się czymś więcej niż szybszym indeksem wektorowym. Oferuje stos wyszukiwania z dwoma odrębnymi modelami wyszukiwania w tej samej bazie danych. Wiersz operacyjny, embedding, reprezentacja tekstowa i atrybuty filtrowania mogą pozostać razem.

Ta konsolidacja wpływa na bezpieczeństwo w takim samym stopniu jak na wygodę. Aplikacja może wyrażać granice tenantów i kontrole uprawnień jako predykaty SQL obok wyszukiwania. Inżynierowie nadal muszą testować, czy każda ścieżka indeksu prawidłowo egzekwuje filtry, ale unikają odtwarzania całego modelu autoryzacji w osobnej usłudze.

Upraszcza to również zachowanie zapisów. Nowo wstawiony rekord może stać się wyszukiwalny bez oczekiwania, aż druga baza danych potwierdzi zdarzenie. Aktualizacje i usunięcia pozostają w znajomym środowisku transakcyjnym, choć czas utrzymania indeksów i zsynchronizowane źródła lakehouse nadal wymagają pomiarów.

Dedykowane silniki zachowują istotne zalety. Elasticsearch i podobne systemy obsługują szeroką analizę językową, niestandardowe punktowanie, agregacje, wyróżnianie, narzędzia do zapytań i kontrole operacyjne opracowane specjalnie dla wyszukiwania. Obsługa BM25 w Lakebase nie eliminuje tych różnic.

Znaczące porównanie ma zatem charakter architektoniczny. Jeśli aplikacja potrzebuje wyszukiwania semantycznego, rankingu dokładnych terminów, aktualnych filtrów operacyjnych i zwykłego SQL, Lakebase może obsłużyć większą część tego obciążenia w jednym miejscu. Jeśli samo wyszukiwanie jest produktem, wyspecjalizowane możliwości mogą nadal uzasadniać oddzielny system.

Benchmark pozostawia pytania produkcyjne bez odpowiedzi

Databricks pokazał atrakcyjny mechanizm, ale nabywcy nadal potrzebują dowodów specyficznych dla swoich obciążeń.

Największą niewiadomą jest niezależność benchmarku. Databricks wybrał systemy, konfiguracje, zbiór danych, typy instancji i założenia kosztowe stojące za opublikowanym porównaniem. Firma wskazuje VectorDBBench i zbiór LAION obejmujący 100 milionów wektorów, lecz ogłoszenie nie zawiera wystarczających szczegółów, aby odtworzyć każdy wynik wyłącznie na podstawie artykułu.

Recall i opóźnienia również wzajemnie na siebie wpływają. Wyszukiwanie przybliżone celowo unika wyczerpującego porównania, dlatego inżynierowie dostrajają liczbę klastrów lub kandydatów analizowanych przez zapytanie. Wyższy recall często wymaga więcej pracy. Pojedynczy punkt wydajności nie może opisać całej krzywej dla różnych docelowych poziomów recall.

Filtrowanie może ponownie zmienić tę krzywą. Rzeczywiste zapytania biznesowe mogą ograniczać wyniki według tenanta, geografii, czasu, stanu zapasów lub autoryzacji. Benchmark o równomiernym rozkładzie nie musi reprezentować wysoce selektywnych ani nierównomiernych filtrów produkcyjnych.

Znaczenie ma także kształt danych. Embeddingi obrazów z LAION różnią się od embeddingów dokumentów firmowych, katalogów produktów, kodu źródłowego czy rekordów klientów. Wymiary są różne, pojawiają się duplikaty, aktualizacje napływają nierównomiernie, a niektórzy tenanci dominują ruch. Każdy z tych czynników może wpłynąć na zachowanie pamięci podręcznej i jakość indeksu.

Wydajność zimnego startu zasługuje na ostrożną interpretację. Zgłoszone P90 na poziomie 1,13 sekundy dotyczy konkretnej konfiguracji 100 milionów wektorów o 768 wymiarach. Aplikacje o rygorystycznych celach interaktywnych mogą potrzebować aktywnych zasobów obliczeniowych zamiast skalowania do zera. Zespoły powinny testować zarówno pierwsze zapytanie, jak i następujący po nim burst.

Uwagę wymagają również ograniczenia operacyjne. Zgodnie z dokumentacją włączenie Lakebase Search restartuje wszystkie zasoby obliczeniowe w projekcie, zrywa aktywne połączenia i nie może zostać cofnięte. To sprawia, że aktywacja jest planowaną zmianą infrastrukturalną, a nie nieszkodliwym przełączeniem rozszerzenia.

Kolejnym kompromisem jest przenośność. Lakebase oferuje standardowe typy Postgresa i znajomą składnię pgvector, lecz jego nowe metody dostępu do indeksów są zastrzeżonymi, zarządzanymi możliwościami. Zespół może zachować znaczną część SQL aplikacji, jednocześnie uzależniając się od Databricks w zakresie zachowania indeksów, skalowania i cen.

Ta sama obawa dotyczy BM25. Standardowe kolumny tsvector pozostają rozpoznawalnymi obiektami Postgresa, ale indeks lakebase_bm25 i charakterystyka jego wykonania są specyficzne dla Lakebase. Odejście od tej platformy może wymagać przebudowania indeksów i ponownego przetestowania jakości rankingu w innym środowisku.

Twierdzenia kosztowe wymagają bezpośredniego pomiaru. Serverless suspension może obniżyć wydatki przy nieregularnym użyciu, lecz wysoka, utrzymująca się współbieżność może sprzyjać innemu modelowi. Generowanie embeddingów, zsynchronizowane tabele, przechowywanie, transfer danych i otaczające usługi Databricks składają się na całą architekturę.

Zespoły powinny zatem oceniać Lakebase Search na reprezentatywnych zapytaniach, a nie za pomocą ogólnego rankingu. Przydatny korpus testowy obejmuje bieżące rekordy, usunięte rekordy, dokumenty objęte kontrolą dostępu, rzadkie identyfikatory, niejednoznaczne zapytania w języku naturalnym oraz filtry najczęściej ograniczające recall.

Powinny także porównywać wyniki operacyjne. Należy mierzyć świeżość danych, odzyskiwanie po awariach, wpływ budowania indeksu, spójność uprawnień oraz czas pracy personelu potrzebny do zarządzania pipeline’ami. Usunięcie zewnętrznej usługi może być cenne, nawet jeśli surowe opóźnienie zapytań niewiele się zmieni.

Żadne z tych pytań nie podważa premiery. Definiują one, co „state of the art” musi oznaczać poza benchmarkiem dostawcy. Architektura ma wiarygodne uzasadnienie techniczne, lecz dowody produkcyjne muszą wykazać, że jej zalety utrzymują się przy rozkładzie danych i obciążeniu każdego nabywcy.

Na co zwracać uwagę po osiągnięciu przez Lakebase Search statusu GA

Trzy sygnały zdecydują, czy Lakebase Search stanie się domyślną funkcją Postgresa, czy pozostanie opcją specyficzną dla Databricks.

Pierwszym sygnałem jest odtwarzalna wydajność. Niezależne testy powinny porównać Lakebase z dostrojonym pgvector, usługami opartymi na DiskANN i dedykowanymi silnikami wyszukiwania dla kilku docelowych poziomów recall. Powinny publikować specyfikacje instancji, współbieżność, selektywność filtrów, stan pamięci podręcznej, czas budowania indeksu i kompletne założenia kosztowe.

Wyniki zbliżone do deklaracji Databricks wzmocniłyby argument, że wspierane przez storage indeksy klastrowe lepiej pasują do dużych kolekcji serverless niż grafy zorientowane na pamięć. Duża rozbieżność osłabiłaby narrację o wydajności, nawet jeśli konsolidacja nadal przynosiłaby korzyści operacyjne.

Drugim sygnałem jest adopcja wśród zespołów zastępujących architektury dwusystemowe. Conexiom dostarcza wczesnego przykładu, ale rynek potrzebuje więcej relacji opisujących skalę produkcyjną, częstotliwość aktualizacji, wolumen zapytań i modele uprawnień. Najbardziej przekonujące historie udokumentują usunięty klaster wyszukiwania lub pipeline ETL, a nie tylko udaną demonstrację.

Adopcja pokaże również, czy znajoma składnia Postgresa ogranicza tarcie migracyjne. Jeśli zespoły będą mogły zmieniać definicje indeksów przy zachowaniu modelu danych i zapytań, Lakebase Search będzie mieć praktyczną drogę do istniejących aplikacji. Jeśli migracje będą wymagały rozległych zmian rankingu, deklaracja kompatybilności będzie miała mniejszą wagę.

Trzecim sygnałem jest reakcja konkurencji. Pgvector nadal dodaje opcje kwantyzacji, filtrowania i skanów iteracyjnych. Dostawcy zarządzanego Postgresa mogą ulepszać architekturę pamięci masowej lub wprowadzać własne rozszerzenia wyszukiwania. Dedykowani dostawcy wyszukiwania mogą podkreślać dojrzałe mechanizmy kontroli rankingu, elastyczność wdrożeń i funkcje wyszukiwania hybrydowego.

Databricks zaczął pozycjonować Lakebase jako zarządzany Postgres dla aplikacji AI w swoim ogłoszeniu premiery z 2025 roku. To wydanie czyni to pozycjonowanie bardziej konkretnym. Same transakcje nie czynią bazy danych gotową na agentów, jeśli każde poważne zapytanie dotyczące wyszukiwania nadal opuszcza system.

Najważniejszy wniosek jest węższy, ale bardziej użyteczny. Databricks Lakebase Search zapewnia programistom jedno zarządzane miejsce dla rekordów operacyjnych, podobieństwa wektorowego, rankingu BM25 i filtrowania SQL. Jego klastrowany, skwantyzowany indeks wektorowy bezpośrednio odpowiada na model pamięci ograniczający duże wdrożenia pgvector.

Kolejna decyzja należy do zespołów inżynieryjnych. Zbudujcie reprezentatywny test wyszukiwania, uwzględnijcie ruch zimny i rozgrzany, zastosujcie rzeczywiste filtry uprawnień i porównajcie pełne obciążenie operacyjne. Jeśli Lakebase zachowa trafność wyników, jednocześnie eliminując infrastrukturę synchronizacji, uproszczenie architektury będzie ważniejsze niż jakikolwiek pojedynczy słupek benchmarku.