Michael JohnsonTeams that store content in Cloudflare D1 can now send selected records to AI Search without a separate intermediate export. On November 12, 2026, Cloudflare added D1 as a data source in the service’s beta: developers provide a read-only query, and AI Search turns each returned row into a document and updates the index on a schedule.
What changed
Previously, AI Search offered other source categories, such as R2 objects or web content. Now D1 can send data from tables directly to the index—for example, published articles, a product catalog, or knowledge-base records. Cloudflare described the change in its November 12 changelog entry; you can create an instance with a D1 source through the dashboard, REST API, or Workers binding.
Database owners use an SQL query to determine which records are indexed and which fields become the document title, content, and metadata. For an article database, for example, a query could select only published content and assign the columns the roles id, title, content, and meta_category. This builds the search representation from a selection defined by the developer.
How the integration works
When you configure a D1 source, AI Search runs the specified query, indexes rows individually, and syncs the index on a schedule. The REST API and Workers binding require a D1 database ID in the same Cloudflare account, a service token ID, and a query that returns an id column. In the dashboard, you can select a database, write a query, and preview its result for one row before creating an instance; these steps are covered in the D1 source documentation.
Column names determine their purpose: title becomes the document title, content the main text, and columns prefixed with meta_ are stored as metadata. Other columns may appear as labeled fields, depending on the document template. This lets you select the categories and fields needed for search in SQL.
Which queries the service accepts
The query must be a single read operation beginning with SELECT or WITH. It must return a nonempty result with unique, nonempty id values; the maximum is 100,000 rows, and the query can be up to 10,000 characters long. The documentation also prohibits bind parameters, comments, and several SQL constructs, including write operations and administrative commands. You cannot use ORDER BY or LIMIT: AI Search reads the result in pages, sorting by id.
If a row’s id changes, AI Search deletes the old document and creates a new one. So it’s best to choose a stable identifier for synchronization. Each result column must also have a unique name; if needed, you can assign one with AS. Because synchronization reads the query’s full result, it counts toward D1 reads, and WHERE conditions can help limit the indexed selection.
Who can benefit
The new integration is suited to teams that already store structured content in D1. They can use a database query to select records for the search corpus, then sync the index when rows are added, changed, or deleted. For example, a catalog can include only items available for sale, while a help center can include only published articles and their categories. Each row becomes a separate document.
The integration is still in beta. Before launch, check that id values are unique and stable, select only the columns you need, and assess how the result size and sync schedule will affect D1 usage. Index updates occur at the selected interval, and reading the full result on each sync consumes D1 reads.
The key change is that D1 can now serve as an AI Search source, with an SQL query determining which database rows become searchable documents. For teams with content in D1, this provides a direct way to connect their data to an index; when planning, account for the row limit and database reads during synchronization.
