I Put a Local 7B Model Inside SSMS 21 & 22 (No Cloud, No API Keys)

TL;DR: I built a free, open-source SSMS 21 & 22 extension that plugs a locally-hosted 7B model (served by LM Studio) straight into SQL Server Management Studio. Your schemas, your queries and your data never leave your machine — and the monthly bill is exactly $0. Repo at the end. 👇

The problem: I wanted AI in my IDE, not in someone's cloud

AI assistants for SQL are genuinely useful. They write your JOINs, they explain execution plans, they review stored procedures. But every single one of them ships your context to a remote API: your table names, your column names, sometimes data samples — all landing in somebody else's logs.

In a lot of real environments that's a hard no: regulated data, strict corporate rules, air-gapped servers. And in some parts of the world, international payments for API subscriptions are a whole separate problem of their own.

Meanwhile, a 7B model running on my own GPU is already good at T-SQL. It doesn't need Azure. It doesn't need OpenAI. It doesn't need the internet at all.

So I asked a simple question: why does my SQL assistant need the cloud in the first place?

The answer, after a few evenings of C#: it doesn't.

The stack

No cloud, no API key, no telemetry. Everything runs between SSMS, LM Studio and SQL Server on your machine.

What the extension actually does

• Chat panel inside SSMS — a proper tool window, dark theme included, with the database switcher at the top
• Full schema awareness — the extension reads your real schema through SMO: tables, columns, PKs/FKs, indexes, views, stored procedures (with parameters), functions, triggers, even row counts — and injects it into every prompt, cached on disk
• Analyze Database — one click, and the model reports facts from your database (real tables, real row counts), not generic advice:

• Execute button under every SQL block — with a safety net: every script is first syntax-checked with SET PARSEONLY (nothing executes on a syntax error), and runtime failures are sent back to the model for an automatic fix before you even see them
• New Query button — pushes the generated SQL into a real SSMS query window on SSMS' own connection, F5 to run
• Explain Plan / Open Plan — extracts the estimated plan (SET SHOWPLAN_ALL, the query is never executed), and can even open the XML plan in SSMS' own graphical plan viewer
• Tune Query — collects real evidence from the server: the XML plan, sys.dm_db_missing_index_* suggestions, and sys.dm_db_index_usage_stats for dead-index detection, then turns it into idempotent CREATE INDEX scripts and safe drop candidates

And because small local models hallucinate confidently, the extension has explicit guardrails: the system prompt forbids invented benchmarks and fake "tested" claims, every column the model mentions must appear verbatim in the schema section, indexes may only be proposed after checking the existing ones, and all DDL must be idempotent (IF NOT EXISTS guards) so re-running a script is safe.

The trickiest part: making a 7B model behave

Two things I learned the hard way:

1. LM Studio silently truncates long prompts from the FRONT. The extension builds one prompt per question: system instructions + full schema text + rolling history + your question. If that prompt exceeds the model's context window, LM Studio doesn't error — it quietly drops the beginning, which means the system message and the entire schema disappear, and the model starts answering with generic advice that ignores your actual database. The extension keeps the whole prompt under a character budget (dropping oldest history first, then shortening the schema), and auto-detects the real context window on overflow to retry.

2. Thinking models can burn the whole budget on reasoning and return an empty answer. The extension strips inline <think> blocks, flags truncated answers, and — worst case — recovers the last complete SQL block from the model's reasoning_content instead of just showing you nothing.

That's the part nobody tells you about local LLMs: the model is the easy bit. Keeping its context intact is the engineering.

Setup: 10 minutes, no credit card

1. Install LM Studio, download a 7B model (I like Qwen2.5-Coder-7B-Instruct for T-SQL), and start the local server.
2. Download SsmsAiAssistant.vsix from the repo's Releases page (CI builds it automatically) and double-click to install — per-user, no admin rights.
3. Start SSMS 21 & 22 → you'll see the Arman AI Assistant menu next to Tools.
4. Open the chat, then Tools → Options → Arman AI Assistant:

1. AI Backend
   Base URL:  http://localhost:1234/v1     ← LM Studio
   API key:   lm-studio                    ← any non-empty string
   Model:     qwen2.5-coder-7b-instruct
2. Database Connection
   Active SSMS connection (or a custom connection string)

Because the backend is plain OpenAI-compatible, the same extension also works with Ollama, vLLM, DeepSeek, Azure OpenAI or OpenAI itself — switchable in Options. Local is just the mode where nobody sees your data and nobody bills you.

Bonus: the same database, via MCP

The repo also ships a small .NET 8 MCP server (stdio, official SDK) exposing 14 SQL tools — list_tables, describe_table, sample_data, execute_sql, ... — so Claude Desktop, Cursor or Claude Code can work against the same SQL Server with the same guardrails. Two components, one solution.

Where to get it

The whole thing is MIT-licensed and open source:

👉 github.com/Fargo4u/ssms-ai-assistant

Grab the ready-made VSIX from Releases, or build it yourself with Visual Studio 2022. If it saves you a few SELECT round-trips or finds you a missing index, a ⭐ on the repo genuinely helps other SQL people find it — and issues/PRs are very welcome.

What would you want an AI assistant to do inside SSMS? Tell me in the comments — feature requests are the fuel here. 🚀