Lakebase Search: Hybrid Search für Agenten direkt in Lakebase Postgres
Die Kernaussagen auf einen Blick.
- Lakebase Search erweitert Lakebase Postgres um Hybrid Search direkt im operativen Speicher: Volltextsuche, Vektorsuche und SQL-Filter laufen in einer gemeinsamen Abfrage und im selben Transaktionskontext.
- Wenn Agenten-Memory, App-State oder operative Wissenseinträge ohnehin in Lakebase liegen, entfällt oft ein separater Vector Store mit eigener Synchronisation, eigener Berechtigungslogik und möglichem Embedding-Drift.
- Für große, kuratierte Wissensbestände auf Delta-Tabellen bleibt Mosaic AI Vector Search meist die bessere Retrieval-Schicht. AI Search ist dagegen für die Suche nach Unity-Catalog-Assets gedacht, nicht für Agenten-Antworten.
- Mein Vorschlag: Für jeden Agenten-Use-Case festlegen, ob Lakebase Search, Mosaic AI Vector Search oder AI Search die passende Suchschicht ist. Entscheidend ist, wo die Daten sinnvoll gespeichert werden, wie schnell sie auffindbar sein müssen und wie der Embedding-Lifecycle betrieben wird.
Inhaltsverzeichnis
Nicht jeder Agent braucht einen Vector Store
In Architektur-Reviews sieht man aktuell häufig eine ähnliche Skizze, die in vielen Plattformen schrittweise entstanden ist: Postgres für App-Zustand und Sitzungsdaten, ein separater Vector Store für Wissensinhalte, eine externe API für zusätzliche Fachdaten. Zwischen diesen Systemen läuft eine Synchronisationspipeline, die regelmäßig Embeddings aktualisiert. Berechtigungen liegen teilweise in Unity Catalog und teilweise im eigenen Berechtigungsmodell des Vector Stores. Im Audit ist später schwer nachvollziehbar, aus welchem System ein Treffer tatsächlich stammt. Schwer beantwortbar ist auch, ob die Antwort auf einem veralteten Embedding basiert.
In wachsenden Agent-Plattformen entsteht diese Architektur oft unbeabsichtigt. Der erste Anwendungsfall braucht etwas RAG, also wird ein Vector Store ergänzt. Der zweite Anwendungsfall braucht Sitzungszustände, also kommt eine Postgres-Datenbank für die Anwendung hinzu. Der dritte Anwendungsfall sucht nach passenden Lakehouse-Assets, also wird AI Search aktiviert. Nach einiger Zeit ist kaum noch klar, welcher Datenpfad welches Berechtigungsmodell nutzt und welche Daten wirklich aktuell sind.
Genau hier setzt Lakebase Search an, das Databricks auf dem Data + AI Summit 2026 als Suche für Agenten direkt im operativen Postgres-Speicher positioniert. Die Frage für die nächste Agent-Foundation lautet damit: Liegt der relevante Inhalt ohnehin in Lakebase Postgres oder gehört er in einen größeren Lakehouse-Wissensbestand?
Wo liegen die Inhalte, auf die der Agent zuerst zugreifen muss? Wie schnell müssen neu geschriebene Inhalte in der Suche sichtbar sein? Wie viele Embeddings ändern sich täglich? Wo sollen Berechtigungen verbindlich gesteuert werden, in Unity Catalog oder in einem zweiten ACL-Modell? Wer betreibt einen zusätzlichen Speicher, falls er wirklich nötig ist?
Was ist Lakebase Search?
Lakebase Search ist eine Suchfunktion direkt in Lakebase Postgres, die drei Sucharten in einer Abfrage und im selben transaktionalen Kontext zusammenführt: Volltextsuche mit Postgres-Mechanismen (tsvector/tsquery und GIN-Indizes), Vektorsuche auf Basis von Postgres-kompatiblen Vektoren (pgvector mit HNSW- oder IVFFlat-Indizes) und klassische SQL-Filter über normale Tabellenattribute (WHERE-Bedingungen). Wenn Daten geschrieben werden, werden die zugehörigen Suchindizes im gleichen Transaktionskontext aktualisiert. Eine Suchabfrage kann Volltext, Vektorähnlichkeit und Filter gemeinsam nutzen.
Die Grundlage bleibt Postgres. Databricks Lakebase ist die serverlose Postgres-Datenbank in der Databricks Data Intelligence Platform, für operative Anwendungen und Agenten im Databricks-Umfeld. Lakebase Search ergänzt diesen OLTP-Store um die Such-Mechanik, die Workloads direkt rund um Agenten typischerweise brauchen: kombinierte Suche, frühe Filterung und schnelle Antworten auf derselben Datenbankschicht wie die Schreibvorgänge.
Statt neben der operativen Datenbank eine zweite Such-Engine zu betreiben, liegen Schreibpfad, Suchpfad und Suchindizes in derselben Postgres-Schicht, mit denselben Transaktionsregeln, demselben Berechtigungsrahmen und demselben Backup-Pfad. Für Agenten-Grundlagen, bei denen Inhalte ohnehin in Lakebase Postgres gespeichert werden (Sitzungsdaten, App-Zustand und operativ gepflegte Wissenseinträge), kann die zusätzliche Synchronisationspipeline entfallen, die in solchen Setups oft einen großen Teil des Betriebsaufwands verursacht.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Volltext, Vektoren und SQL-Filter
Hybrid-Suche bedeutet hier: Volltextsuche, Vektorähnlichkeit und SQL-Filter werden gemeinsam ausgeführt auf derselben Datenbank und im gleichen Konsistenzrahmen. Dafür nutzt Lakebase Search Postgres-nahe Erweiterungen, die Databricks gemeinsam mit der Such-Schicht ausliefert: lakebase_vector für Vektor-Suche und lakebase_text für Volltextsuche mit besserer Relevanzbewertung. Beide laufen in der gleichen Postgres-Engine, mit bekannten Postgres-kompatiblen Datentypen (pgvector-kompatibel, tsvector-kompatibel) wie das Ökosystem sie kennt. Der Unterschied liegt vor allem in der Art, wie die Indizes gespeichert und genutzt werden.
lakebase_vector reduziert den hohen Speicherbedarf klassischer HNSW-Indizes durch komprimierte Vektorindizes auf Basis RaBitQ-basierter Komprimierung (Randomized Binary Quantization) ohne die Trefferqualität stark zu verschlechtern. Ein Index mit 100 Millionen Vektoren, der mit Standard-pgvector-HNSW rund 300 GB RAM bräuchte, passt damit in unter 10 GB. Häufig genutzte Indexteile liegen im schnellen Cache, selten genutzte Teile können günstiger im Objektspeicher liegen. lakebase_text ergänzt oder ersetzt klassische Volltextindex-Mechanismen, die vollständig im RAM gehalten werden müssen, durch ein Index-Layout, das für sequenzielle Lese-Pfade aus dem Object Storage gebaut ist. Geliefert wird dabei eine Relevanzbewertung, die stärker auf Suchqualität ausgelegt ist als die schlichte ts_rank-Mechanik.
Eine typische Agentenabfrage kombiniert Volltext, Vektorähnlichkeit und Filter. Vektor- und Volltext-Treffer werden über Reciprocal Rank Fusion (RRF) zusammengeführt: eine Rang-Zusammenführung der verschiedenen Trefferlisten. Dabei zählt vor allem die Position eines Treffers in den jeweiligen Ergebnislisten. Filter auf strukturierte Felder (zum Beispiel Mandant, Sprache, Zeitraum oder Status) werden als normale SQL-Filter in derselben Abfrage angewendet und vor der Vektor-Suche angewendet (frühe Anwendung der Filter). Das hilft, trotz enger Filter passende Treffer zu finden, was bei externen Vector Stores oft das schwächste Glied ist, sobald Tenant- oder Zeitfenster-Filter ins Spiel kommen.
Die Suchindizes werden beim Schreiben gepflegt. Ein Insert oder Update aktualisiert tsvector-Spalten, pgvector-Einträge und die zugehörigen Indizes innerhalb derselben Transaktion wie die eigentliche Tabellenzeile. Der typische OLTP-Mechanismus der Postgres-Engine trägt mit: Write-Ahead-Log, MVCC, Lock-Management. Es gibt kein zusätzliches Zeitfenster, in dem Embeddings erst später synchronisiert werden, und keinen separaten Pipeline-Status für die Suche, der getrennt überwacht werden müsste.
Für die Embedding-Erzeugung selbst hängt die konkrete Mechanik vom gewählten Modell ab. Lakebase Search bietet eine integrierte Anbindung an Databricks-Modelle und externe Embedding-Services, die Vektoren bei Schreib-Operationen direkt erzeugen können. Die Erzeugung der Embeddings wirkt sich dann auf den Schreibvorgang aus statt später in einer separaten Pipeline zu laufen. Alternativ kann die Anwendung den bereits berechneten Vektor direkt mitschreiben. Beide Pfade landen am Ende im selben pgvector-Index.
In Summe entsteht damit ein Suchverhalten ähnlich einer direkt in die Anwendung integrierten Suche, mit sofortiger Sichtbarkeit neu geschriebener Daten und mit der Möglichkeit, klassische Filter und semantische Ähnlichkeit in einer Antwort zu kombinieren. Genau das ist die Kompatibilität zur Agent-Welt, die sonst nur über mehrere Systeme synchronisiert erreicht würde.
Lakebase Search vs Mosaic AI Vector Search vs AI Search
Im Databricks-Stack hat jede der drei Suchschichten einen klaren Platz. Lakebase ist die operative Postgres-Schicht für Anwendungen, Agentenzustand, Sitzungsdaten und operative Wissenseinträge. Lakebase Search bringt die Suche direkt in diese operative Schicht. Mosaic AI Vector Search bleibt die Suchschicht für große Wissensbestände auf Delta-Tabellen, mit eigener Pipeline für Embeddings und eigener Synchronisation mit dem Lakehouse. AI Search löst eine andere Aufgabe: die semantische Suche nach passenden Unity-Catalog-Objekten, nicht die Inhaltssuche innerhalb einer Agentenantwort.
| Retrieval-Schicht | Wo die Daten liegen | Art der Suche | Typischer Datenbestand | Umgang mit Embeddings | Governance-Rahmen |
|---|---|---|---|---|---|
| Lakebase Search | Lakebase Postgres (OLTP) | Hybrid in einer Query und einer Transaktion | klein bis mittelgroß, operativ gepflegt, häufig geändert | direkt beim Schreiben erzeugt oder von der Anwendung mitgegeben | Unity Catalog |
| Mosaic AI Vector Search | Delta-Tabellen (Lakehouse) | Vektor + optional Filter, eigene Such-Engine | groß, selten geändert und auf Lakehouse-Skalierung ausgelegt | eigene Embedding-Pipeline mit Synchronisationsfenster | Unity Catalog |
| AI Search | Unity-Catalog-Assets | semantische Suche nach Daten- und Plattformobjekten | Tabellen, Views, Modelle, Notebooks | Asset-Metadaten | Unity Catalog |
| Externer Vector Store (Pinecone, Qdrant, Weaviate, pgvector außerhalb) | außerhalb Databricks | Vektor + Filter | je nach Setup | externe Pipeline | eigenes Berechtigungsmodell plus Anbindung an Unity Catalog |
Lakebase Search trägt App-Zustand, Agenten-Memory und kleinere, redaktionell gepflegte Wissenseinträge: also alles, was ohnehin in Lakebase Postgres geschrieben wird und im nächsten Konversationsschritt wieder lesbar sein muss. Mosaic AI Vector Search trägt große, selten geänderte Wissenskorpora auf Delta-Tabellen mit eigener Embedding-Pipeline und Lakehouse-Skalierung. In produktiven Agent-Architekturen laufen beide oft nebeneinander: Lakebase Search für Session und Memory, Mosaic AI Vector Search für das große Knowledge-Korpus. Wer Lakebase Search auch für lakehouse-skalige Wissensbestände einsetzt, bremst die operative Postgres-Last aus. Wer Mosaic AI Vector Search auch für Agenten-Memory einsetzt, lebt mit Sync-Lag im Konversationspfad.
Wie das größere Vergleichsbild der Databricks-eigenen Vector-Lösung aussieht, also wann eigener Embedding-Lifecycle und wann Sync zum Lakehouse trägt, führen wir in Vector Search auf Databricks aus. Und wenn die Frage der nächsten Foundation lautet, wie RAG-Architekturen insgesamt strukturiert werden, klären wir das im Überblick zu Retrieval-Augmented Generation auf Databricks.
Agenten-Memory, App-Suche und operative Wissensbestände
Drei typische Anwendungsfälle passen besonders gut zu Lakebase Search und werden auch genau so positioniert.
Agent Memory & Session State
Verlauf, Präferenzen, Tool-Aufrufe und Zwischenergebnisse liegen ohnehin in Lakebase Postgres. Eine Hybrid-Query verbindet Volltext-Match, Vektor-Ähnlichkeit und SQL-Filter auf Tenant und Zeitfenster im selben Datenpfad wie die Schreibvorgänge des Agenten.
Kleine bis mittlere Wissensbestände
Ticketantworten, Knowledge-Artikel oder Produktbeschreibungen, die häufig redaktionell geändert werden, sind ohne Verzögerung durch eine separate Embedding-Pipeline sofort durchsuchbar.
Suche innerhalb einer Anwendung
Lakebase Search übernimmt die Suchfunktion direkt im App-Speicher, mit bestehender Berechtigungslogik, OLTP-Latenz und Ergebnissen auf dem aktuellen Stand der operativen Daten.
Die Lakehouse-Klammer bleibt erhalten. Welche der Agent- und App-Konsumenten oben in welchem Bauplan zusammenspielen, also Agent Bricks als Foundation, Databricks Apps als Konsument, Lakebase als operativer Speicher, klären wir in den Databricks Apps und in Agent Bricks.
Lakebase Search oder Mosaic AI Vector Search?
Lakebase Search ist auf agent-nahe Suche im operativen Postgres-Pfad zugeschnitten, nicht auf jeden Retrieval-Workload, der in einer Databricks-Architektur auftaucht. Drei Anforderungsprofile fallen typischerweise aus diesem Korridor heraus.
Ein großer Wissensbestand auf Delta-Tabellen (sehr viele Embeddings, eigene Embedding-Pipeline, Modellwechsel und Re-Indexierung, Sync mit dem Lakehouse-Bronze/Silver-Pfad) gehört auf Mosaic AI Vector Search. Die Engine ist genau dafür gebaut: ein aus Delta gesyncter Vector-Index (Delta Sync Index), Suchlast getrennt von der operativen Postgres-Last, klare Trennung zwischen Embedding-Betrieb und Suchperformance über getrennte Serving-Endpoints.
Ein spezialisierter bestehender Vector-Workload mit besonderen Indexanforderungen oder eigenen Embedding-Pipelines außerhalb von Databricks (etwa eine bestehende Pinecone- oder Qdrant-Installation mit historischer Tiefe) kann bewusst im bestehenden System bleiben. Der externe Store behält klar verteilte Verantwortung mit klar geregelter Verantwortung für Synchronisation, Identitäten und Lineage. Lakebase Search ergänzt dann App-Zustand und Agenten-Memory, ersetzt aber nicht zwingend das bestehende Knowledge-Retrieval.
Ein pragmatischer Aufbau kann mehrere Suchschichten kombinieren: Lakebase Search für Agenten-Memory und operativ gepflegte Inhalte, Mosaic AI Vector Search für große Wissensbestände, AI Search für die Suche nach Plattformobjekten, ein externer Store nur, wenn besondere Anforderungen ihn wirklich nötig machen. Unity Catalog sollte die gemeinsame Klammer für Identität, Berechtigungen und Lineage bilden.
Weniger Synchronisation, weniger Drift, bessere Nachvollziehbarkeit
Die wichtigste Folge: für passende Lakebase-Search-Anwendungsfälle entfällt die zusätzliche Synchronisation zwischen operativer Datenbank und Vector Store. Der typische CDC- oder Polling-Pfad „operative Tabelle → Embedding-Pipeline → separater Vector Store“ wird durch Indexierung direkt im Schreibpfad der Datenbank ersetzt. Damit fallen mehrere Kostenblöcke gleichzeitig weg: Pipelinebetrieb, Monitoring, Backfills und Fehlerbehandlung, die Fehlerbehandlung bei Schema-Änderungen und zusätzliche Betriebsverantwortung für die Suchschicht.
Die Nachvollziehbarkeit wird einfacher. Statt zwei Speichersystemen mit eigener Berechtigungslogik und Synchronisation dazwischen läuft der Datenfluss in einer Hierarchie: eine Lakebase-Tabelle, Suche auf derselben Tabelle und derselbe Berechtigungskontext im Unity Catalog. Im Audit lässt sich nachvollziehen, woher der Treffer kam, bis auf die Tabelle und den Schreib-Eintrag, ohne zusätzlichen Vector Store als Zwischenebene.
Die Konsequenz für die RAG-Architektur ist Identität, Lineage und Suche in einem gemeinsamen Modell, nicht nur als reine Vereinfachung der Infrastruktur. Das ist genau die Aussage, die agent-natives Retrieval bei Databricks tragen soll. Für die Standard-Agent-Foundation reduziert es die Zahl der getrennten Betriebsstrecken, die ein Plattform-Team gleichzeitig verstehen, betreiben und absichern muss, von vier auf zwei. Welche Klassen von Pipelines bei dieser Verschiebung wegfallen und welche bleiben, ordnet der Überblick zu RAG-Architektur auf Databricks im breiteren Bild ein.
Antwortzeit und Konsistenz im operativen Postgres-Pfad
Suche und Schreibvorgänge laufen auf derselben Lakebase-Postgres-Schicht. Das hat zwei wichtige Folgen für Agentenarchitekturen.
Neu geschriebene Daten sind direkt konsistent lesbar. Ein Wissenseintrag, der kurz vor der Suche gespeichert wurde, kann sofort in den Suchergebnissen auftauchen. Es gibt kein separates Synchronisationsfenster und keine separate Indexaktualisierung, auf die gewartet werden muss. Für Agenten, die in einer Konversation gerade Memory speichern und in der nächsten Antwort wieder verwenden, ist das die passende Konsistenzanforderung. Mit einem separaten Vector Store muss diese Konsistenz zusätzlich abgesichert werden. Der Agent würde sich gegen den Embedding-Sync-Lag absichern müssen, was meistens als eine unsaubere Warte- oder Retry-Logik implementiert wird.
Die Antwortzeit hängt vom Lakebase-Workload ab. Die konkreten Zahlen pro Region und Workload-Profil veröffentlicht Databricks separat; typische Hybrid-Abfragen auf mittelgroßen Tabellen liegen im Bereich, in dem OLTP-Postgres-Queries leben. Das ist oft kürzer als ein externer Vector Store mit zusätzlichem Netzwerkweg, aber bei sehr großen Embedding-Beständen aber nicht automatisch besser. Der Vergleich heißt hier „kürzerer Pfad“. Wenn der Workload aber lakehouse-skalig wird, gilt wieder das, was oben steht: dann ist Mosaic AI Vector Search die passendere Schicht, weil Suchlast und operative Schreiblast sollten dann getrennt skaliert werden.
In Summe entsteht damit ein Konsistenzprofil, das gut zu Agenten-Memory und App-Suche passt, und ein Antwortzeitprofil, das von der operativen Datenbanklast abhängt. Beides ist die Stärke der Schicht, gleichzeitig ihre Begrenzung.
Lakebase Search Verfügbarkeit, Reifegrad und Roadmap
Lakebase Search wurde auf dem Data + AI Summit 2026 angekündigt und steht laut Databricks-Ankündigung der agent-nativen Retrieval-Schicht in Lakebase Postgres zunächst als Beta auf ausgewählten Clouds und Regionen zur Verfügung. weitere Clouds, Regionen und der GA-Zeitpunkt sind in der Databricks-Produkt-Dokumentation hinterlegt und können sich nach der Ankündigung noch ändern. Eine Architekturentscheidung sollte immer den aktuellen Produktstatus zum Entscheidungszeitpunkt prüfen und nicht nur den Stand der ursprünglichen Ankündigung.
Beta bedeutet für die Architekturentscheidung: Lakebase Search ist als frühe produktionsnahe Nutzung mit bewusstem Risiko gedacht, mit der Bereitschaft, mögliche Anpassungen bei Änderungen an APIs oder Funktionen einzukalkulieren. Beim GA-Übergang gilt die Schicht als reguläre Plattform-Option mit den Lakebase-eigenen SLAs. Der Unterschied entscheidet, welche Workload-Profile in welcher Phase produktiv gehen. Agent-Memory und app-interne Suche sind ab Beta produktionstauglich, kritische externe Suchanwendungen mit harten SLAs sollten eher auf GA-Reife warten.
Die Kostenlogik folgt der Lakebase-Autoscaling-Mechanik (Default für neue Instanzen seit März 2026): selten genutzte Indexteile wandern in günstigeren Object Storage (~20 $/TB/Monat statt ~3.000 $/TB/Monat für RAM-residente Vektoren). Das verändert die Wirtschaftlichkeit großer, überwiegend inaktiver Wissensbestände und Multi-Tenant-Setups deutlich. Für eine belastbare Vergleichsrechnung zu Mosaic AI Vector Search oder externen Stores zählt das Lakebase-Pricing zum Entscheidungszeitpunkt.
Welche Retrieval-Schicht passt zu welchem Workload?
Wie die Entscheidung konkret aussehen kann, lässt sich an drei wiederkehrenden Profilen zeigen.
Profil 1: Konversationsagent
App-Zustand und Memory je Nutzer liegen ohnehin in Lakebase Postgres, dazu ein überschaubarer, regelmäßig geänderter Wissensbestand. Lakebase Search kann hier die Standardsuchschicht sein; Mosaic AI Vector Search kommt nur bei einem zusätzlichen großen Lakehouse-Wissensbestand dazu.
Profil 2: Wissensagent im Lakehouse
Ein mehrere Millionen Datensätze starker Korpus auf Delta-Tabellen mit eigener Embedding-Pipeline, Modellwechseln und Re-Indexierung bleibt bei Mosaic AI Vector Search. Lakebase Search übernimmt parallel Memory und Sitzungszustände der Agent-Konversation.
Profil 3: App-Zustand plus Asset-Discovery
Drei Quellen parallel: Lakebase Search für State und Memory, Mosaic AI Vector Search für kuratiertes Lakehouse-Wissen, AI Search für die Suche nach passenden Unity-Catalog-Objekten: Unity Catalog bildet die gemeinsame Governance-Klammer.
Die Faustregel lässt sich einfach zusammenfassen:
Wenn Inhalte ohnehin in Lakebase Postgres geschrieben werden, ist Lakebase Search der naheliegende Startpunkt. Wenn der Wissensbestand sehr groß ist und eine eigene Embedding-Pipeline braucht, passt Mosaic AI Vector Search besser. Wenn nach passenden Unity-Catalog-Assets gesucht wird, ist AI Search die richtige Schicht. Wenn ein bestehender externer Vector Store bereits produktiv funktioniert, kann er weiter genutzt werden, aber mit klarer Anbindung an Identitäten und Governance.
Grenzen von Lakebase Search
Lakebase Search passt gut zu agentennahen Workloads auf operativen Daten. Für bestimmte Anforderungen reicht diese Schicht allein jedoch nicht aus.
Geteilter Compute für Suche und Schreiblast
Eine Instanz erlaubt aktuell bis zu 1.000 parallele Verbindungen und 2 TB logische Datengröße. Viele Suchabfragen und viele Schreibvorgänge beeinflussen sich gegenseitig: Workloads mit sehr hoher Suchlast und wenig Schreibaktivität sind mit einer getrennt skalierbaren Such-Engine oft sauberer gelöst.
Embedding-Lifecycle bleibt eigene Disziplin
Durch RaBitQ-Komprimierung skaliert ein `lakebase_vector`-Index auf über eine Milliarde Vektoren. Modellwechsel, Re-Embedding und Sync mit Lakehouse-Datenständen bleiben Engpässe, für die Mosaic AI Vector Search mehr operative Kontrolle bietet.
Dauerhaft hohe externe Suchlast
Eine öffentliche Suche mit konstanter QPS-Last ohne ruhige Phasen ist nicht der typische Einsatzbereich. Die Auto-Scale-Mechanik zahlt sich bei Lastspitzen mit Ruhephasen aus, nicht bei konstant hochgepressten externen Such-Endpunkten.
Produktreifegrad bestimmt das Risiko
Nach einer Ankündigung ändern sich Pricing, Index-Optionen, Modell-Coverage und Region-Verfügbarkeit schnell. Vor jeder Architekturentscheidung gilt der aktuelle Produktstand statt des Zustands zum Zeitpunkt dieses Artikels.
Fazit
Lakebase Search lohnt sich, wenn operative Agenten-Daten ohnehin in Lakebase Postgres liegen und ein zusätzlicher Vector Store mehr Betriebsaufwand als Nutzen bringt.
Lakebase Search ist besonders sinnvoll, wenn die operativen Daten eines Agenten ohnehin in Lakebase Postgres gespeichert werden und ein zusätzlicher Vector Store mehr Betriebsaufwand erzeugt als Nutzen bringt gegenüber der tatsächlich benötigten Suchqualität. Besonders relevant ist das für Agentenarchitekturen mit App-Zustand und Memory, für mittelgroße redaktionell gepflegte Wissensbestände und für interne Suchfunktionen in Anwendungen, bei denen aktuelle Postgres-Daten sofort auffindbar sein müssen und heute über ein zweites System abgewickelt werden.
Gute Kandidaten erkennt man an typischen Signalen: eine Synchronisationspipeline zwischen operativer Datenbank und Vector Store, die regelmäßig verzögert ist. Berechtigungen, die auf Unity Catalog und ein separates Vector-Store-Modell verteilt sind. Embeddings, die nicht zum aktuellen Datenstand passen. Audit-Fragen, die nur durch Abgleich mehrerer Systeme beantwortet werden können. Ein Agent, der Knowledge-Records im selben Turn schreibt und lesen will. Mehr Monitoring auf der bestehenden Pipeline löst diese Grundprobleme meist nicht. Sie werden kleiner, wenn die passende Suchschicht gewählt wird.
Wenn Lakebase noch nicht produktiv genutzt wird oder wenn der Wissensbestand von Beginn an sehr groß und Lakehouse-zentriert ist im Embedding-Lifecycle, sollte die erste Entscheidung anders ausfallen. Dann ist Mosaic AI Vector Search auf Delta meist der naheliegende Startpunkt, und der Hauptaufwand liegt dann bei Embedding-Pipeline, Re-Indexierung und Betrieb des Wissenskorpus.
Mein Vorschlag: Die Standardsuchschicht sollte dort liegen, wo der Inhalt ohnehin sinnvoll gespeichert und gepflegt wird. Diese Klärung lohnt sich vor dem ersten produktiven Agenten und vermeidet spätere Re-Architektur.
Eine gute Retrieval-Architektur hat nicht möglichst viele Suchsysteme. Sie hat für jede Suchanfrage einen klaren Datenpfad, eine klare Identität und eine nachvollziehbare Quelle.
Legt für jede neue Agentenarchitektur pro Anwendungsfall eine klare Grenze fest, ab wann Lakebase Search trägt und wann Mosaic AI Vector Search beginnt.
FAQ
Lakebase Search ist eine native Such-Schicht in Lakebase Postgres, die Volltext-, Vektor- und Filter-Suche in einer Query und einer Transaktion zusammenführt. Sie ist als agent-natives Retrieval direkt im OLTP-Store gedacht, ohne separates Vector-Store-System. Indexierung erfolgt im Schreibpfad: Schreib-Operationen aktualisieren die zugehörigen Indizes innerhalb derselben Transaktion wie die Tabellenzeile.
