Databricks bringt Volltext- und Vektorsuche zu Lakebase Postgres

Databricks am 28. September 2026 führte Lakebase Search ein, eine integrierte Suchmaschine für seine Lakebase Postgres‑Datenbank, bereitgestellt über zwei Erweiterungen: lakebaseVektor für die Suche nach den nächsten Nachbarn und lakebasetext für BM25‑Volltextsuche. Beide Erweiterungen sind allgemein verfügbar auf AWS und Azure.

Die Erweiterungen ermöglichen Entwicklern, semantische, Schlüsselwort‑ und hybride Suche direkt in Postgres neben operationalen Daten auszuführen. Databricks sagte, traditionelle OLTP‑Systeme seien nicht für die Suchanforderungen von KI‑Agenten gebaut, die eine niedrige Latenz, hochpräzise Abrufe erfordern und oft massive parallele Suchen ausführen, und dass die Lösung dieses Problems bislang bedeutete, eine eigenständige Suchmaschine an die primäre Datenbank mit einer ETL‑Pipeline anzuhängen. Das Unternehmen sagte, es habe Lakebase Search zusammen mit dem Feedback von Hunderten von Beta‑Kunden entwickelt.

Benchmark‑Ergebnisse und die Conexiom‑Implementierung

Databricks sagte, lakebase_Vektor liefert die doppelte Durchsatzrate des zweitbesten Systems im VectorDBBench‑100M‑Benchmark, der den LAION‑Datensatz verwendet, und sei viermal günstiger als ein Cloud‑Postgres‑Anbieter, der pgvector nutzt, vor zusätzlichen Einsparungen durch Autoskalierung. Das Unternehmen berichtete eine P99‑Latenz von 71 Millisekunden bei 97 % Recall, was bedeutet, dass die Engine die wahren nächsten Nachbarn zu 97 % der Zeit erfolgreich abruft, und stellte fest, dass pgvector und DiskANN nur auf einer einzelnen großen Instanz getestet wurden.

Databricks berichtete außerdem über ein Kundenergebnis von Conexiom, das BM25‑Hybridsuche über mehr als 100 Millionen Zeilen mit halb so großem Rechenaufwand wie seine frühere pgvector‑Konfiguration ausführt. Die Infrastrukturkosten von Conexiom fielen um das Dreifache und der Durchsatz stieg im Vergleich zu pgvector um das Fünffache, sagte das Unternehmen.

“Lakebase Search bietet uns ein völlig neues Skalierbarkeitsniveau gegenüber pgvector und ermöglicht BM25 in derselben serverlosen Datenbank”, sagte Jordan Voves, AI/ML‑Architekt bei Conexiom. “Wir nutzen Lakebase, um Daten in großem Maßstab mit unseren Agenten zu verbinden.”

Die Pgvector‑Grenzen hinter dem Design

Databricks sagte, pgvector sei die am häufigsten installierte Erweiterung in Lakebase Postgres, und beschrieb drei wiederkehrende Schmerzpunkte, die bei Kunden beobachtet wurden, die es in großem Umfang einsetzen.

Der erste ist Kosten, die mit dem Datenvolumen statt mit der Nutzung skalieren. pgvector hält seinen HNSW‑Index im Datenbank‑Speicher, und da die HNSW‑Suche auf zufälligem Graph‑Durchlauf beruht, sinkt die Leistung um den Faktor 10 bis 50, sobald der Index auf die Festplatte auslagert und Abfragen zu Ketten zufälliger Lesevorgänge werden. Ein 768‑dimensionaler float32‑Vektor benötigt etwa 3,3 Kilobyte Speicher, sobald Graph‑Links und Postgres‑Overhead einbezogen sind, sodass ein Index über 100 Millionen Zeilen ungefähr 330 Gigabyte RAM erfordert, um resident zu bleiben, vollständig bereitgestellt, unabhängig davon, ob Abfragen ihn berühren oder nicht.

Der zweite ist die Indexwartung. Wenn ein Build auf die Festplatte auslagert, dauerte der Aufbau eines pgvector‑Index laut Databricks fast 50 Stunden auf einer Standard‑Cloud‑Instanz, und Schreibvorgänge leiden unter demselben Engpass, da das Einfügen eines Vektors einen zufälligen Durchlauf und die Modifikation mehrerer Graph‑Schichten erfordert. Da HNSW kein globales Rebalancing hat, bedeutet die Wiederherstellung der Suchqualität das Ausführen eines vollständigen REINDEX, einer Operation, die die Tabelle sperrt und Produktionsschreibvorgänge stoppt.

Der dritte ist, dass eine einzelne Abfrage nicht parallelisiert werden kann. Eine pgvector‑Abfrage wird von einem einzigen Postgres‑Backend‑Prozess ausgeführt, sodass der HNSW‑Index‑Scan keine Parallelisierung erhält. Einen höheren Recall zu erreichen erfordert das Durchlaufen mehrerer Graph‑Knoten, was zufällige Speicher‑Lesevorgänge und Distanzvergleiche hinzufügt, die Latenz erhöht und die Abfragen pro Sekunde reduziert, sodass das Skalieren des Durchsatzes das Hinzufügen von Datenbank‑Verbindungen oder Lesereplikaten bedeutet.

Wie Lakebase_vector aufgebaut ist

Lakebase Postgres trennt Speicher von Rechenleistung: permanente Daten liegen in kostengünstigem Cloud‑Objektspeicher, während RAM und lokales NVMe als kurzlebige Caches dienen, die den aktiven Arbeitssatz halten. Auf dieser Grundlage kombinierte Databricks zwei Techniken.

Hierarchisches IVF‑Clustering gruppiert Vektoren in Cluster, die als zusammenhängende Blöcke gespeichert werden. Eine Abfrage bewertet die Cluster‑Zentroiden im Speicher und liest anschließend nur die wenigen Blöcke, die vielversprechend erscheinen, als große sequentielle Lesevorgänge, anstatt viele zufällige Sprünge zu machen. Die binäre Quantisierung mittels der RaBitQ‑Methode komprimiert jeden Vektor auf etwa ein Bit pro Dimension, etwa 32‑mal kleiner als float32, sodass Abfragen kompakte Codes scannen, um Kandidaten vorzuselektieren und nur diese Vorselektion gegen Vollpräzisions‑Vektoren neu zu ranken.

Da das Design zustandslos ist, skaliert es auf Null, und im Ruhezustand zahlen Nutzer nur für den Speicher. Databricks berichtete, dass ein gemessener P90‑Wert von 1,13 Sekunden für die erste Abfrage nach dem Skalieren‑auf‑Null bei einem 100‑Millionen‑Vektor‑, 768‑dimensionalen Datensatz erzielt wurde, und sagte, dass 100 Millionen Vektoren auf einer einzigen Lakebase Compute Unit bedient werden können.

Der Indexaufbau trainiert die Cluster‑Zentroiden ein einziges Mal anhand einer kleinen Zufallsstichprobe; jeder Vektor wird dann seinem nächsten Zentroiden zugeordnet, quantisiert und als unabhängiger Vorgang in den entsprechenden Block geschrieben, sodass die Arbeit sich über alle verfügbaren Kerne verteilt. Databricks sagte, dass seine LTAP‑Architektur den Indexaufbau vom primären Datenbank‑System auf verteilte Engines wie Spark auslagert, wodurch die Build‑Zeit auf Minuten reduziert wird, und kündigte an, dass weitere Funktionen in diesem Bereich folgen werden. Da Prädikate bereits beim Block‑Scan angewendet werden, vermeiden gefilterte Abfragen das Über‑Abrufen von Kandidaten und halten den Recall hoch, und eine einzelne Abfrage wird über CPU‑Kerne parallelisiert.

BM25-Textsuche und hybride Abfragen

Databricks erklärte, dass die standardmäßige Postgres‑tsvector‑Suche keinen kontextweiten Relevanzbezug zum Korpus bietet. lakebase_text bewertet Begriffe anhand der globalen inversen Dokumenthäufigkeit, wobei seltene, hochintentionale Begriffe stärker gewichtet und häufige Füllwörter weniger. Außerdem prüft es obere Score‑Grenzen, während es den Index durchläuft, und verwirft ganze Posting‑Blöcke, die das Top‑K‑Ergebnis nicht beeinflussen können, was das Unternehmen laut eigener Aussage schneller macht als tsvector mit GIN‑Indizes.

Die Kombination beider Erweiterungen ermöglicht native hybride Suche innerhalb von Postgres: Eine einzelne Abfrage kann gewöhnliche SQL‑Filterprädikate anwenden, Live‑Operationstabellen joinen und die semantische Vektorbewertung mit der BM25‑Schlüsselwortrelevanz verbinden. Databricks sagte, das System skaliere von einer Zeile bis zu einer Milliarde Vektoren und von einer Abfrage pro Sekunde bis zu Tausenden, ohne manuelle Neu‑Provisionierung, und beschreibe das Design als für KI‑Agenten gedacht, deren Workflows innerhalb von Sekunden Tausende gleichzeitiger Abrufanfragen auslösen können.

Databricks positioniert Lakebase Search für Nutzer, die operative und Suchdaten in einer einzigen Datenbank konsolidieren möchten, während Databricks AI Search weiterhin die verwaltete Engine für Abruf ist, die sofort einsatzbereit funktioniert. Lakebase Search ist allgemein verfügbar auf AWS und Azure; bestehende Lakebase‑Nutzer können die Erweiterungen aktivieren, und neue Nutzer können sich für Lakebase anmelden.