Vector Search Indexes and Endpoints

What it is

Mosaic AI Vector Search stores embeddings of your chunks and returns the closest ones to a query. It is the retriever behind most RAG applications on Databricks. It is called Databricks AI Search in newer docs; the exam guide keeps the Vector Search name.

It has two building blocks: an endpoint, the compute that serves queries, and an index, the searchable copy of your vectors, governed in Unity Catalog with a catalog.schema.index name.

How it works

Index types

A Delta Sync index needs Change Data Feed on the source table for standard endpoints (a table with row tracking enabled uses it automatically). It runs in triggered mode, where you start each sync, or continuous mode, which keeps the index close to real time at higher cost. A Direct Vector Access index never syncs by itself; your code upserts rows.

Endpoint types

Choose by the requirement the scenario states. Very large corpora and cost pressure point to storage optimized; tight latency, a high query rate or continuous freshness point to standard.

Creating an index

You create an endpoint, then an index on it. With managed embeddings you name the source column and the embedding endpoint.

index = client.create_delta_sync_index(
    endpoint_name="docs_endpoint",
    source_table_name="main.docs.chunks",
    index_name="main.docs.chunks_index",
    pipeline_type="TRIGGERED",
    primary_key="chunk_id",
    embedding_source_column="text",
    embedding_model_endpoint_name="databricks-qwen3-embedding-0-6b")

Here client is a VectorSearchClient from databricks.vector_search.client. That package is now a deprecated alias of the renamed SDK, which keeps the same method names. A triggered index is refreshed with index.sync(); a Direct Vector Access index is created with create_direct_access_index and written with index.upsert([...]).

Querying an index

index = client.get_index(index_name="main.docs.chunks_index")
results = index.similarity_search(
    query_text="How do I enable Change Data Feed?",
    columns=["chunk_id", "text", "source_url"],
    num_results=5,
    filters={"product": "Delta Lake"})

With managed embeddings you pass query_text and the index embeds it with the same model. With self managed embeddings you pass query_vector yourself. columns chooses what comes back, and filters narrows results by metadata columns: a dictionary on standard endpoints, a SQL like string on storage optimized ones.

Hybrid search and re ranking

query_type="hybrid" runs vector and keyword (full text) search together and merges the two rankings, which helps with exact terms such as product codes or error IDs. A re ranker then rescores a small candidate set: a cross encoder reads the query and each passage together, which is more accurate than vector distance but too slow to run on the whole index.

How the exam asks about this

• "Documents land in a Delta table nightly and the index must reflect them each morning at the lowest cost." Use a Delta Sync index in triggered mode and run sync() after the load.
• "An application streams new vectors that are not stored in any table." Use a Direct Vector Access index and upsert.
• "Two billion embeddings, cost matters, a little extra latency is acceptable." Use a storage optimized endpoint.