Forum Discussion
How does GitHub Copilot in SSMS 22 handle database context collection before generating a response?
Hello,
I am trying to better understand the internal workflow of GitHub Copilot in SSMS 22, especially for database-specific questions.
From the product descriptions, it seems that Copilot can use the context of the currently connected database, such as schema, tables, columns, and possibly other metadata, when answering questions or generating T-SQL.
However, I could not find clear official documentation about the actual sequence of operations.
My main questions are:
- Before generating a response, does Copilot first collect database context/metadata from the active connection and then send that context to the LLM as grounding information?
- Or does it first use the LLM to interpret the user’s request, decide what information is needed, and then retrieve database metadata before generating the final answer?
- In some explanations, I have seen the phrase "Core SQL Copilot Infrastructure", but I cannot find any official documentation for that term.
- Is this an official component name?
- If so, what does it specifically refer to in the SSMS Copilot architecture?
- When Copilot answers schema-related or data-related questions, what information is retrieved automatically from the connected database, and is any SQL executed as part of that process?
- Is there any official architectural documentation that explains:
- context collection,
- prompt grounding,
- LLM invocation order,
- and whether query execution can occur before the final response is generated?
I am asking because I want to understand the feature from both an architecture and data governance/security perspective.
Any clarification from the product team or documentation links would be greatly appreciated.
Thank you.
2 Replies
Hi,
Great questions. While Microsoft hasn't published a detailed step-by-step architecture of GitHub Copilot in SSMS 22, the general workflow is that Copilot uses the current database context to ground its responses when appropriate. This can include metadata such as database objects, schemas, tables, columns, and other relevant information from the active connection.
The exact internal sequence—whether the LLM first interprets the request before additional metadata is retrieved, or whether context is collected upfront—isn't publicly documented. Likewise, "Core SQL Copilot Infrastructure" isn't an official architectural term that has been documented by Microsoft.
For schema-aware features, Copilot may retrieve metadata from the connected database to provide more accurate, context-aware suggestions. Depending on the request, this can involve executing metadata queries against system catalog views, but the specific implementation details, prompt construction, grounding process, and LLM invocation order haven't been publicly disclosed.
If your focus is on architecture, governance, or security, Microsoft's official Copilot documentation is currently the best source of information, although it doesn't go into the internal orchestration details. If more detailed architectural guidance becomes available, it will likely be published in the official documentation or shared by the product team.
Hopefully this provides some clarity while we wait for more detailed documentation from Microsoft.
Documented behavior is that Copilot can use the active query editor and connected database context, including relevant metadata. Database instructions can add database-specific guidance. Microsoft does not publish a fixed internal sequence for collecting, ranking, and sending schema context, so that orchestration should not be treated as a product contract.
Context is bounded by the SSMS connection and identity. Generated actions run under the database user’s permissions; Copilot grants no additional SQL privileges. Agent mode can require approval before execution. Apply least privilege and review generated SQL, especially in production.
To validate behavior, create a low-privilege login, capture SQL Audit or Extended Events, and compare activity while changing the active database and editor contents. This shows what your build reads or executes without guessing about undisclosed internals. Distinguish metadata from data: object names and definitions may supply context, while reading rows requires permission and observable queries.
