Databricks Vector Search: RAG-Search direkt im Lakehouse betreiben
Die Kernaussagen auf einen Blick.
- Databricks Vector Search ist die verwaltete Suchschicht für RAG-Anwendungen direkt in Databricks. Quellen, Embeddings, Index, Berechtigungen und Audit bleiben damit näher an Unity Catalog und am bestehenden Lakehouse.
- Der größte Vorteil liegt im einfacheren Betrieb: weniger separate Synchronisierung, weniger zusätzliche Governance und weniger eigene Infrastruktur neben Databricks.
- Für RAG auf Daten, die bereits im Lakehouse liegen, sollte Vector Search zuerst geprüft werden. Eine externe Vektor-Datenbank wie Pinecone, Qdrant oder pgvector lohnt sich vor allem bei sehr großen Indizes, harten Latenzanforderungen oder bestehenden Plattformvorgaben.
- Vor der Tool-Entscheidung sollten zuerst Datenmodell, Berechtigungen, Embedding-Strategie und Qualitätsmessung geklärt werden. Die Vektor-Datenbank allein entscheidet nicht, ob eine RAG-Anwendung gute Antworten liefert.
Inhaltsverzeichnis
Für RAG braucht es keine separate Vector Database
Viele RAG-Piloten starten mit Pinecone oder einer ähnlichen Vektordatenbank. Für den ersten Prototyp ist das oft der schnellste Weg: Notebook bauen, Dokumente aufteilen, Embeddings erzeugen, Index befüllen und erste Antworten testen.
Die eigentlichen Fragen kommen meist später. Der Index muss dauerhaft aktuell bleiben, Berechtigungen müssen sauber greifen, und es muss nachvollziehbar sein, wo Embeddings liegen und wer darauf zugreifen darf. Was im Piloten noch einfach wirkt, wird im produktiven Betrieb schnell zu einem eigenen Daten- und Governance-Thema.
In vielen Databricks-Umgebungen entsteht dadurch eine zweite Datenhaltung neben dem Lakehouse. Die Quelltabellen liegen bereits in Unity Catalog, mit Berechtigungen, Lineage und Audit. Die Embeddings liegen aber in einem separaten System, mit eigener Synchronisierung, eigenen Zugriffsregeln und eigenem Betrieb. Damit entsteht genau die Trennung, die das Lakehouse eigentlich reduzieren soll.
Vor der Entscheidung für Vector Search oder eine externe Vektordatenbank sollten deshalb einige Fragen geklärt werden:
- Wie viele Dokumente, Dateien oder Chunks sollen heute indexiert werden, und wie stark wächst diese Menge in den nächsten zwölf Monaten?
- Wer darf auf welche Indizes zugreifen?
- Wie bleibt der Index aktuell, wenn sich Quelltabellen, Dokumente oder Schemata ändern?
- Was passiert mit den Kosten, wenn aus 100.000 Chunks plötzlich 10 Millionen werden?
- Welche Anforderungen gibt es an Region, Hosting, Datenschutz und Betrieb?
Die Entscheidung ist deshalb nicht nur eine Performancefrage. Es geht vor allem darum, wo Daten und Embeddings liegen, wie sie aktuell gehalten werden, wie Berechtigungen greifen und wer den Betrieb langfristig verantwortet.
Was ist Databricks Vector Search?
Databricks Vector Search ist ein verwalteter Dienst für Vektorindizes innerhalb der Databricks-Plattform. Der Dienst speichert Embeddings und ermittelt über Approximate-Nearest-Neighbor-Verfahren semantisch ähnliche Einträge und liefert die Top-K-Ergebnisse für RAG-Pipelines, semantische Suche oder AI Agents. Support-Anfragen wie „Konto gesperrt“ oder „Login schlägt fehl“ liegen im selben Vektorraum nah beieinander, während Abrechnungsthemen wie „Rechnung fehlerhaft“ ein eigenes Cluster bilden. Eine neue Query wird in denselben Raum eingebettet und findet über die Nächste-Nachbarn-Suche die semantisch ähnlichsten Einträge, unabhängig von den tatsächlich verwendeten Wörtern.
Vector Search muss nicht als separates Daten- und Governance-System betrieben werden. Vector Search lässt sich direkt mit Tabellen in Unity Catalog verbinden. Berechtigungen und Ownership können über dieselben Governance-Strukturen verwaltet werden, und Lineage wird in den Catalog geschrieben. Quelle und darauf basierender Index bleiben damit innerhalb einer gemeinsamen Governance-Schicht.
Die Folge: Berechtigungen für Quelle und Index müssen konsistent verwaltet werden, damit Nutzer nur auf zulässige Inhalte zugreifen können. Das Löschen einer Tabelle macht die Abhängigkeit der Vector-Indizes in Lineage sichtbar. Quellinhalte und Retrieval-Index werden nicht mehr über vollständig getrennte Governance- und Auditprozesse verwaltet.
Die Architektur besteht im Wesentlichen aus drei Komponenten: der Vector-Search-Endpoint (die bereitgestellte Rechenkapazität für Indexierung und Abfragen), der Vector-Search-Index (die Datenstruktur mit den Embeddings) und die Embedding-Quelle (Foundation Model oder externes Modell). Endpunkt, Index und Embedding-Modell können abhängig vom jeweiligen Workload konfiguriert werden.
Vector Search ist Teil des KI-Stacks auf Databricks und ergänzt dort die anderen Plattform-Komponenten für produktive KI-Workloads.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Databricks Vector Search, Mosaic AI Vector Search und AI Search einordnen
Die Begriffe werden oft nicht sauber getrennt. In Dokus, Architekturgesprächen und internen Abstimmungen führt das schnell zu Missverständnissen.
Vector Search
Der technische und verbreitetste Name. So heißt der Dienst in der Python-SDK, in der REST-API (databricks-vectorsearch) und im Großteil der bestehenden Architektur-Dokumentation.
Mosaic AI Vector Search
Derselbe Dienst unter dem Markendach Mosaic AI, unter dem Databricks seinen KI-Stack aus Model Serving, Agent Framework und Vector Search zusammenfasst. Taucht vor allem in Produkt- und Marketing-Kontexten auf.
Databricks AI Search
Die neuere Bezeichnung, die Databricks zusätzlich in Teilen der Dokumentation verwendet: gemeint ist dieselbe verwaltete Retrieval-Schicht.
SDK-Paketname, Index-Objekt und Governance-Modell bleiben identisch, unabhängig davon, welcher Name in der jeweiligen Quelle steht. Für eine Architekturentscheidung ist die Bezeichnung damit nachrangig. Es zählen Index-Typ, Embedding-Quelle und die Governance über Unity Catalog.
Delta Sync Index vs Direct Vector Access Index
Zunächst muss entschieden werden, wie der Index mit Daten versorgt und aktuell gehalten wird. Databricks bietet hier zwei Modi an.
Delta Sync Index hält den Index automatisch mit einer Delta-Tabelle in Unity Catalog synchron. Die Quelle steht in Unity Catalog, den Index lässt du die Embeddings entweder über ein konfiguriertes Modell berechnen oder die Quelltabelle liefert bereits vorberechnete Embeddings. Für die Aktualisierung stehen zwei Pipeline-Modi zur Verfügung: Triggered aktualisiert den Index nur bei einem gezielten Lauf, etwa im Anschluss an einen Batch-Job, und hält die Kosten niedrig, weil zwischen den Läufen kein Compute mitläuft. Continuous hält den Index nahezu in Echtzeit mit der Quelle synchron, dafür läuft die Sync-Pipeline dauerhaft. Die Databricks-Dokumentation zum Delta Sync Index beschreibt beide Modi und die Embedding-Optionen.
Direct Vector Access Index ermöglicht das direkte Schreiben von Vektoren und Metadaten per API. Die Anwendung schreibt Vektoren und Metadaten direkt per API in den Index. Es gibt keine automatische Sync mit einer Quell-Tabelle, dafür liegt die vollständige Verantwortung für Datenänderungen, Löschungen und Synchronisierung bei der Anwendung. Sinnvoll, wenn keine Delta-Tabelle als führende Quelle existiert oder die Sync-Logik selbst gebaut werden soll.
| Eigenschaft | Delta Sync Index | Direct Vector Access Index |
|---|---|---|
| Quelle | Delta-Tabelle in Unity Catalog | beliebige Schreib-Quelle per API |
| Sync | automatisch (Triggered/Continuous) | manuell (Anwendung verantwortet) |
| Embedding | Plattform oder vorberechnet | immer von außen geliefert |
| Schema-Änderungen | Index folgt der Tabelle | Anwendung muss anpassen |
| Typischer Einsatzbereich | RAG auf Lakehouse-Daten | Streaming-Quellen, Custom-Logik |
| Betriebsaufwand | gering | mittel bis hoch |
Für RAG-Anwendungen auf bestehenden Lakehouse-Daten ist ein Delta Sync Index meist der naheliegende Ausgangspunkt. Die Synchronisierung zwischen Quelle und Index wird damit durch die Plattform übernommen: keine separat entwickelte Synchronisierungspipeline. Direct Vector Access eignet sich weiterhin für Anwendungen mit eigener Daten- und Schreiblogik, wenn die Embeddings aus einem Stream oder aus einer Anwendung kommen, bei denen keine Delta-Tabelle als führende Datenquelle vorgesehen ist.
Foundation Model APIs, externe Modelle oder MLflow
Anschließend muss das geeignete Embedding-Modell und dessen Betriebsform ausgewählt werden. Dafür stehen drei typische Ansätze zur Verfügung, darunter Databricks Foundation Model APIs als verwalteter Service.
Foundation Model APIs
Liefern Embedding-Modelle wie BGE Large oder GTE als verwalteten Service. Abrechnung über DBUs, Verarbeitung innerhalb der konfigurierten Databricks-Umgebung, oft der einfachste Governance-Pfad bei erhöhten Datenschutz- und Datenresidenzanforderungen.
Externe Embedding-Provider
OpenAI, Azure OpenAI, Anthropic oder Cohere lassen sich über einen verwalteten Modellendpunkt integrieren, der Authentifizierung und Protokollierung zentralisiert. Sinnvoll bei Qualitätsanforderungen an ein bestimmtes Modell oder bestehenden Vendor-Standards.
Eigene Embedding-Modelle
Auf MLflow Model Serving trainiert oder fein-getunt, für stark domänenspezifische Begriffe, mehrsprachige Nischen-Dokumente oder Code-Embeddings. Höchster Entwicklungs- und Betriebsaufwand, oft beste Retrieval-Qualität bei spezialisierten Daten.
Das verwendete Embedding-Modell beeinflusst die Retrieval-Qualität häufig stärker als die Wahl der Vektordatenbank. Ein allgemeines Modell kann bei juristischen, medizinischen oder technischen Dokumenten deutlich schlechtere Ergebnisse liefern als ein domänenspezifisches Modell. Vor einem Plattformvergleich sollten deshalb mehrere Embedding-Modelle auf demselben Dokumentenbestand getestet werden.
Unity Catalog Governance für Vector Search: Berechtigungen, Lineage und Audit
Der erste Vorteil zeigt sich schon vor der Governance-Frage: Vector Search ist ein integrierter, verwalteter Dienst innerhalb der Plattform und muss nicht als eigenes System betrieben werden. Es gibt keinen separaten Cluster, keine zusätzliche Datenbank-Instanz und kein zweites Betriebsmodell, das gepatcht, skaliert und überwacht werden muss. Bei Pinecone, Qdrant oder einem selbst-gehosteten Dienst kommt genau dieser Betrieb als eigene Aufgabe hinzu.
Der zweite Vorteil ist die Integration in Unity Catalog, und das ist der wesentliche Unterschied zu einer separat betriebenen Vektordatenbank. Vector-Search-Indizes sind regulär verwaltete Objekte in Unity Catalog. Indizes werden wie andere Unity-Catalog-Objekte über Katalog, Schema und Namen adressiert (catalog.schema.index), über vergleichbare Berechtigungsmechanismen verwaltet wie Tabellen, sie erscheinen in der Catalog-UI mit Tags und Beschreibungen.
Berechtigungen funktionieren auf zwei Ebenen: der Endpoint trägt eigene Permissions (anlegen, abfragen, verwalten), der Index trägt zusätzliche Permissions (lesen, schreiben, löschen). Eine Anwendung, die den Index abfragen will, braucht das USE CATALOG-, USE SCHEMA- und SELECT-Privileg auf dem Index. Das Berechtigungsmodell orientiert sich damit an den bestehenden Unity-Catalog-Strukturen.
Bei Delta Sync Indizes kann die Abhängigkeit zwischen Quelltabelle und Index in der Lineage sichtbar werden. Im Catalog zeigt die Quell-Tabelle eines Delta Sync Index die Abhängigkeit zum Vector-Search-Index, und der Index zeigt zurück auf die Quelle. Bei Schema-Änderungen oder Tabellen-Löschungen wird die Folge sichtbar, bevor Änderungen unbemerkt zu Fehlern im produktiven Retrieval führen.
Zugriffe und Änderungen können über die Audit- und Systemprotokolle der Plattform ausgewertet werden. Welche Identität zu welchem Zeitpunkt einen Index verwendet oder verändert hat, welche Abfragen liefen, welche Berechtigungen sich änderten: das ist Teil der gleichen Logs, die für SQL-Workloads und Notebook-Sessions ohnehin gepflegt werden. Bei einer externen Vektordatenbank müssen Auditinformationen zusätzlich integriert und mit den Plattformlogs zusammengeführt werden. Für eine vollständige Nachvollziehbarkeit ist dann eine systemübergreifende Auditierung erforderlich.
Wie Unity Catalog das Berechtigungs- und Lineage-Modell trägt, klären wir im Überblick zu Unity Catalog als Governance-Schicht der Databricks-Plattform.
Chunking, Retrieval, Reranking und Antwort
Vector Search übernimmt innerhalb einer RAG-Architektur ausschließlich den Retrieval-Schritt. Eine produktive RAG-Architektur umfasst in der Regel vier Verarbeitungsschritte.
Von der Delta Table zum Endpoint.
Daten liegen in Unity-Catalog-governed Delta Tables. Vector Search baut daraus einen HNSW- oder IVF+PQ-Index und serviert Queries über drei Endpoint-Typen, alles serverlos, ohne separate Pipeline.
Delta Lake
ParquetQuelle und Chunking. Die Dokumente liegen als Bronze-Tabelle in Delta. Ein Verarbeitungsschritt teilt die Dokumente in geeignete Abschnitte und speichert sie in einer Silver-Tabelle mit Quell-ID, Position und Metadaten. Die geeignete Länge und Überlappung hängen vom Dokumenttyp und der späteren Abfrage ab. Die Qualität des Chunkings entscheidet über die RAG-Qualität in vielen Fällen ebenso stark wie das verwendete Embedding-Modell.
Embedding und Index. Anschließend werden für die vorbereiteten Abschnitte Embeddings erzeugt (entweder per Foundation Model oder externes Modell) und in die Silver-Tabelle oder direkt in den Vector-Search-Index geschrieben. Bei einem Delta Sync Index übernimmt Databricks die Aktualisierung des Index aus der Quelltabelle.
Retrieval. Der Agent oder die Anwendung ruft den Vector-Search-Endpoint auf, übergibt die Suchanfrage des Nutzers (entweder als Text oder als bereits eingebetteter Vektor), liefert die am höchsten bewerteten Treffer einschließlich der zugehörigen Metadaten. Optional läuft ein Re-Ranker (z. B. ein Cross-Encoder) auf den Treffern, um die Relevanzbewertung der Treffer weiter zu verbessern. Eine hybride Suche verbindet semantische Ähnlichkeit mit klassischer Volltextsuche. Wann der gleiche Index als Hybrid-Lookup direkt aus der OLTP-Schicht heraus sinnvoller ist, klären wir im Überblick zu Lakebase Search.
Generierung und Antwort. Die Retrieval-Treffer werden dem Sprachmodell als zusätzlicher Kontext bereitgestellt (über Databricks Foundation Model APIs oder externe Provider). Das Modell formuliert die Antwort, idealerweise mit nachvollziehbaren Verweisen auf die verwendeten Quellen.
Vector Search lässt sich über drei Wege ansprechen. Erstens über die Databricks Vector Search SDK (Python), die in Notebooks und Jobs direkt nutzbar ist. Zweitens über die REST-API, die auch von externen Anwendungen oder LangChain/LlamaIndex-Pipelines aufgerufen wird. Drittens über das Mosaic AI Agent Framework, das den Retrieval-Schritt als Komponente eines Agenten kapselt. Der Agent ruft Vector Search transparent auf, die Anwendung ergänzt fachliche Steuerung, Antwortformat und weitere Agentenlogik.
Eine RAG-Pipeline auf dieser Architektur sollte wie ein produktives Daten- oder KI-Produkt betrieben werden. Sie hat Owner, Schema-Verträge zwischen den Schichten, Monitoring auf Retrieval-Qualität und Kosten und ein reproduzierbarer Aktualisierungs- und Deployment-Prozess.
Databricks Vector Search vs Pinecone, Qdrant, pgvector und Weaviate
Die Alternativen zu Vector Search unterscheiden sich vor allem im Betrieb. Entscheidend ist nicht nur die Suche selbst, sondern wie Daten in den Index kommen, wie Berechtigungen greifen, welche Skalierung gebraucht wird und wer das System später betreut. Die folgende Übersicht ordnet die gängigen Optionen entlang dieser Fragen ein.
| System | Architektur | Lakehouse-Sync | Governance | Typischer Skalierungsbereich | Vendor |
|---|---|---|---|---|---|
| Databricks Vector Search | verwaltet, Plattform | nativ (Delta Sync Index) | Unity Catalog | Abhängig von Endpunkttyp, Abfragemuster und aktueller Produktunterstützung | Databricks |
| Pinecone | verwaltet, Cloud-nativ | manuell | eigenes IAM | bis ~Milliarden | Pinecone |
| Qdrant | verwaltet oder selbst-gehostet | manuell | eigene Permissions | bis ~hunderte Mio | Qdrant |
| pgvector | Postgres-Extension | manuell | Postgres-Rollen | bis ~10 Mio Vektoren | OSS / Hyperscaler |
| Weaviate | verwaltet oder selbst-gehostet | manuell | eigene Permissions | bis ~hunderte Mio | Weaviate |
| Milvus | selbst-gehostet, verteilt | manuell | eigene Permissions | bis ~Milliarden | OSS / Zilliz |
Die Übersicht ist nur ein erster Orientierungspunkt. Sie ersetzt keinen technischen Vergleich mit den eigenen Daten und Abfragen. Latenz, Trefferqualität und Kosten hängen unter anderem vom Embedding-Modell, vom Index-Typ, von der Abfragelast und vom eingesetzten Compute ab.
Eine belastbare Entscheidung sollte deshalb mit einem eigenen Benchmark getroffen werden: mit den echten Dokumenten, den typischen Suchanfragen und den erwarteten Lastprofilen. Herstellerangaben und allgemeine Benchmarks reichen dafür nicht aus.
Wann passt eine externe Vector Database besser?
Bestimmte Anforderungen können weiterhin für eine spezialisierte Vektordatenbank sprechen. Das gilt vor allem in vier Situationen.
Wenn der Index sehr groß wird. Bei mehreren hundert Millionen oder Milliarden Embeddings sollte geprüft werden, ob eine spezialisierte Vektordatenbank besser passt. Systeme wie Pinecone, Milvus oder Qdrant sind genau für große, verteilte Vektorindizes gebaut. Ob sich das lohnt, hängt aber nicht nur von der Größe ab, sondern auch von Kosten, Betrieb und Zugriffsmustern.
Wenn sehr niedrige Latenz verbindlich zugesichert werden muss. Für viele RAG-Anwendungen reicht die Latenz von Vector Search aus. Anders sieht es aus, wenn ein Endkunden-Use-Case dauerhaft Antwortzeiten im sehr niedrigen Millisekundenbereich braucht. Dann sollte gegen spezialisierte Systeme getestet werden, statt sich auf allgemeine Erfahrungswerte zu verlassen.
Wenn bereits eine Vektordatenbank produktiv läuft. Eine bestehende Pinecone-, Qdrant- oder pgvector-Umgebung sollte nicht ohne klaren Grund ersetzt werden. Entscheidend ist, ob eine Konsolidierung auf Vector Search den Betrieb wirklich vereinfacht oder ob Migration, Umstellung und neue Betriebsprozesse mehr Aufwand erzeugen als Nutzen.
Wenn die Daten kaum im Lakehouse liegen. Vector Search spielt seine Stärken vor allem aus, wenn die Daten bereits in Delta-Tabellen und Unity Catalog verwaltet werden. Wenn die relevanten Inhalte überwiegend aus externen APIs, Drittanbieter-Systemen oder transaktionalen Quellen außerhalb des Lakehouses kommen, ist der Integrationsvorteil kleiner.
Entscheidend ist, wo die Daten liegen, wie groß der Index wird, welche Latenz wirklich gebraucht wird und welches System im Betrieb am besten zur bestehenden Plattform passt.
Was kostet Databricks Vector Search?
Die Kosten setzen sich im Wesentlichen aus drei Bestandteilen zusammen. Laufzeit und Größe des Endpunkts (das laufende Compute), Storage (die Größe des Index in GB) und Aufrufe des verwendeten Embedding-Modells (für Indizes, die Embeddings über Plattform-Modelle erzeugen). Databricks dokumentiert die aktuellen Pricing-Komponenten für Vector Search öffentlich; die Konditionen lassen sich an die Cloud-Region und das Account-Profil anpassen.
Bei dauerhaft verfügbaren Endpunkten stellt der Compute häufig den größten Kostenblock dar. Ein Standard-Endpoint läuft kontinuierlich und wird stundenweise abgerechnet. Dieser Compute verarbeitet Indexaktualisierungen und Suchabfragen. Ein Storage-optimized Endpoint ist für sehr große Indizes mit niedrigerer Query-Last gedacht und ist auf andere Kosten- und Performanceprofile als ein Standardendpunkt ausgerichtet.
Storage-Kosten skalieren mit der Größe des Index. Bei kleinen Indizes (unter einer Million Vektoren) ist das ein nachrangiger Posten. Bei sehr großen Indizes wird auch der Speicherbedarf zu einem relevanten Kostenfaktor.
Embedding-Calls fallen an, sobald der Index die Embeddings selbst über Foundation Models erzeugt. Eigene Embeddings, vorab in der Quell-Tabelle berechnet (z. B. einmal per Batch-Job), verlagern die Kosten in einen separaten Batch- oder Modellprozess. Eine mögliche Kostenoptimierung: Embeddings werden nur bei neuen oder geänderten Inhalten neu berechnet und nicht bei jedem Sync neu berechnet.
Im Vergleich zu externen Anbietern ist die Kostenlogik eine andere. Pinecone und Qdrant rechnen primär nach Pod- oder Cluster-Klassen plus Storage. pgvector kostet das, was die Postgres-Instanz darunter kostet. Das ist günstig bei kleinen Skalen, aber teuer, sobald die Hauptdatenbank nicht für Vektor-Operationen ausgelegt ist. Ein mehrjähriger Kostenvergleich, der ausschließlich Listenpreise berücksichtigt, lässt häufig Entwicklung, Synchronisierung, Monitoring und Governance unberücksichtigt.
Was Vector Search nicht löst
Vector Search löst die Suche im Vektorindex. Die Qualität einer RAG-Anwendung hängt aber nicht nur vom Index ab, sondern vom gesamten Zusammenspiel aus Dokumentenaufbereitung, Embeddings, Retrieval, Prompt und Sprachmodell.
Chunking bleibt entscheidend
Zu große Abschnitte vermischen Themen, zu kleine verlieren Kontext. PDFs, Tabellen und Code-Blöcke liefern schlechte Treffer bei starrer Gleichteilung. Die bessere Antwort kommt meist aus besserer Vorverarbeitung, nicht aus einer anderen Vektordatenbank.
Embedding-Modell muss zum Inhalt passen
Ein generisches Modell reicht für viele Standardfälle. Bei juristischen, medizinischen oder sehr branchenspezifischen Texten kann ein angepasstes Modell deutlich bessere Treffer liefern.
Hybrid Search braucht eigenes Tuning
Reine semantische Suche ist schwächer bei Produktnummern, Eigennamen, IDs oder exakten Begriffen. Hybrid Search aus Vektor- und Volltextsuche verlangt zusätzliche Konfiguration, Tests und laufende Qualitätsmessung.
Prompt und Kontext entscheiden über die Antwort
Auch gute Treffer führen nicht automatisch zu guten Antworten. Re-Ranking, Kontext-Komprimierung und ein sauber aufgebauter Prompt bleiben Teil der RAG-Architektur.
Embeddings sind Teil der Governance
Sensible Inhalte müssen auch bei Embedding-Erzeugung, Speicherung und Modellaufrufen berücksichtigt werden, insbesondere bei personenbezogenen Daten, Datenresidenz oder externer Modellverarbeitung.
Latenz, Recall und Kosten mit echten Daten messen
Allgemeine Benchmarks helfen nur begrenzt. Nur ein eigener Test mit den echten Dokumenten, Suchanfragen und Lastprofilen zeigt, ob Vector Search zum geplanten Betrieb passt.
Vector Search ist also ein wichtiger Baustein, aber nicht die ganze RAG-Lösung. Die eigentliche Entscheidung sollte immer im Zusammenhang mit Datenaufbereitung, Embedding-Strategie, Governance, Prompt-Design und Betriebsmodell getroffen werden.
Fazit
Databricks Vector Search lohnt sich vor allem dann, wenn die Daten bereits im Lakehouse liegen und über Unity Catalog verwaltet werden.
Damit bleiben Quellen, Berechtigungen, Lineage und Embeddings näher beieinander. Eine separate Vektordatenbank würde dagegen zusätzliche Synchronisierung, eigene Zugriffsregeln und einen weiteren Betriebsprozess mitbringen.
Typische Einsatzszenarien sind:
- RAG-Pipelines auf Delta-Tabellen und Unity-Catalog-Daten
- Wissensassistenten, die bestehende Berechtigungen berücksichtigen müssen
- AI Agents, die mehrere Datenprodukte gemeinsam durchsuchen
- semantische Suche auf Dokumenten, Dateien oder Tabellen im Lakehouse
- Anwendungen mit höheren Anforderungen an Audit, Datenresidenz und Zugriffskontrolle
Wenn die relevanten Daten kaum im Lakehouse liegen, bereits eine produktive Vektordatenbank betrieben wird oder sehr harte Latenzanforderungen bestehen, sollte Vector Search nicht automatisch gesetzt werden. Dann kann Pinecone, Qdrant, pgvector oder ein anderes System weiterhin die bessere Wahl sein.
Für neue RAG-Anwendungen auf Databricks-Daten sollte Vector Search zuerst geprüft werden. Ein Vergleich mit Pinecone, Qdrant oder pgvector lohnt sich vor allem bei besonderen Anforderungen an Latenz, Skalierung oder Portabilität. Die Reihenfolge sollte dabei klar bleiben: erst Datenmodell und Governance klären, dann Embedding- und Retrieval-Strategie festlegen und danach das passende Vektorsystem auswählen.
Vereinfacht Vector Search eure RAG-Architektur?
- welche eurer Use Cases echte Kandidaten für Vector Search sind
- welche Governance-, Compliance- und Betriebsrisiken vor dem Rollout geprüft werden sollten
- welcher Architekturansatz zu eurer Plattform und eurem RAG-Stack passt
FAQ
Databricks Vector Search ist eine verwaltete Vektor-Datenbank in der Data Intelligence Platform. Sie speichert Embeddings, sucht semantisch über approximative Nearest-Neighbor-Algorithmen und integriert sich nativ in Unity Catalog für Berechtigungen, Lineage und Audit. Seit 2026 firmiert das Produkt zusätzlich unter dem Namen Databricks AI Search.
