Databricks testet Lakebase Search mit einer echten Slide-App und zeigt, wo die Grenzen liegen

15. Oktober 2026, 02:06Quelle: Databricks

Databricks hat Benchmark-Ergebnisse für Lakebase Search veröffentlicht und dafür die interne App Slide Hub als Grundlage genutzt. Laut dem Unternehmen halten ein kleinerer Kandidatenpool und ein passend dimensionierter Dateicache die Hybridsuche schnell und senken zugleich die Zahl der gelesenen Seiten.

Das Wichtigste in Kürze

Lakebase Search führt Vektor- und BM25-Stichwortsuche als Postgres-Erweiterungen in der App-Datenbank aus und ist seit September allgemein verfügbar.
Bis 4 CU begrenzt die Datenbank den Durchsatz, ab 8 CU sind es die App-Worker.
Die Reduzierung der Kandidaten von 1.000 auf 200 erhält 90,5 % der Top-10-Ergebnisse und liest etwa ein Drittel der Seiten.
Ein 14-minütiger Lasttest mit 109.000 Anfragen verbrauchte 0,02 US-Dollar Rechenleistung; Databricks empfiehlt eine dauerhaft laufende Untergrenze von 0,5 CU für 31 bis 40 US-Dollar pro Monat.

Hybridsuche direkt in der App-Datenbank

Slide Hub ist eine interne Databricks-App, mit der Field Engineers Folien aus rund 700 internen Präsentationen finden und wiederverwenden. Eine Suchleiste findet einzelne Folien nach Bedeutung und nach Stichwort, und ein Server für das Model Context Protocol (MCP) bietet KI-Agenten dieselbe Suche. Die App speichert ihre Folien, Bewertungen, Such-Telemetrie und Änderungshistorie in Lakebase Postgres.

Lakebase Search ist laut Databricks seit September allgemein verfügbar. Es besteht aus Postgres-Erweiterungen, läuft also neben den Anwendungstabellen und erfordert nicht, Daten in ein separates Suchsystem zu kopieren. lakebase_vector speichert Embeddings und unterstützt den Index lakebase_ann für die approximative Nächste-Nachbarn-Suche. lakebase_text unterstützt den Index lakebase_bm25 für das Ranking nach Stichwörtern. Der ANN-Index nutzt IVF-Partitionierung und RaBitQ-Quantisierung, die jeden Vektor auf etwa 1 Bit pro Dimension komprimiert.

Die 23.000 Folienzeilen von Slide Hub liegen in derselben serverlosen Lakebase-Postgres-Instanz wie Bewertungen, Telemetrie, Änderungshistorie und Vorschaubilder. Eine einzige SQL-Anweisung setzt die gesamte Ranking-Logik um. Sie holt 200 Kandidaten je Methode, führt sie per Reciprocal Rank Fusion mit k=60 zusammen, wendet eine Ähnlichkeitsschwelle von 0,70 an und filtert die Ergebnisse auf Inhalte, die der Nutzer sehen darf.

Wo die Lastgrenze liegt

Eine Suchanfrage nutzt zwei getrennte Recheneinheiten: Lakebase Postgres und die Databricks-Apps-Compute, auf der der Webserver läuft. Im Test wurde jeweils nur eine Seite verändert, und die Zahl der simulierten Nutzer wurde schrittweise erhöht. Ergebnisse bei 500 Nutzern:

1 CU, MEDIUM-App mit 2 Workern: 196 Anfragen/s, p50 1,8 s
4 CU, MEDIUM-App mit 2 Workern: 219 Anfragen/s, p50 1,6 s
8 CU, MEDIUM-App mit 2 Workern: 336 Anfragen/s, p50 1,0 s
16 CU, MEDIUM-App mit 2 Workern: 349 Anfragen/s, p50 1,0 s
16 CU, LARGE-App mit 4 Workern: mindestens 662 Anfragen/s, p50 343 ms

Bis 4 CU ist die Datenbank der limitierende Faktor. Bei 1 CU benötigte die Suchanweisung im Schnitt 146 ms und las 14,9 Mio. Seiten aus dem Speicher, bei einem Dateicache von 1,5 GB. Bei 8 CU waren es im Schnitt 34 ms mit 12 GB Cache, und der Durchsatz stieg um rund 50 %. Ab 8 CU wird die App zum Engpass: 16 CU mit derselben MEDIUM-App brachten nur 4 % mehr. Bei 16 CU mit einer LARGE-App war der Lastgenerator die Grenze.

Der Connection Pool spielte dennoch eine Rolle. Bei 50 Nutzern erreichte die App ohne ihn 45 Anfragen/s und 2,4 s p95, mit ihm 85 Anfragen/s und 0,7 s p95. Der Embedding-Cache machte unter Last keinen messbaren Unterschied.

Kleinere Kandidatenpools, günstigere Kaltstarts

Die Zahl der Kandidaten pro Methode bestimmt, wie viele Seiten eine Abfrage berührt, und bei kaltem Cache damit die Latenz. Slide Hub wurde ursprünglich mit 1.000 Kandidaten ausgeliefert. Der Test maß 20 öffentliche Abfragen:

40 Kandidaten: kalt 127 ms, Wiederholung 5,0 ms, 5.655 Seiten, Top-10-Überlappung 74,5 %
100 Kandidaten: kalt 240 ms, Wiederholung 7,9 ms, 7.355 Seiten, Top-10-Überlappung 89 %
200 Kandidaten: kalt 387 ms, Wiederholung 11,7 ms, 10.401 Seiten, Top-10-Überlappung 90,5 %
1.000 Kandidaten: kalt 740 ms, Wiederholung 35,3 ms, 28.972 Seiten, Top-10-Überlappung 100 % (die Referenz)

Da Nutzer selten über 200 Ergebnisse hinaus blättern, liefert Slide Hub jetzt 200 aus. Gemessen Ende zu Ende von einem Job in derselben Cloud-Region dauerte eine kalte Suche mit 200 Kandidaten 2,9 s, eine wiederholte Suche 40 ms. Rund 1 s der Kaltzeit entfällt auf das Aufwecken des Endpunkts, und die erste Abfrage auf einer neuen Verbindung zahlt etwa 75 ms für die Planung.

Was das für Entwickler bedeutet

Laut Databricks sollte man zuerst die Abfrage dimensionieren, dann Lakebase Postgres skalieren, bis die App-Worker zum Engpass werden, und erst danach die App. Unterhalb von 8 CU hilft zusätzliche Datenbankkapazität, ab 8 CU helfen mehr App-Worker.

Bei den Kosten rechnet Lakebase Postgres Rechenleistung nur ab, solange sie läuft. Ein 14-minütiger Lasttest mit 109.000 Anfragen verbrauchte laut Databricks nur 0,02 US-Dollar an Lakebase-Postgres-Rechenleistung. Um Kaltstarts zu vermeiden, empfiehlt das Unternehmen als Produktionsbasis eine dauerhaft laufende Untergrenze von 0,5 CU für 31 bis 40 US-Dollar pro Monat. Die Quelle beschreibt außerdem Skalierungstests mit 1 bis 4 Mio. Zeilen des öffentlichen englischen MIRACL-Korpus, doch der vorliegende Text endet vor diesen Ergebnissen.