Microsoft recently announced updates and fixes for SSMS 22.3. While the release included many quality-of-life fixes, it also introduced a deceptively powerful addition called Database Instructions. This feature stood out to me as it can fundamentally changes how GitHub Copilot understands your database, not just its schema, but its meaning.

Instead of repeatedly explaining business rules, naming conventions, or legacy quirks to Copilot, you can now store that context directly in the database itself and have Copilot automatically apply it during query generation and analysis. Essentially creating living documentation that travels with the database and improves Copilot’s accuracy over time.

We’ll walk through a step‑by‑step demo using AdventureWorks2025 and the Sales.SalesOrderHeader, Sales.SalesOrderDetail and Production.Product tables for this demonstration on how to incorporate Database Instructions into your data environment. Learn how to setup a SQL Server 2025 Practice Environment.

What Are Database Instructions?

Database Instructions provide database‑specific context to GitHub Copilot by storing guidance as extended properties inside the database. Copilot automatically discovers and applies these instructions at runtime, ensuring that generated queries reflect business definitions, canonical tables, and domain rules rather than relying only on schema names or assumptions.

Key characteristics:

• Instructions live with the database
• They persist across sessions
• They apply to all Copilot users accessing that database
• They act as living documentation, not comments or external wiki pages

Prerequisites

According to Microsoft Learn, Database Instructions require the following:

• SSMS 22.3 or later
• AI Assistance workload installed
• Signed in with a GitHub account that has Copilot access
• A database where you can add extended properties

How Database Instructions Work

Database Instructions are extended properties stored inside the database that GitHub Copilot automatically discovers and applies at runtime. When you ask Copilot a question or request T‑SQL, Copilot incorporates these instructions as additional context, ensuring responses align with business definitions and usage patterns.

There are two instruction types:

Only one instruction of each type can exist at its respective scope, and no additional configuration is required beyond creating the extended property.

Demo Overview: AdventureWorks2025

In this demonstration we’ll show Copilot how Sales data should be interpreted in AdventureWorks2025.

Business Assumptions (Demo Scenario)

• SalesOrderHeader is the authoritative source for orders
• Revenue is based on LineTotal from SalesOrderDetail
• Products must be joined via ProductID
• Queries should avoid SELECT *
• Orders with Status = 5 represent completed sales

These rules are demo assumptions for instructional purposes. Use the following stored procedures to manage extended properties.

• Create: sp_addextendedproperty
• Update: sp_updateextendedproperty
• Remove: sp_dropextendedproperty

Step 1: Prompt Copilot (Before Instructions)

In GitHub Copilot type the following,

“Show total sales by product for last year”

Copilot may:

• Guess which tables to use
• Use SELECT *
• Misinterpret revenue logic

Step 2: Create a Database Constitution (CONSTITUTION.md)

A database constitution defines global rules that apply to all Copilot interactions for this database. Once saved, these rules are automatically applied to future Copilot queries.

Example: Constitution.md for AdventureWorks2025

EXEC sp_addextendedproperty 
@name = N'CONSTITUTION.md', 
@value = N' This database uses AdventureWorks2025 standards.    
General rules: 
- Do not use SELECT * 
- Always qualify column names with table aliases 
- Sales reporting should use Sales.SalesOrderHeader and Sales.SalesOrderDetail 
- Product details must be retrieved from Production.Product 
- Completed orders are identified by Status = 5';

Step 3: Add Object‑Level Instructions (AGENTS.md)

You can use the AGENTS.md instructions are scoped to specific objects, such as individual tables or schemas, rather than applying broadly across the entire system.

Creating the Agent.md for Sales.SalesOrderHeader

EXEC sp_addextendedproperty 
@name = N'AGENTS.md', 
@value = N'SalesOrderHeader represents customer orders.  
- Use OrderDate for time-based filtering  
- Status = 5 indicates completed orders  
- Join to SalesOrderDetail on SalesOrderID',  
@level0type = N'SCHEMA',  
@level0name = N'Sales',  
@level1type = N'TABLE',  
@level1name = N'SalesOrderHeader';

Agent.md Example for Sales.SalesOrderDetail

EXEC sp_addextendedproperty 
@name = N'AGENTS.md', 
@value = N'SalesOrderDetail stores line-level sales data. 
Revenue calculations should use LineTotal 
- Join to Production.Product using ProductID', 
@level0type = N'SCHEMA', 
@level0name = N'Sales', 
@level1type = N'TABLE', 
@level1name = N'SalesOrderDetail';

Example Table 3: Production.Product

EXEC sp_addextendedproperty 
@name = N'AGENTS.md', 
@value = N'Production.Product contains product metadata. 
- ProductID is the primary key 
- Use Name for reporting-friendly output', 
@level0type = N'SCHEMA', 
@level0name = N'Production', 
@level1type = N'TABLE', 
@level1name = N'Product';

Step 4: Prompt Copilot (After Instructions)

In GitHub Copilot type the following, “Show total sales by product for completed orders last year”

Copilot now:

• Uses Status = 5
• Joins SalesOrderHeader, SalesOrderDetail, and Production.Product
• Avoids SELECT *
• Uses LineTotal for revenue

Viewing Existing Instructions

You can ask Copilot directly:

• “Show me the database instructions for this database”
• “Does this database have a constitution set?”

Copilot will summarize the stored guidance rather than querying system tables directly.

Why This Matters

Database Instructions are especially valuable for:

• Shared environments
• Training databases
• Large or legacy schemas
• Reducing tribal knowledge

This means:

• Less time explaining schema quirks
• More consistent Copilot output
• Faster onboarding for new people

Final Thoughts

Database Instructions turn GitHub Copilot into a domain‑aware SQL assistant instead of a generic code generator. By embedding guidance directly in the database, teams can align Copilot with real business rules once, and benefit from it everywhere. If you’re using SSMS 22.3 or later, this feature is absolutely worth adding to your toolkit.