Databricks adds direct AI Search indexing for streaming data, views and Iceberg tables
The support covers Streaming Tables, Materialized Views and managed Iceberg v3+ tables. Existing indexing workflows remain, but source configuration requirements still apply.
Databricks’ October 26, 2026 change lets AI Search build and keep indexes synchronized directly from Streaming Tables, Materialized Views, and managed Iceberg v3+ tables, without a customer-maintained intermediate Delta table and sync pipeline. The search index and existing Delta Sync workflow remain, and deployment still depends on Unity Catalog, serverless compute, and source-specific prerequisites. This reduces integration and maintenance work for live or cross-engine data, but teams using self-managed embeddings cannot switch an existing index to Databricks-managed embeddings; they must create a new index and recompute them.
01
Workspaces need Unity Catalog and serverless compute, and index creation requires CREATE TABLE privileges on the destination catalog schema.
02
Materialized Views require external metadata, or Smart Clone, enabled on the view or its defining pipeline.
03
Standard endpoints require change data feed on source tables; tables with row tracking enabled use that feed automatically.
Databricks is removing a data-preparation step between more company data and AI search applications. On October 26, 2026, it announced direct AI Search support for Streaming Tables, Materialized Views and managed Iceberg v3+ tables. The company says customers no longer need an intermediate Delta table and custom synchronization pipeline for those sources.
One less data layer to maintain
AI Search retrieves information for applications such as AI assistants and recommendation systems. It can find content through embeddings: numerical representations that allow a query to match similar meaning, rather than only identical words. Developers create a searchable index from a source table, then query it to retrieve matching documents and their associated information.
Delta tables were already supported. Previously, customers using the three newly supported sources had to create a separate Delta representation and keep it synchronized with the original. Databricks says that required another data layer, custom update logic and ongoing maintenance. Native connections remove that intermediate layer; they do not remove the search index itself.
Different sources, different search context
Streaming Tables address continuously arriving records, such as new listings, inventory changes, availability and user activity. Databricks describes an append-only table feeding new records into AI Search as they arrive. Its examples include helping people find newly available restaurants and generating recommendations from recent trends. Here, the source supplies a continuing stream of events rather than a fixed collection.
Materialized Views provide a different input: a maintained result that can aggregate events, filter records and join multiple sources. As the underlying data changes, the view is updated incrementally and AI Search passes those changes to its index. Databricks positions this route for personalization, including recommendations based on a current session or a user's recent activity and changing interests.
Managed Iceberg support targets data used across different engines. These tables can feed AI Search without conversion or migration to another table format. Databricks gives examples including searches across product catalogs managed by different systems and combined business or customer data. The supported scope is managed tables using Iceberg version 3 or later—not an unrestricted promise covering every Iceberg table.
The workflow stays; setup requirements remain
Customers use the existing interface or API workflow: create a Delta Sync index and point it at the source. Despite that name, the workflow now accepts the additional source types. Databricks' documentation also spells out prerequisites that remain relevant even when customers no longer have to build the extra synchronization pipeline themselves.
The workspace must have Unity Catalog and serverless compute enabled. Creating an index also requires CREATE TABLE privileges on the destination catalog schema.
Materialized Views require external metadata, also called Smart Clone, enabled on the view or the pipeline that defines it.
For standard endpoints, source tables must use a change data feed. Tables with row tracking enabled use that feed automatically.
Teams also retain a choice about who produces the embeddings. They can supply text and have Databricks compute them using a specified model, or provide embeddings they have calculated themselves. Both Delta Sync options support the expanded source list and keep the index synchronized as the source changes.
That choice has a migration consequence. An index using self-managed embeddings cannot be converted into one with Databricks-managed embeddings. A team that later wants Databricks to handle that work must create a new index and recompute the embeddings, according to the documentation.
Reader comments
Newest comments first. Replies stay oldest first.