Databricks Vector Search is now AI Search, and the rename is not cosmetic

On 1 June 2026, Databricks Vector Search became Databricks AI Search. The release note is two sentences long, and the second is the part that matters: you can now create full-text search indexes without any vectors or embeddings at all. The name changed because the product outgrew it.

Three months later, much of what you will find written about this product still uses the old name, including tutorials that were accurate when they were published. That matters more than a label, because one SQL function was joined by a second one that does something quite different, and the scaling story changed underneath both.

Here is what actually changed, and what you have to decide now that did not exist as a decision before.

What the rename admits

Vector search is a retrieval technique: you turn documents into embeddings, turn the query into an embedding, and find the nearest neighbours. It is very good at meaning and famously mediocre at exact strings. Ask it for a SKU, an error code, or a customer identifier and semantic similarity will confidently hand you something that means almost the same thing, which is worthless when the user typed an exact token.

The product had already grown past pure vectors before the rename. Today it does three things at once:

• Similarity search, using the Hierarchical Navigable Small World (HNSW) algorithm for approximate nearest neighbours (ANN), with L2 distance as the metric. If you want cosine similarity, normalise your embeddings first, at which point L2 ranking and cosine ranking agree.
• Keyword search, scored with Okapi BM25. By default it searches every text or string column, tokenising at word boundaries, stripping punctuation and lowercasing, though a Beta query-time option can limit matching to chosen columns. Dedicated full-text indexes behave differently again: they apply language-specific analyzers rather than that flat treatment.
• Hybrid search, which runs both and fuses the two ranked lists with Reciprocal Rank Fusion, with the fusion parameter set to 60.

A system that can rank by BM25 over string columns with no embeddings in sight is not a vector search engine. Hence the rename, and hence the genuinely new capability that shipped with it: full-text indexes that need no embedding model, no embedding cost, and no embedding refresh. They are not free of constraints, though: a dedicated full-text index requires a storage-optimized endpoint and triggered sync, so you trade the embedding pipeline for a different set of rules.

Two SQL functions that are not the same function

This is the part that trips people up, because both exist, both are current, and their names suggest a rename when in fact they are different tools.

vector_search() is in Public Preview and does what it always did: query one index and return matching rows. You give it an index name and either a query_text or a query_vector, and you get results back. It does not run on classic SQL warehouses.

SELECT * FROM vector_search(
  index => 'catalog.schema.my_index',
  query_text => 'why did the checkout fail',
  query_type => 'HYBRID',
  num_results => 10
)

All arguments must be passed by name. Leave query_type off and you get the approximate-nearest-neighbour default, which is the trap described above.

ai_search() is in Beta and is a different shape of thing entirely. You hand it a natural-language question and one or more indexes configured as knowledge sources, and it generates its own optimised search queries, retrieves across all of those sources, deduplicates the results, reranks them by relevance, and then by default synthesises a grounded natural-language answer over what it found.

SELECT ai_search(
  'How do I configure auto-scaling for my SQL warehouse?',
  PARSE_JSON('[{
    "type": "vector_search",
    "config": {
      "index_name": "prod_catalog.docs.support_articles",
      "text_col": "article_body",
      "doc_uri_col": "article_url"
    }
  }]')
) AS result

The knowledge sources go in positionally as a JSON array, not as a named argument, and each one is wrapped in a type envelope. You can pass up to ten, and vector_search is currently the only source type, so "knowledge sources" describes where this is heading more than where it is today.

In other words, one is a retrieval primitive and the other is most of a RAG pipeline collapsed into a single SQL call. The tell is the return value. vector_search() gives you rows to do something with. ai_search() returns a VARIANT holding the retrieved documents and, alongside them, an answer field, which is populated unless you set generate_answer to false.

ai_search() needs Databricks Runtime 18.2 or above, and on serverless compute the environment version must be 3 or above, because it depends on VARIANT. It runs from notebooks, the SQL editor, jobs, workflows, and Spark Declarative Pipelines.

The scaling answer arrived separately

Databricks announced High QPS for AI Search as generally available in a blog post on 28 July 2026, with the documentation release note dated 15 July. By default a standard endpoint supports 20 to 200 queries per second depending on index size, while real-time applications such as search bars and recommendation systems often want 100 to 1000 or more. You now set a target_qps on the endpoint and Databricks provisions infrastructure to match, instead of you provisioning replicas, sizing nodes and putting a load balancer in front of the index. Endpoint throughput, latency and health are visible per endpoint in the UI.

Two qualifications the announcement wording glides over, both stated plainly in the docs. Scaling is best-effort and not guaranteed. And setting a target QPS provisions additional capacity that you are charged for regardless of actual query traffic, so this converts an infrastructure problem into a standing bill rather than making it disappear. That is still usually the right trade at production scale, but it is a budgeting decision, not a checkbox.

What to do with all this

1. Re-run your searches, not just your bookmarks. The canonical docs now sit under the AI Search path, though the old Vector Search URL still resolves, so nothing is broken. The issue is third-party material: anything written before June cannot tell you about full-text indexes, ai_search(), or High QPS, however correct it was at the time.
2. Re-open the hybrid question. If your corpus has identifiers in it and you built pure similarity retrieval, you are leaving exact-match relevance on the table.
3. Decide which function you are on deliberately. Picking ai_search() because it is newer means adopting its retrieval and synthesis opinions. That is a good trade for batch enrichment and a questionable one when you already have a tuned pipeline.
4. Check the preview gates before you design around anything. Full-text search, dedicated full-text indexes, and ai_search() are all Beta at the time of writing; vector_search() is Public Preview. None of them carry GA guarantees yet.

The rename looks like marketing noise and mostly is not. It marks the point where this stopped being an embeddings index with a query API and started being a search product, one that happens to use vectors when vectors are the right tool.

Facts here were checked against the Databricks documentation and release notes on 2 September 2026. Preview and Beta states move quickly, so verify the gating before you build on it. brickster.ai is an independent community project and is not affiliated with Databricks.