Key Takeaways
Databricks Vector Search is now called Databricks AI Search. It is the managed retrieval service built into the Databricks platform: it indexes Delta tables into vectors, keeps them in sync with the source, and serves similarity, hybrid and filtered queries for RAG applications, all governed by Unity Catalog. The Python SDK is now the databricks-ai-search package.
- Cost: you pay for the search endpoint plus embedding compute, so endpoint type and sync mode drive the bill more than query volume does.
- Effort: a first index takes hours; clean chunking, metadata and a sync schedule take weeks.
- Risk: indexes do not support row- or column-level permissions, so sensitive content needs its own index or filtering design.
- Fit: best when the documents and tables already live in the lakehouse; weakest when the content sits outside Databricks and changes hourly.
Retrieval-augmented generation looks simple on a whiteboard: chunk the documents, embed them, retrieve the closest matches, hand them to a model. In production, the retrieval layer is where most answers go wrong, because the index is only as good as the data behind it. A Cloudera and Harvard Business Review Analytic Services study from March 2026 found only 7% of enterprises describe their data as completely ready for AI.
The people who would fix that are busy. The Fivetran 2026 benchmark put 53% of engineering capacity on pipeline maintenance. A separate vector database with its own sync jobs, its own permissions and its own on-call rota adds to that load. Keeping retrieval inside the lakehouse, next to the tables it indexes, removes a whole system from the diagram.
This guide covers the rename, how the service works, the design choices that decide answer quality, where teams run into trouble, and the signals that tell you whether you are ready to build.
Vector Search Is Now Databricks AI Search
The product documentation now opens with “Databricks AI Search (formerly Databricks Vector Search).” You will also see the older “Mosaic AI Vector Search” name in blog posts and tutorials from 2024 and 2025. All three names refer to the same service.
The client library followed. The databricks-ai-search package on PyPI is described as the Databricks AI Search Client (formerly Vector Search), with version 0.78 released on 3 August 2026. Install it with pip install databricks-ai-search. The older databricks-vectorsearch package is being phased out, and class aliases keep existing code working, so nothing breaks the day you switch. Update new projects to the new package and plan the swap for old ones during normal maintenance.
The rename also signals scope. The service now covers hybrid keyword and similarity search, reranking and full-text search, not only nearest-neighbour vectors. That matters for RAG, where exact product codes and policy numbers often retrieve better by keyword than by meaning.
How AI Search Works on the Lakehouse
Two decisions shape everything else: the index type and the endpoint type.
Index types. A Delta Sync Index reads a source Delta table and keeps itself current. It comes in two flavours: Databricks-managed embeddings, where the platform computes vectors from a text column, and self-managed embeddings, where you supply precomputed vectors. Sync uses the table’s Change Data Feed and runs in triggered or continuous mode. A Direct Vector Access Index skips the table entirely; your code writes vectors through the REST API and no automatic sync happens. A dedicated full-text index exists as well, available only on storage-optimized endpoints with triggered sync.
Endpoint types. A standard endpoint holds roughly 320 million vectors at 768 dimensions, according to the documentation. A storage-optimized endpoint holds over one billion vectors at the same dimension and indexes 10 to 20 times faster, with about 250 milliseconds of added query latency. For most mid-market RAG workloads the standard endpoint is the right start; storage-optimized earns its place when the corpus is very large or rebuilds are slow.
| Choice | Pick it when | Watch out for |
|---|---|---|
| Delta Sync, managed embeddings | Source is a governed Delta table with a text column | Embedding compute on every changed row |
| Delta Sync, self-managed embeddings | You already compute embeddings in a pipeline | You own embedding model versioning |
| Direct Vector Access | Vectors come from an app, not a table | No automatic sync; drift is your problem |
| Standard endpoint | Latency matters and the corpus is moderate | Capacity ceiling around 320 million vectors |
| Storage-optimized endpoint | Very large corpus or slow rebuilds | About 250 ms added latency |
Design Decisions That Decide Answer Quality
The index is the last step of a pipeline, not the first. Treat the source table as a gold-layer product in your medallion design, with an owner, a schema contract and a freshness target. Our guide to the medallion architecture explains how bronze, silver and gold map onto that ownership.
- Chunk in silver, not at query time. Store one row per chunk with a stable chunk ID, the parent document ID, the section heading and the effective date. Those columns become your filters.
- Filter before you rank. Metadata filters on region, product line or document status stop the retriever from pulling a retired policy just because its wording matches.
- Use hybrid search for codes and names. Part numbers, SKUs and clause references retrieve better through keyword matching. Hybrid search combines both methods in one query.
- Add reranking once you have a baseline. Reranking improves ordering, but you need an evaluation set first to prove it helped.
Guardrails on what the model is allowed to say with the retrieved context are a separate layer. We cover that in RAG guardrails.
Where RAG on Databricks Breaks
Slow first builds
Community threads repeatedly report initial index builds that crawl when embeddings are computed one row at a time. Before blaming the platform, check whether the embedding model endpoint has enough throughput provisioned and whether the source table is far larger than it needs to be. Storage-optimized endpoints index faster when the corpus genuinely is huge.
Permissions that do not follow the data
The documentation states that indexes appear in and are governed by Unity Catalog, but row- and column-level permissions are not supported on them. If one table mixes content for different audiences, the index cannot enforce the row filter the table had. Split sensitive content into separate source tables and separate indexes, and grant access per index.
Stale answers from a forgotten sync
A triggered index only refreshes when something triggers it. Teams schedule the source pipeline in Lakeflow Jobs and forget to add the sync step, so the table is current and the index is a week old. Chain the sync into the same job and alert on lag.
Change Data Feed switched off
Delta Sync on a standard endpoint needs Change Data Feed enabled on the source table. A table recreated by a careless overwrite loses that setting and breaks incremental sync. Set it in the table definition, not by hand.
Cost creep from continuous sync
Continuous sync keeps an index fresh within minutes, and it keeps compute running to do so. Most document corpora change daily at most. Default to triggered sync and justify continuous mode with a real freshness requirement.
Signals You Are Ready to Build, and Signals You Are Not
Score yourself honestly against both lists before you commit a quarter to a RAG build.
You are ready when:
- The source documents land in Unity Catalog with one owner per collection and superseded versions removed.
- You can name the freshness target for each index in hours or days.
- Sensitive and general content already sit in separate tables.
- A business expert has written 50 or more real questions with expected answers.
- Your Unity Catalog metastore and serverless compute are enabled in a supported region.
You are not ready when:
- Nobody can say which version of a document is authoritative.
- The plan is to “index everything” and filter later.
- Access rules exist only as row filters on a shared table.
- Success is defined as “the demo looked good.”
If most of the second list describes you, fix the process first. That is AIM-IT in practice: Assess the document flow, Innovate on ownership, Model the index design, then Implement and Track. For a view of what a full build costs once you are ready, see our breakdown of enterprise RAG implementation cost, and if you want an outside team to run it, our Databricks consulting practice builds retrieval on the lakehouse you already own.
Frequently Asked Questions (FAQs)
Is Databricks Vector Search the same as Databricks AI Search?
Yes. Databricks renamed Vector Search to Databricks AI Search, and the documentation now uses the new name with a “formerly Databricks Vector Search” note. Older material also calls it Mosaic AI Vector Search. All three names describe one service.
Do I need to change my code after the rename?
Not immediately. The new Python package is databricks-ai-search, and class aliases keep code written against databricks-vectorsearch working. Switch new projects to the new package and migrate older ones during routine maintenance.
What is the difference between a Delta Sync Index and a Direct Vector Access Index?
A Delta Sync Index reads a Delta table and updates itself through Change Data Feed, in triggered or continuous mode. A Direct Vector Access Index receives vectors you write through the REST API and has no automatic sync, so keeping it current is your job.
Which endpoint type should I choose for RAG?
Start with a standard endpoint for moderate corpora where latency matters. Move to storage-optimized when the corpus runs toward a billion vectors or rebuilds are too slow, accepting roughly 250 milliseconds of added latency.
Does AI Search enforce row-level security?
No. Indexes are governed by Unity Catalog at the index level, but the documentation states row- and column-level permissions are not supported. Separate sensitive content into its own tables and indexes.
Can AI Search do keyword search as well as vector search?
Yes. It supports hybrid search that combines keyword and similarity matching, plus reranking and metadata filters. Dedicated full-text search is labelled Beta and runs on storage-optimized endpoints only.