GitHub Copilot in SSMS 22 vs. a Local 7B Model Extension: An Honest Comparison

TL;DR Copilot in SSMS 22 now has a "bring your own model" option — but the provider list is locked (OpenAI, Anthropic, Google, xAI, Azure, Foundry Local), it still needs a GitHub account, and background services keep calling the Copilot API. A local extension connects to any OpenAI-compatible server (LM Studio, Ollama, vLLM), needs zero accounts, and works on SSMS 21 and 22. Here's an honest side-by-side — including the things Copilot does better.

Full disclosure up front: I built the local extension (Arman AI Assistant), so weigh my judgment accordingly. The Copilot facts below come from Microsoft's own documentation — if anything here is out of date, tell me in the comments and I'll correct it with credit.

What Copilot in SSMS 22 actually offers

Credit where it's due: this is no longer a toy. Copilot in SSMS ships as the AI Assistance workload in the Visual Studio Installer, and per Microsoft's docs you now get:

• Chat (and inline chat) grounded on your database connection
• Slash commands like /doc to document, explain, fix, or optimize T-SQL
• Editor autocompletions since SSMS 22.2
• Agent mode since SSMS 22.7 — give it a high-level goal and it works autonomously: executes queries, reads execution plans, modifies schema (with your approval), and can be extended with agent skills and MCP servers

It's a serious product. There's also BYOM — "bring your own model": in the chat's model picker, choose Manage Models and add a model with your own API key from OpenAI, Anthropic, Google, xAI, or Azure — plus Foundry Local, Microsoft's local runtime and the one genuinely offline route.

That's real progress. Foundry Local deserves a proper mention: it runs ONNX models on your own hardware through Microsoft's runtime, so "local" is genuinely achievable — it just means picking from Microsoft's catalog rather than your own download folder. Now the fine print — because there's a gap between "bring your own model" and "bring your own server."

The fine print

1. The provider list is fixed. There's no generic OpenAI-compatible endpoint field. You can't point Copilot in SSMS at http://localhost:1234/v1, so LM Studio, Ollama, vLLM and llama.cpp don't connect directly. Whatever coder model you already have downloaded is out of reach unless Foundry Local happens to ship it. That distinction sounds cosmetic until you actually run it: the whole point of LM Studio and Ollama is that the model, the weights and the traffic belong to nobody but you.
2. A GitHub account is still required. Even with your own API key, the experience stays anchored to Copilot sign-in. And BYOM is not available on Copilot Business/Enterprise plans — corporate users are pinned to the default cloud models.
3. Background services still phone home. The docs say it directly: "Services like embeddings, intent detection, and repository indexing might continue to use the Copilot API" — even when you use a custom model. If your threat model is "no schema fragments leave this machine," that sentence deserves attention.
4. It's SSMS 22 only. The earlier SSMS 21 preview used a different, Azure OpenAI-based experience that required provisioning an Azure OpenAI resource in the portal. If your shop is still on 21, none of this is waiting for you there.
5. Availability. GitHub Copilot isn't offered in sanctioned regions at all, and plenty of teams sit behind corporate blocks. Even the free tier starts with a GitHub account that can reach the service.

What the local route does differently

Arman AI Assistant is an open-source (MIT, no telemetry) VSIX that turns SSMS into a plain client for any OpenAI-compatible server. It doesn't try to be Copilot — it's a schema-aware chat panel plus a set of database workflows. It also deliberately skips things: no ghost-text autocompletions, no autonomous agent mode. A scoped toolset keeps even a small 7B model useful instead of ambitious. Where it differs:

• Any endpoint, any model. Point it at LM Studio (http://localhost:1234/v1), Ollama, vLLM, llama.cpp — or at OpenAI itself if you ever want to. Switchable in Options.
• Explicit schema injection. Tables, columns, PK/FKs, indexes, views, procs, functions, triggers and row counts are injected into every prompt and cached — so even a small 7B model answers with your real object names instead of hallucinated ones.
• Structural guardrails. Generated T-SQL passes a PARSEONLY pre-check before execution, runtime errors trigger an auto-fix loop, and DDL is idempotent-only. The model can propose; it can't casually wreck your schema.
• Performance workflow. Explain Plan opens a graphical .sqlplan viewer; Tune Query pulls real DMV evidence — missing indexes, dead indexes, usage stats — instead of generic advice.
• Analyze Database. A one-click report generated from your actual schema, not a template.
• Zero accounts, zero keys, zero billing — and it runs on SSMS 21 and 22.

Side by side

	Copilot in SSMS 22	Local extension (Arman)
Install	VS Installer workload	VSIX from Releases
Account	GitHub + Copilot access	None
Model freedom	Fixed list + Foundry Local	Any OpenAI-compatible server
LM Studio / Ollama / vLLM	✗	✓
Fully offline	Only via Foundry Local	Always
Agent mode (autonomous, MCP)	✓ — 22.7+	✗ — focused toolset
Inline autocompletions	✓ — 22.2+	✗ — chat + tools
Works on SSMS 21	✗	✓
Executed-SQL guardrails	Approval-based	PARSEONLY + auto-fix + idempotent DDL
DMV evidence	You can prompt for it	One-click Tune Query flow
Background API calls	Even with BYOM (per docs)	Nothing leaves the machine
Cost	Free tier (limited) / paid plans	$0, MIT

Read that table as "different priorities," not "winner." Copilot wins the top half; the local route wins the bottom half.

When Copilot in SSMS is the right choice

• You already pay for Copilot and want a vendor-supported, zero-setup experience
• You want inline autocompletions and agent mode — the local extension has neither
• Your company prefers a Microsoft-managed product with familiar billing and admin controls
• Foundry Local covers your local-model needs

If that's you, honestly — use it. It's good, and it's improving monthly.

When the local route wins

• Your data is regulated or air-gapped and the rule is nothing leaves the machine — including embeddings
• You're on SSMS 21 and not migrating this quarter
• You're in a region where Copilot simply isn't offered, or you don't want another subscription tied to a payment method you don't have
• You already run LM Studio or Ollama and want SSMS to use that model — not Microsoft's catalog
• You want structural guardrails and a DMV-based tuning workflow around the model, not just approvals

Try it in 10 minutes

1. Grab the VSIX from GitHub Releases — CI-built, works on SSMS 21 & 22
2. In LM Studio, load a model (a 7B coder is plenty) and start the server on port 1234
3. Install the VSIX, open Options, set the endpoint to http://localhost:1234/v1
4. Open the chat, ask in plain English, review the generated T-SQL, execute with guardrails

Repo: github.com/Fargo4u/ssms-ai-assistant — and if you want the backstory, including the two nastiest bugs I hit while connecting a local model to SSMS, I wrote about it in my earlier post.

If you try it and hit anything weird, open an issue — that's the fuel this project runs on. And if you disagree with this comparison, say so in the comments. I'd genuinely like to know where I'm wrong.