Microsoft Foundry has started letting Azure SQL Database feed AI systems directly. Azure SQL is now a first class knowledge source in Azure AI Search, available in public preview. In plain terms, teams building Copilot, RAG, and agentic experiences can point their retrieval layer at relational tables without first copying everything into a separate vector store.
Why this matters for grounded AI
Most enterprise data does not live in documents. It lives in databases, in tables with relationships, constraints, and access controls that have been maintained for years. RAG setups have historically been awkward around that reality. You scramble to extract the interesting bits, chunk them, embed them, and load the result into a search index, then pray the export stays in sync with the source of truth.
Treating Azure SQL as a knowledge source changes that flow. When a table is exposed as a knowledge source, Azure AI Search can pull from it as part of its indexing pipeline, and the structured data becomes something your LLM can be grounded against. Instead of a stale snapshot, the retrieved context comes from authoritative, relational data.
How it slots into the pipeline
The knowledge source concept sits inside the broader Azure AI Search indexing story. You define what data the search service should ingest, and the service feeds that into an index built for fast retrieval. For RAG, that index then supplies grounding content to the model when a user asks a question. The model does not train on your data; it just gets the right slice of it at query time.
Adding SQL as a source type means the ingestion layer can now reach into databases natively, rather than requiring you to pre-transform relational data into flat documents. For developers, that removes a step that was both tedious and error prone. The table you query in your app and the data your agent reasons over are now the same thing.
What this means for agent deployments
This fits a broader trend in the platform: moving from retrieval that requires heavy preparation toward retrieval that reads from systems of record. Agents are only as good as what they can see, and giving them live access to the relational backbone of a business is a real step up from a document export.
There is a practical payoff too. When your grounding data is relational, queries can respect the structure of the data. Lookups that depend on joins, filters, and relationships behave the way they do in the application, because the source is still a database. That is hard to replicate once everything has been flattened into vectors and chunks.
What to watch for
Public preview means the feature is a moving target, so scope it as an experiment before betting anything critical on it. The main things to check early are how freshness works, how access is governed, and how the retrieval responds to structured queries. Databases change frequently, so the sync behavior between the table and the index matters more than the initial load.
Security deserves the same attention it always gets with grounding data. If an agent can reason over database content, the boundaries of what it is allowed to see need to be explicit. Preview is the right time to test how row and column level security plus your existing identity model carry through to retrieval.
How this compares to the alternative
The conventional approach before this feature was a custom ingestion pipeline. You wrote code to query the database, chunk the rows, generate embeddings, and push results into a search index, then scheduled it to rerun on some cadence. It worked, but it came with maintenance costs and a built in clock skew. Between runs, the index drifted from the database, and grounding quality drifted with it.
A native knowledge source does not eliminate that problem entirely, because search indexes are still separate from the source data. But it moves the synchronization work into the platform instead of leaving it in your code. That is the meaningful difference. You stop owning the export logic and start owning the question of which tables are safe to expose.
For teams considering this, the honest framing is about trust boundaries. Documents are relatively easy to restrict by folder or identity. Databases carry an implicit promise that whoever queries them sees only what they are allowed to see. Carrying that promise through to an index that then feeds an LLM is the part worth thinking about before you wire ten production tables into an agent.
Practical next steps
For a team already on Azure AI Search, the fastest path is to enable Azure SQL as a knowledge source in a dev index and point a sample Copilot at it, then see whether the answers reflect the actual table contents. That test will surface the integration rough edges faster than any planning document.
The bigger architectural question is where this moves the needle. If you have been maintaining parallel pipelines that export database content into vector stores, a native SQL knowledge source is a candidate to collapse that duplication. Treat it as a chance to simplify, not to rip out a working system overnight.