AI for SSMS, compared — SQL Sage vs GitHub Copilot vs SsmsAgentic

01The choice today

If you work in SQL Server Management Studio 22 and want an AI assistant next to your query editor, there are three distinct options as of August 2026:

• GitHub Copilot in SSMS — Microsoft's first-party assistant, installed via the Visual Studio Installer (the “AI Assistance” workload). You sign in with a GitHub account that has a Copilot subscription; the model is provided by GitHub Copilot.
• SsmsAgentic — an independent AI pair-DBA panel that brings Claude into SSMS 22. Per its README it launches the Claude Code CLI as a child process, uses that CLI's Claude sign-in, shows an Allow/Deny banner per statement, writes a full audit log to disk, and offers a 15-day trial.
• SQL Sage — an independent AI pair-DBA that runs on the Claude or ChatGPT/Codex account you already have (through Claude Code or the Codex CLI) or your own Anthropic API key (BYOK, no CLI). AI usage is not included. It adds a Proven & Accountable layer the other two do not document: deterministic blast-radius before ALTER/DROP, a proof that an AI rewrite returns the same rows, one-click incident triage from live DMVs, and a tamper-evident audit log you can export as evidence.

SQL Sage and SsmsAgentic are genuinely close on the fundamentals — both independent, both run through the Claude Code CLI, both classify statements and confirm writes, both keep an audit log. So the honest question isn't “who has a CLI” — it's which model do you want to run, and do you need the changes proven and logged as evidence. The table below sticks to what each vendor documents publicly.

02What SQL Sage is — and isn't

We'd rather tell you where it doesn't fit than oversell it. If the proof-and-audit layer below doesn't matter to your work, one of the other two may serve you just as well — and the table says where they win.

03The difference: proof & accountability

Everything above the line — chat, T-SQL help, DBA tools — SQL Sage and SsmsAgentic both do, and Copilot does the general-purpose version. The reason to reach for SQL Sage is what it does below the line. Its own tagline: Copilot guesses; SQL Sage proves it — and logs it.

• Change-Impact — prove the blast radius before you ALTER or DROP. It reads the system catalogs and reports the dependent views, procedures, functions, triggers and constraints, the inbound foreign keys, the rows at risk and the object's indexes — deterministically, not guessed. Honest limit: static analysis cannot see dynamic (EXEC / sp_executesql) or cross-database SQL, and it says so.
• Prove-It — proof that an AI rewrite returns the same rows. A deterministic, server-side multiset fingerprint (order-independent and duplicate-aware) plus the logical-reads delta, with a clear EQUIVALENT / DIFFERENT / UNDECIDABLE verdict. It runs read-only in a rolled-back transaction, costs zero AI tokens, and is honest when a query genuinely can't be proven (a nondeterministic function, or TOP without ORDER BY).
• Incident Mode — on-call triage that cites the proof. One click runs a deterministic, read-only snapshot of what the server is doing right now — the blocking chain, top waits with each one's % share, and the most expensive in-flight queries — every number cited from a live DMV, never guessed. Reads server state only, never table data.
• Tamper-evident audit log + evidence pack. The queries SQL Sage runs or blocks are recorded to a local, hash-chained audit log — on by default, switched off with Audit SQL — so an edit, deletion or reorder of any entry still in the file is detectable (SHA-256 chain). Not logged: schema look-ups (table lists, column definitions), a few read-only diagnostics (wait stats, plan-cache top queries, active requests, deadlock history) and repository reads; the health check and Incident Mode are logged by name, without their SQL. Export an evidence pack in Markdown + JSON — what the AI did to production and who approved it — with a one-line integrity verdict. (Honest scope: a bare append-only chain can't prove the newest lines weren't dropped from the end — it's a tamper-evidence aid, not a certified immutable compliance record.)
• Evidence-first, not guess-first. The assistant grounds claims in real catalog and DMV values rather than asserting them, and states plainly when something is dynamic, cross-database or otherwise unresolved instead of glossing over it.
• Connect a repository (preview). Opt-in, per repository, on the Claude channel: the assistant reasons about your application's source code alongside the database. Native file, shell and search tools are disabled while a repo is connected — it reads the live repository only through SQL Sage's own read_repo_file / search_repo tools, confined to that folder, and nothing is copied. Secret files (.env, appsettings*.json, keys, .git/ and similar) are refused, and recognisable secret tokens in other files are redacted; a plain-text password in ordinary source code is not recognised.

Neither GitHub Copilot in SSMS nor SsmsAgentic describes an equivalent proof-and-equivalence layer in its public documentation. SsmsAgentic does keep an audit log — we don't claim otherwise — but its site does not describe it as tamper-evident or as an exportable evidence pack. Where their docs are silent, the table marks the cell “—” rather than guessing.

04Full comparison table

05Setup — CLI sign-in, BYOK, and the CLI

There's a common misconception worth clearing up: that one of these tools is “the simple one with no CLI”. In fact both SQL Sage's CLI sign-in path and SsmsAgentic use the Claude Code CLI. The real setup difference is that SQL Sage gives you a second path that needs no CLI at all, plus a second provider.

• SQL Sage — CLI sign-in. You sign in inside Claude Code or the Codex CLI with your own Claude or ChatGPT account. On this path SQL Sage never sees, stores, or transmits your credentials; it only asks the CLI whether you're signed in. No separate key, no GitHub account, no Copilot licence — but AI usage is not included: Claude Code needs a Claude plan that includes it or an Anthropic Console account, and Codex a ChatGPT account.
• SQL Sage — BYOK (no CLI). Prefer not to run a CLI? Paste your own Anthropic API key and SQL Sage talks to the API directly — no Claude Code, no background process. The key is the one secret it keeps, stored on your machine encrypted with Windows DPAPI.
• GitHub Copilot in SSMS. Installed through the Visual Studio Installer's “AI Assistance” workload; you sign in with a GitHub account that has a Copilot subscription. The model comes from GitHub Copilot rather than a Claude/ChatGPT account you connect. (For context, the earlier “Copilot in SSMS 21” used your own Azure OpenAI endpoint, deployment and API key; that was replaced by GitHub Copilot in SSMS 22.)
• SsmsAgentic. Per its README, it launches the Claude Code CLI as a child process and uses that CLI's own sign-in, reusing your live SSMS connection. It is Claude-only.

06Providers & choice

If it matters which model answers, the options differ:

• SQL Sage supports both Claude (via Claude Code) and ChatGPT / Codex (via the Codex CLI), and you pick a model from a dropdown; new Claude and ChatGPT/Codex models appear in the picker without a plugin release.
• GitHub Copilot in SSMS provides the model through GitHub Copilot — you sign in with GitHub rather than connecting your own Claude or ChatGPT account.
• SsmsAgentic brings Claude to SSMS; support for other providers is not stated on its site.

07Safety, privacy & telemetry

Here we speak in detail about SQL Sage, because that's the product whose internals we can state as fact. For the others, where their public documentation doesn't spell out the equivalent behaviour, the cells above are marked “—” rather than guessed at. Where SsmsAgentic's README does state a behaviour (per-statement Allow/Deny, an audit log to disk), we credit it as fact.

In SQL Sage:

• Read-only by default. Statements are classified by the same parser SSMS uses (ScriptDom). SELECT runs read-only; DML and DDL require a confirmation dialog showing the exact SQL before anything executes — every time. Safety is a feature here, not friction: only destructive operations stop for you.
• Your data stays yours. Schema metadata and your query text go to the model; query result rows never do, unless you opt in per session. Server and database names can be masked. An egress panel shows the exact payload before it is sent.
• Local, tamper-evident audit. The queries SQL Sage runs or blocks are appended to a local, hash-chained JSONL log under %LOCALAPPDATA%\SqlSage\audit\ — local-only, no network egress, on by default and switched off with Audit SQL — exportable as an evidence pack. Not logged: schema look-ups (table lists, column definitions), a few read-only diagnostics (wait stats, plan-cache top queries, active requests, deadlock history) and repository reads; the health check and Incident Mode are logged by name, without their SQL.
• No token custody. On the CLI sign-in path, sign-in lives in Claude Code / Codex; SQL Sage never holds your account credentials. With BYOK, the one secret is your key, encrypted with DPAPI. Secrets are never in plaintext, the registry, or version control.
• No analytics or tracking code — and every request to us, listed. The extension talks to our servers only for: the update check when the panel starts (version.json; switch it off with Check for updates); the signed model list; for a paid licence, licence validation that sends only the licence identifier — our server records the date of the last validation, kept for 35 days, to count active installations; and one anonymous count when you click Download in the update banner. None of these carries your name, email, a device or installation identifier, or anything from your database. Details: Privacy Policy, section 6.

If any of the other tools document the same guarantees, treat their own docs as the source of truth — we don't claim what we can't verify, and we don't claim they lack what they simply don't mention.

08Updates & releases

SQL Sage ships frequently. The panel checks for new versions and shows a banner when one is out; you download and run the signed installer (close SSMS first) — nothing is installed silently, and you can switch the check off with Check for updates. The model list updates independently too: new Claude and ChatGPT/Codex models show up in the picker without waiting for a plugin release, because the list is fetched from a hosted manifest.

09FAQ

10Which should you pick?

All three run in SSMS 22, so it comes down to fit:

• Pick SQL Sage if you touch production and want changes proven and logged as evidence — deterministic blast-radius, prove-equivalence, incident triage, a tamper-evident audit log — on the Claude or ChatGPT/Codex account you already have, through its CLI or with a CLI-free key (AI usage not included).
• Pick GitHub Copilot in SSMS if you already have a GitHub Copilot subscription and want Microsoft's first-party assistant installed through the Visual Studio Installer, and general-purpose ghost-text completions matter most.
• Pick SsmsAgentic if you specifically want a Claude pair-DBA in SSMS with per-statement approval and are happy with Claude only.

Want the SQL Sage detail on CLI sign-in and what each provider gives you? See your own AI account in SSMS — Claude or ChatGPT/Codex, or the full documentation. Every install starts a 30-day free trial with all features, no credit card.

AI usage not included: SQL Sage needs your own AI access (Claude Code on a paid Claude plan, the Codex CLI with a ChatGPT account, or your own Anthropic API key). See pricing

Start the 30-day free trial

11Sources & disclaimer

• GitHub Copilot in SSMS — Microsoft Learn, “Install GitHub Copilot in SSMS”: learn.microsoft.com/en-us/ssms/copilot/copilot-in-ssms-install
• SsmsAgentic — vendor site: ssmsagentic.io and its public README: github.com/ado-webco/ssms-agentic

SQL Sage facts on this page reflect the current product; see the documentation and home page for the authoritative description.