Databricks Lakebase Search stellt den separaten Search-Stack infrage
Databricks hat Databricks Lakebase Search auf AWS und Azure allgemein verfügbar gemacht und integriert damit zwei Suchmaschinen in seinen verwalteten Postgres-Dienst. Das am 28. September veröffentlichte Angebot unterstützt Vektor-Retrieval und BM25-basierte Keyword-Rangfolgen, ohne eine separate Suchdatenbank zu erfordern. Das stellt eine vertraute KI-Architektur infrage: Postgres speichert operative Datensätze, während ein anderes System Kopien für das Retrieval indexiert.
Das Unternehmen erklärt, seine neue Vektorerweiterung könne 100 Millionen Vektoren mit 97 % Recall und einer P99-Latenz von 71 Millisekunden durchsuchen. Außerdem beansprucht es in seinem Benchmark den doppelten Durchsatz des nächstbesten Systems sowie viermal niedrigere Kosten als Cloud-Postgres mit pgvector. Diese Ergebnisse sind beachtlich, doch Databricks hat die Tests selbst durchgeführt und keine vollständige unabhängige Validierung veröffentlicht.
Die größere Geschichte ist nicht ein weiterer Vektorindex. Databricks Lakebase Search ist ein Versuch, operatives Postgres semantisches, keyword-basiertes und hybrides Retrieval im Agentenmaßstab bewältigen zu lassen. Wenn die Architektur unter realen Produktions-Workloads funktioniert, können einige Teams einen Suchdienst und die ihn umgebenden Datenpipelines entfernen. Der Druck richtet sich sowohl auf pgvector-Deployments als auch auf dedizierte Suchsysteme, die ihre Komplexität bislang durch überlegene Skalierung rechtfertigten.
Databricks Lakebase Search verlagert Retrieval in Postgres
Die Veröffentlichung macht Suche von einem angebundenen Dienst zu einer verwalteten Fähigkeit der operativen Datenbank.
Die technische Ankündigung stellt zwei Postgres-Erweiterungen vor. lakebase_vector übernimmt die Suche nach näherungsweisen nächsten Nachbarn, bei der Vektoren nahe einer Abfrage gefunden werden, ohne jeden möglichen Datensatz zu vergleichen. lakebase_text bietet BM25, eine Ranking-Methode, die Termhäufigkeit, Dokumentlänge und die Seltenheit von Begriffen in einer Sammlung gewichtet.
Beide Erweiterungen sind für Lakebase-Projekte auf AWS und Azure allgemein verfügbar. Entwickler können eine der Erweiterungen installieren oder sie für hybrides Retrieval kombinieren. Diese Kombination ist wichtig, weil Vektor- und Keyword-Suche unterschiedliche Fehlerfälle lösen.
Die Vektorsuche vergleicht Embeddings, also numerische Repräsentationen von Bedeutung. Sie kann eine Anfrage wie „schneller Sportwagen“ mit Datensätzen zu einem Automodell abgleichen, auch wenn diese exakten Wörter dort nicht vorkommen. Die Keyword-Suche bleibt besser für Kennungen, Namen, Fehlercodes, Produktnummern und andere Begriffe geeignet, deren wörtliche Form Bedeutung trägt.
Die hybride Suche führt beide Methoden aus und führt ihre Rangfolgen zusammen. Ein KI-Support-Agent könnte semantische Ähnlichkeit nutzen, um konzeptionell verwandte Vorfälle zu finden, und zugleich eine exakte Übereinstimmung für einen bestimmten Fehlercode bewahren. Ein E-Commerce-Agent könnte die Absicht eines Käufers interpretieren, ohne eine gewünschte Modellnummer zu verlieren.
Diese Operationen laufen neben Transaktionsdaten, statt auf einer separat synchronisierten Kopie zu arbeiten. Ein Entwickler kann das Retrieval anhand aktueller Felder wie Mandant, Lagerstatus, Zugriffsrechten oder Workflow-Status filtern. Databricks zufolge wendet lakebase_vector Filter beim Scannen von Indexblöcken an. Dadurch verringert sich die Notwendigkeit, zunächst eine breite Kandidatenmenge abzurufen und anschließend nicht autorisierte oder irrelevante Zeilen zu verwerfen.
Dieses Design zielt auf ein dauerhaftes Problem von Retrieval-Systemen. Die aktuellste Version eines Datensatzes liegt häufig in der Anwendungsdatenbank, während die durchsuchbare Version erst später über eine Extraktionspipeline eintrifft. Selbst eine kurze Verzögerung kann dazu führen, dass ein Agent gelöschte Dokumente, veraltete Berechtigungen oder nicht mehr verfügbare Bestände sieht.
Wenn Retrieval näher an den operativen Daten bleibt, verkürzt sich dieses Synchronisationsfenster. Außerdem kann sich die Zahl der Systeme verringern, die Entwickler überwachen, absichern und reparieren müssen. Besonders relevant ist das für Teams, die eine durchsuchbare Wissensbasis aufbauen, bei der Zugriffskontrollen und Dokumentänderungen mit den Suchergebnissen abgestimmt bleiben müssen.
Lakebase Search beseitigt nicht jeden Schritt der Datenbewegung. Embeddings müssen weiterhin erzeugt werden, Quellinhalte können außerhalb von Postgres entstehen, und Lakehouse-Tabellen müssen vor der Bereitstellung synchronisiert werden. Der Unterschied besteht darin, dass Anwendungen die entstehenden Indizes über vertraute Postgres-Typen und -Operatoren abfragen können.
Databricks verknüpft die Funktion zudem mit seiner umfassenderen Lakehouse-Plattform. Die Produktdokumentation erläutert, wie Unity Catalog-Tabellen in Lakebase synchronisiert werden können. Dabei kann eine Embedding-Spalte zu einem Postgres-Vektor werden, während Quelltext zu einem tsvector wird, der optimierten PostgreSQL-Repräsentation für Text-Retrieval.
Die unmittelbare Veränderung ist daher konkret. Lakebase bietet nun native verwaltete Indizes für bedeutungsbasierte und exakte Begriffssuche, und Anwendungen können sie neben operativen Feldern abfragen. Die Spannung beginnt bei der Frage, was diese Konsolidierung ersetzt.
KI-Agenten setzen die separate Suchpipeline unter Druck
Agenten-Workloads machen Synchronisationsfehler und ungenutzte Infrastruktur schwerer zu rechtfertigen.
Eine traditionelle Sucharchitektur umfasst gewöhnlich mindestens zwei Datenspeicher. Postgres speichert Transaktionen und Anwendungsstatus. Eine Suchmaschine oder Vektordatenbank erhält transformierte Kopien über eine Pipeline für Extraktion, Transformation und Laden.
Diese Aufteilung kann im großen Maßstab gut funktionieren, schafft jedoch betriebliche Verpflichtungen. Teams müssen fehlgeschlagene Updates erkennen, fehlende Datensätze erneut verarbeiten, Schemaänderungen koordinieren, Löschsemantik bewahren und Datenbankberechtigungen in einem anderen System nachbilden. Außerdem brauchen sie einen Plan, Indizes neu aufzubauen, ohne die Anwendung zu unterbrechen.
KI-Agenten verstärken diese Verpflichtungen, weil Retrieval Teil eines Entscheidungszyklus wird. Eine herkömmliche Suchseite kann ein unvollständiges Ergebnis verkraften, während ein Nutzer Alternativen prüft. Ein Agent kann unmittelbar nach dem Abruf eines Datensatzes handeln, wodurch Aktualität und Autorisierung wichtiger werden.
Ein Account-Management-Agent veranschaulicht das Problem. Er könnte Besprechungsnotizen semantisch durchsuchen, eine exakte Vertragskennung abgleichen und Ergebnisse anhand der Berechtigungen des aktuellen Nutzers filtern. Wenn diese drei Signale in unterschiedlichen Systemen liegen, muss die Anwendung sie abgleichen, bevor das Modell sicher antworten kann.
Dasselbe Problem tritt im Handel auf. Ein Shopping-Agent kann eine mehrdeutige Anfrage mithilfe von Embeddings interpretieren, doch Verfügbarkeit und regionale Einschränkungen stammen aus sich schnell ändernden operativen Spalten. Die Suche in einer veralteten Kopie kann eine überzeugende Antwort zu einem nicht verfügbaren Artikel liefern.
Stoßartige Nutzung erzeugt eine weitere Druckquelle. Unternehmenssuche für menschliche Nutzer folgt oft vorhersehbaren Arbeitszeiten. Agenten können beim Planen, Verifizieren und Überarbeiten einer Aufgabe viele parallele Retrieval-Aufrufe erzeugen. Eine einzelne Nutzeranfrage kann mehrere Suchvorgänge statt nur eines auslösen.
Databricks hat Lakebase Search auf diese ungleichmäßige Nachfrage ausgelegt. Lakebase trennt dauerhaften Speicher von Rechenleistung, hält Daten in Objektspeicher vor und nutzt Speicher sowie lokales NVMe als Caches. Search-Compute kann bei Inaktivität pausieren und fortgesetzt werden, wenn eine weitere Abfrage eingeht.
Das Unternehmen berichtet bei einem Index mit 100 Millionen Vektoren und 768 Dimensionen über eine P90-Latenz für die erste Abfrage von 1,13 Sekunden nach dem Herunterskalieren auf null. Zudem erklärt es, dass dieselbe Sammlung mit einer Lakebase Compute Unit bereitgestellt werden kann. Dies sind Unternehmensmessungen und keine allgemeingültigen Erwartungen, zeigen jedoch das angestrebte Betriebsmodell.
Eine kalte Abfrage von einer Sekunde eignet sich nicht für jede interaktive Anwendung. Für einen selten genutzten internen Agenten könnte sie jedoch akzeptabel sein, wenn dadurch kein großer Search-Cluster dauerhaft betrieben werden muss. Teams können Compute aktiv halten, wenn Latenz entscheidend ist, und ruhigere Umgebungen pausieren lassen.
Auch die Indexerstellung wird vom primären Transaktionspfad wegverlagert. Databricks zufolge kann das System Zentroiden aus einer Stichprobe trainieren, Vektorzuweisung und Quantisierung verteilen und anschließend unabhängige Indexblöcke schreiben. Eine künftige Auslagerung auf verteilte Engines wie Spark gehört zur Ausrichtung des Unternehmens, auch wenn die Ankündigung dazu auffordert, auf diese umfassendere Fähigkeit zu warten.
Das ist wichtig, weil große Indexaufbauten mit Transaktions-Workloads konkurrieren, wenn sie dieselben Prozessor-, Speicher- und Storage-Ressourcen nutzen. Die Verlagerung dieser Arbeit aus der primären Datenbank kann Interferenzen reduzieren. Sie verändert außerdem das Kostenmodell: weg vom dauerhaft bereitgestellten Indexserver, hin zur Bezahlung aktiver Retrieval-Rechenleistung und dauerhaften Speichers.
Das Druckziel sind nicht sämtliche dedizierten Search-Deployments. Große Search-Teams benötigen häufig spezialisierte Analyzer, angepasste Ranking-Pipelines, fortgeschrittene Observability oder Funktionen, die über Jahre entwickelt wurden. Lakebase setzt stattdessen die verbreitete Architektur unter Druck, in der ein zweites System hauptsächlich existiert, weil die Suche mit Postgres nicht mehr komfortabel skalierte.
Diese Unterscheidung hält die Ankündigung auf dem Boden der Tatsachen. Databricks argumentiert nicht, dass eine Datenbank jeden Search-Workload ausführen sollte. Das Unternehmen argumentiert, dass mehr KI-Anwendungen die Aufteilung aufschieben, vereinfachen oder vermeiden können.
Lakebase Vector Search nimmt pgvectors Speichermodell ins Visier
Der Hauptwettbewerb lautet: speichergestütztes Lakebase Search gegen speicherintensive pgvector-Indizes im großen Maßstab.
Pgvector hat Postgres zu einem praktischen Ausgangspunkt für semantisches Retrieval gemacht. Es fügt Vektortypen, Distanzoperatoren, exakte Suche und approximative Indizes hinzu, ohne Entwickler zu einer ungewohnten Datenbankschnittstelle zu zwingen. Es bleibt Open Source und ist in vielen gehosteten Postgres-Diensten weit verbreitet verfügbar.
Zu den standardmäßigen approximativen Optionen gehören HNSW und IVFFlat. HNSW erstellt einen mehrschichtigen Graphen, der nahe Vektoren miteinander verbindet. Es bietet ein günstiges Verhältnis von Geschwindigkeit und Recall, doch der Aufbau des Graphen benötigt Zeit und der Index verbraucht erheblichen Speicher. IVFFlat gruppiert Vektoren in Listen und durchsucht die vielversprechendsten Gruppen, wodurch Speicher- und Erstellungskosten sinken, während die Abfrageleistung im Allgemeinen geringer ausfällt.
Die eigene pgvector-Dokumentation beschreibt diese Abwägungen. Sie weist darauf hin, dass HNSW-Indizes deutlich schneller aufgebaut werden, wenn der Graph in maintenance_work_mem passt. Außerdem warnt sie, dass mehr Suchkandidaten den Recall auf Kosten der Abfragegeschwindigkeit verbessern.
Databricks argumentiert, dass diese Einschränkungen schwieriger werden, wenn ein HNSW-Graph über den Speicher einer einzelnen Maschine hinauswächst. Das Abrufen einer Kette von Graphknoten aus entferntem Objektspeicher kann viele kleine, zufällige Lesevorgänge erzeugen. Ein für residenten Speicher optimiertes Design wird weniger effizient, wenn der Working Set kalt ist.
Die Lakebase-Vektorsuche nutzt hierarchisches Inverted-File-Clustering, um dieses Zugriffsmuster zu verändern. Vektoren werden in zusammenhängenden Blöcken gruppiert. Eine Abfrage bewertet zunächst Cluster-Zentroiden und liest dann Blöcke, die den vielversprechendsten Clustern zugeordnet sind.
Die Erweiterung kombiniert dieses Layout mit der binären RaBitQ-Quantisierung, die jeden Vektor für die anfängliche Kandidatenbewertung auf ungefähr ein Bit pro Dimension komprimiert. Databricks beschreibt diese Repräsentation als etwa 32-mal kleiner als einen standardmäßigen 32-Bit-Gleitkommavektor. Anschließend bewertet das System eine begrenzte Kandidatenmenge mithilfe von Vektoren mit voller Präzision erneut.
Dieser Mechanismus macht den Index sowohl für Objektspeicher als auch für lokales Caching besser geeignet. Eine kalte Abfrage liest mehrere relevante Blöcke, statt Hunderten von Graphverbindungen zu folgen. Eine warme Abfrage kann kompakte Binärcodes scannen und gleichzeitig einen kleineren aktiven Speicherbedarf aufrechterhalten.
Databricks zufolge kann ein einzelner lakebase_ann-Index mehr als eine Milliarde Vektoren aufnehmen. In der Dokumentation heißt es außerdem, der Indexaufbau sei 50- bis 100-mal schneller als HNSW. Diese Angaben beschreiben die Implementierung des Unternehmens und sollten nicht automatisch auf jedes Schema, jedes Embedding-Modell oder jede Filterverteilung übertragen werden.
Der zentrale Benchmark verwendete 100 Millionen Vektoren aus dem LAION-Datensatz. Laut Databricks erzielte Lakebase den doppelten Durchsatz des zweitbesten getesteten Systems. Das Unternehmen meldete 97 % Recall bei 71 Millisekunden P99, was bedeutet, dass 99 % der gemessenen Anfragen innerhalb dieser Latenz abgeschlossen wurden und die tatsächlichen Nachbarn mit der angegebenen Rate zurücklieferten.
Der Benchmark lieferte auch die Behauptung vierfach geringerer Kosten gegenüber einem nicht genannten Cloud-Postgres-Anbieter mit pgvector. Databricks weist darauf hin, dass pgvector und DiskANN auf einzelnen großen Instanzen getestet wurden. Dieser Vorbehalt schränkt den Vergleich ein, da Architektur, Konfiguration, Hardware, Parallelität und Preisannahmen die Ergebnisse wesentlich verändern können.
Ein Benchmark kann zeigen, dass ein Ansatz eine Bewertung verdient, ohne die Kaufentscheidung abschließend zu klären. Databricks hat nicht belegt, dass jede pgvector-Workload migrieren sollte. Kleinere Indizes passen möglicherweise problemlos in den Arbeitsspeicher, und eine bestehende pgvector-Installation kann kostengünstig, portabel und einfach zu betreiben sein.
Pgvector unterstützt außerdem binäre Quantisierung, Indizierung mit halber Präzision, iterative Scans, Partitionierung und konfigurierbaren Suchaufwand. Teams mit optimierten Deployments haben mehr Möglichkeiten, als ein einfaches Basisdiagramm nahelegt. Die Open-Source-Erweiterung funktioniert in vielen Postgres-Umgebungen, während Lakebase Search zu einem verwalteten Databricks-Service gehört.
Die Kompatibilität senkt jedoch die Migrationskosten. Databricks zufolge verwendet lakebase_vector die Vektortypen, Distanzoperatoren und Abfragesyntax von pgvector. Eine Anwendung kann vertrautes SQL beibehalten und dabei einen lakebase_ann-Index statt eines HNSW- oder IVFFlat-Index erstellen.
Das ist ein bewusst gewählter Wettbewerbsschritt. Databricks fordert Entwickler nicht dazu auf, das pgvector-Programmiermodell aufzugeben. Stattdessen bietet das Unternehmen unter weitgehend derselben Schnittstelle eine andere Speicher- und Indexierungs-Engine.
Kundenerfahrungen liefern ein praktisches Signal. Conexiom teilte Databricks mit, dass das Unternehmen eine hybride BM25-Suche über mehr als 100 Millionen Zeilen mit der Hälfte des Compute-Bedarfs seines vorherigen pgvector-Setups betreibt. Das Beispiel ist nützlich, weil es eine operative Workload beschreibt, bleibt aber eine vom Anbieter ausgewählte Kundenaussage ohne unabhängig veröffentlichte Methodik.
Der Nutzen der Lakebase-Vektorsuche ist am größten, wenn die Sammlung groß ist, die Nachfrage nach Abfragen unregelmäßig ausfällt und operative Filter wichtig sind. Er wird schwächer, wenn Teams Infrastrukturportabilität priorisieren, einen vorhersehbaren dauerhaft aktiven Bedarf haben oder ihre Latenzziele bereits mit pgvector erreichen.
Native BM25 verändert die Gleichung der Volltextsuche
Der leisere Teil der Veröffentlichung könnte wichtiger sein als der Vektor-Benchmark.
Viele KI-Suchprodukte überbetonen Embeddings. Semantisches Matching hilft, wenn Nutzer und Dokumente dieselbe Idee mit unterschiedlichen Worten ausdrücken. Weniger zuverlässig ist es, wenn eine Anfrage eine exakte Kennung enthält, die ein Embedding-Modell als schwach oder unbekannt behandelt.
Man denke an einen Agenten, der nach „CVE-2026-1234“, einer Kundennummer oder einem bestimmten Komponentennamen sucht. Eine Ähnlichkeitssuche kann konzeptionell verwandte Datensätze zurückgeben, während sie die Bedeutung der exakten Zeichenfolge verfehlt. Keyword-Ranking liefert ein separates Retrieval-Signal, das wörtliche Treffer bewahrt.
Die lakebase_text-Erweiterung von Lakebase fügt einen lakebase_bm25-Index hinzu, der mit PostgreSQL-tsvector-Werten und Textabfrageoperatoren kompatibel ist. BM25 bezieht die termweite Häufigkeit über die gesamte Sammlung und die Dokumentlänge ein, wodurch seltene Begriffe stärker beitragen als häufige.
PostgreSQL bietet bereits umfangreiche Volltextfunktionen. Es kann Dokumente analysieren, Wörter normalisieren, Stoppwörter entfernen, GIN-Indizes erstellen und Ergebnisse mit ts_rank oder ts_rank_cd bewerten. Die offizielle Dokumentation zum Ranking weist darauf hin, dass die integrierten Ranking-Funktionen lexikalische Häufigkeit, Nähe und strukturelle Informationen verwenden.
Diese Funktionen verwenden globale Sammlungsstatistiken nicht auf dieselbe Weise wie BM25. Dieser Unterschied ist relevant, wenn ein Produkt eine suchmaschinenähnliche Relevanz statt einfacher Übereinstimmungen benötigt. Teams haben in der Vergangenheit eigene Ranking-Logik hinzugefügt oder Text in eine dedizierte Engine ausgelagert.
Databricks zufolge verwendet lakebase_text Block-Max WAND für Top-K-Retrieval. Dieser Algorithmus überspringt Bereiche, die kein Ergebnis liefern können, das mit den aktuell höchsten Scores konkurriert. Statt jedes passende Dokument vollständig zu bewerten, konzentriert die Engine die Arbeit auf Kandidaten, die in die angeforderte Ergebnismenge gelangen können.
Der Ansatz ergänzt Vektor-Retrieval. Eine Support-Anfrage könnte für exakten Fehlertext gegen lakebase_bm25 und für semantisch ähnliche Incident-Beschreibungen gegen lakebase_ann laufen. Reciprocal Rank Fusion kann anschließend beide geordneten Listen kombinieren, ohne vorauszusetzen, dass ihre Rohscores dieselbe Skala teilen.
An diesem Punkt wird Databricks Lakebase Search mehr als ein schnellerer Vektorindex. Es bietet einen Such-Stack mit zwei unterschiedlichen Retrieval-Modellen innerhalb derselben Datenbank. Die operative Zeile, das Embedding, die Textrepräsentation und die Filterattribute können zusammenbleiben.
Diese Konsolidierung betrifft Sicherheit ebenso wie Komfort. Eine Anwendung kann Mandantengrenzen und Berechtigungsprüfungen als SQL-Prädikate neben dem Retrieval ausdrücken. Entwickler müssen weiterhin testen, ob jeder Indexpfad Filter korrekt durchsetzt, vermeiden jedoch, in einem separaten Service ein vollständiges Autorisierungsmodell neu zu erstellen.
Sie vereinfacht auch das Schreibverhalten. Ein neu eingefügter Datensatz kann durchsuchbar werden, ohne auf die Bestätigung eines Ereignisses durch eine zweite Datenbank zu warten. Aktualisierungen und Löschungen bleiben in einer vertrauten transaktionalen Umgebung, auch wenn der Zeitpunkt der Indexpflege und synchronisierte Lakehouse-Quellen weiterhin gemessen werden müssen.
Dedizierte Engines behalten wichtige Vorteile. Elasticsearch und ähnliche Systeme unterstützen umfassende Sprachanalyse, angepasste Bewertung, Aggregationen, Hervorhebungen, Abfragewerkzeuge und speziell für die Suche entwickelte Betriebskontrollen. Die BM25-Unterstützung von Lakebase beseitigt diese Unterschiede nicht.
Der aussagekräftige Vergleich ist daher architektonischer Natur. Wenn eine Anwendung semantisches Retrieval, Ranking exakter Begriffe, aktuelle operative Filter und gewöhnliches SQL benötigt, kann Lakebase einen größeren Teil dieser Workload an einem Ort abdecken. Wenn die Suche selbst das Produkt ist, können spezialisierte Funktionen weiterhin ein separates System rechtfertigen.
Der Benchmark lässt Fragen zur Produktion offen
Databricks hat einen attraktiven Mechanismus gezeigt, doch Käufer benötigen weiterhin workloadspezifische Belege.
Die größte Unsicherheit betrifft die Unabhängigkeit des Benchmarks. Databricks wählte die Systeme, Konfigurationen, den Datensatz, die Instanzgrößen und die Kostenannahmen hinter seinem veröffentlichten Vergleich aus. Das Unternehmen nennt VectorDBBench und den LAION-Datensatz mit 100 Millionen Vektoren, doch die Ankündigung liefert nicht genügend Details, um jedes Ergebnis allein auf Grundlage des Artikels zu reproduzieren.
Recall und Latenz stehen ebenfalls in Wechselwirkung. Approximatives Retrieval vermeidet bewusst einen vollständigen Vergleich, daher stimmen Entwickler darauf ab, wie viele Cluster oder Kandidaten eine Anfrage untersucht. Höherer Recall erfordert häufig mehr Arbeit. Ein einzelner Leistungspunkt kann nicht die gesamte Kurve über unterschiedliche Zielwerte für den Recall beschreiben.
Filter können diese Kurve erneut verändern. Reale Geschäftsabfragen können Ergebnisse nach Mandant, Geografie, Zeit, Lagerstatus oder Autorisierung einschränken. Ein gleichmäßig verteilter Benchmark repräsentiert nicht zwangsläufig hochselektive oder ungleichmäßige Produktionsfilter.
Auch die Datenform ist relevant. Bild-Embeddings aus LAION unterscheiden sich von Embeddings für Unternehmensdokumente, Produktkataloge, Quellcode oder Kundendatensätze. Dimensionen variieren, Duplikate treten auf, Aktualisierungen kommen ungleichmäßig an, und einige Mandanten dominieren den Datenverkehr. Jeder dieser Faktoren kann das Cache-Verhalten und die Indexqualität beeinflussen.
Die Cold-Start-Leistung verdient eine sorgfältige Einordnung. Die gemeldete P90 von 1,13 Sekunden gilt für eine konkrete Konfiguration mit 100 Millionen Vektoren und 768 Dimensionen. Anwendungen mit strengen interaktiven Zielen benötigen möglicherweise aktive Compute-Ressourcen statt Scale-to-Zero. Teams sollten sowohl die erste Anfrage als auch den darauffolgenden Burst testen.
Auch operative Einschränkungen erfordern Aufmerksamkeit. Laut Dokumentation startet die Aktivierung von Lakebase Search jede Compute-Ressource in einem Projekt neu, trennt aktive Verbindungen und kann nicht rückgängig gemacht werden. Das macht die Aktivierung zu einer geplanten Infrastrukturänderung und nicht zu einem harmlosen Umschalten einer Erweiterung.
Portabilität ist ein weiterer Zielkonflikt. Lakebase präsentiert Standard-Postgres-Typen und vertraute pgvector-Syntax, doch seine neuen Indexzugriffsmethoden sind proprietäre, verwaltete Funktionen. Ein Team kann einen großen Teil seines Anwendungs-SQL behalten und dennoch bei Indexverhalten, Skalierung und Preisgestaltung von Databricks abhängig werden.
Dieselbe Sorge gilt für BM25. Standard-tsvector-Spalten bleiben erkennbare Postgres-Objekte, doch der lakebase_bm25-Index und seine Ausführungsmerkmale sind spezifisch für Lakebase. Ein Wechsel könnte erfordern, Indizes neu aufzubauen und die Ranking-Qualität an anderer Stelle erneut zu testen.
Kostenbehauptungen erfordern direkte Messungen. Serverless-Suspendierung kann Ausgaben bei unregelmäßiger Nutzung senken, doch hohe dauerhafte Parallelität könnte ein anderes Modell begünstigen. Embedding-Generierung, synchronisierte Tabellen, Speicher, Datentransfer und umgebende Databricks-Services tragen zur Gesamtarchitektur bei.
Teams sollten Lakebase Search daher mit repräsentativen Fragen statt einer generischen Bestenliste bewerten. Ein nützlicher Testkorpus umfasst aktuelle Datensätze, gelöschte Datensätze, zugriffsgesteuerte Dokumente, seltene Kennungen, mehrdeutige natürlichsprachliche Abfragen und die Filter, die den Recall am ehesten verringern.
Sie sollten außerdem operative Ergebnisse vergleichen. Messen Sie Datenaktualität, Fehlerbehebung, Auswirkungen des Indexaufbaus, Berechtigungskonsistenz und den Zeitaufwand des Personals für die Verwaltung von Pipelines. Das Entfernen eines externen Service kann wertvoll sein, selbst wenn sich die reine Abfragelatenz kaum verändert.
Keine dieser Fragen entkräftet die Veröffentlichung. Sie definieren, was „State of the Art“ außerhalb eines Anbieter-Benchmarks bedeuten muss. Die Architektur hat eine glaubwürdige technische Begründung, doch Produktionsbelege müssen zeigen, dass ihre Vorteile die Datenverteilung und Workload jedes Käufers überstehen.
Worauf nach der GA-Verfügbarkeit von Lakebase Search zu achten ist
Drei Signale werden bestimmen, ob Lakebase Search zu einer Standardfunktion von Postgres wird oder eine Databricks-spezifische Option bleibt.
Das erste Signal ist reproduzierbare Leistung. Unabhängige Tests sollten Lakebase mit optimiertem pgvector, DiskANN-basierten Services und dedizierten Such-Engines über mehrere Recall-Ziele hinweg vergleichen. Sie sollten Instanzspezifikationen, Parallelität, Filterselektivität, Cache-Zustand, Zeit für den Indexaufbau und vollständige Kostenannahmen veröffentlichen.
Ergebnisse nahe an den Behauptungen von Databricks würden die These stärken, dass speichergestützte Clusterindizes für große serverlose Sammlungen besser geeignet sind als speicherorientierte Graphen. Eine große Abweichung würde das Leistungsnarrativ schwächen, selbst wenn die Konsolidierung weiterhin operative Vorteile bietet.
Das zweite Signal ist die Akzeptanz bei Teams, die Architekturen mit zwei Systemen ersetzen. Conexiom liefert ein frühes Beispiel, doch der Markt benötigt mehr Berichte über Produktionsumfang, Aktualisierungshäufigkeit, Abfragevolumen und Berechtigungsmodelle. Die überzeugendsten Geschichten werden einen entfernten Suchcluster oder eine abgeschaffte ETL-Pipeline dokumentieren, nicht nur eine erfolgreiche Demonstration.
Die Akzeptanz wird auch zeigen, ob vertraute Postgres-Syntax die Migrationshürden senkt. Wenn Teams Indexdefinitionen ändern können, während sie ihr Datenmodell und ihre Abfragen beibehalten, hat Lakebase Search einen praktischen Weg in bestehende Anwendungen. Wenn Migrationen umfangreiche Änderungen am Ranking erfordern, wird die Kompatibilitätsbehauptung weniger Gewicht haben.
Das dritte Signal ist die Reaktion des Wettbewerbs. Pgvector erweitert weiterhin seine Optionen für Quantisierung, Filterung und iterative Scans. Anbieter von Managed Postgres können die Speicherarchitektur verbessern oder eigene Sucherweiterungen einführen. Spezialisierte Suchanbieter können auf ausgereifte Ranking-Steuerung, flexible Bereitstellung und hybride Retrieval-Funktionen setzen.
Databricks begann in seiner Ankündigung zur Markteinführung von 2025, Lakebase als Managed Postgres für KI-Anwendungen zu positionieren. Diese Veröffentlichung macht diese Positionierung konkreter. Transaktionen allein machen eine Datenbank nicht agententauglich, wenn jede ernsthafte Retrieval-Abfrage das System weiterhin verlassen muss.
Die unmittelbare Erkenntnis ist enger gefasst und nützlicher. Databricks Lakebase Search bietet Entwicklern einen zentral verwalteten Ort für operative Datensätze, Vektorähnlichkeit, BM25-Ranking und SQL-Filterung. Sein geclusterter, quantisierter Vektorindex adressiert direkt das Speichermodell, das große pgvector-Bereitstellungen einschränkt.
Die nächste Entscheidung liegt bei den Engineering-Teams. Erstellen Sie einen repräsentativen Retrieval-Test, berücksichtigen Sie kalten und warmen Traffic, wenden Sie reale Berechtigungsfilter an und vergleichen Sie den vollständigen Betriebsaufwand. Wenn Lakebase die Relevanz erhält und zugleich Synchronisierungsinfrastruktur überflüssig macht, wird die architektonische Vereinfachung wichtiger sein als jeder einzelne Benchmark-Balken.
