SQL Sage vs GitHub Copilot in SSMS: an honest comparison

If you searched for an “SSMS Copilot alternative,” you probably want a straight answer, not a sales pitch. This is a comparison of two AI assistants for SQL Server Management Studio — Microsoft’s GitHub Copilot in SSMS and SQL Sage for SSMS, which I work on — written to be useful even if you pick the other one.

Disclosure: I build SQL Sage for SSMS at LumaSoft. I’ll say where GitHub Copilot is the stronger choice, because a comparison you can’t trust is worthless to you.

What exactly am I comparing — and what am I not?

A word on method first, because it governs everything below. I compare operating models, not results. I did not benchmark speed, cost-per-query, or the quality of generated SQL, so I publish no numbers for any of that — a made-up benchmark would be worse than none. What I do compare is the part you can verify from documentation: how each tool signs you in, what each vendor says leaves your machine, how each handles reads versus writes, and how each is licensed.

Everything I state about GitHub Copilot comes from Microsoft’s and GitHub’s own documentation, linked inline, so you can check it yourself. Everything I state about SQL Sage comes from our own product facts. If I couldn’t confirm a claim about Copilot at the source, it isn’t in this article.

One clarification, because the name is overloaded. There was an earlier “Copilot in SSMS” preview in SSMS 21 that connected to an Azure OpenAI resource you supplied; per Microsoft it won’t be backported and is now a feature-frozen preview. The current product — and the one this article means — is GitHub Copilot in SSMS, which requires SSMS 22 or later. SQL Sage for SSMS is an add-in for SQL Server Management Studio 22 on Windows 10/11. So both run on SSMS 22; version is not a point of difference.

How does each one sign you in?

Here’s the first place the “keyless” selling point needs honesty. Both tools avoid a raw, per-token API key for their default path — so if your mental model is “Copilot makes me manage an API key,” that’s not accurate.

GitHub Copilot in SSMS uses your GitHub account with Copilot access; you sign in with an existing GitHub account or sign up for a free Copilot plan. It runs on a GitHub Copilot subscription — free, Pro, Business, or Enterprise.

SQL Sage is also account-based, but it runs on a subscription you may already have for something else: you sign in with your own Claude (via Claude Code) or ChatGPT/Codex (via Codex CLI), and the AI runs on that. If you’d rather use a raw Anthropic key, you can — it’s an option, not a requirement.

So the real difference isn’t “key versus no key.” It’s which account carries the cost and which provider answers: a dedicated GitHub Copilot plan, or the Claude/ChatGPT subscription you might already pay for. Neither is universally better; it depends on what your team already buys. If you want the longer argument for the account-based approach, I wrote how to use AI in SSMS without an API key and the security case for keyless AI tooling.

What actually leaves your machine?

To write useful SQL, a model needs your schema — table and column names, types, relationships — and the query text. Neither tool needs your rows to draft, explain, or optimise a query. The question is what each vendor commits to in writing.

Microsoft documents that GitHub Copilot in SSMS sends your prompts to the model and may send information about your database and SQL version along with them, with schema context (tables, columns, indexes, views) by default. Microsoft also states that GitHub Copilot in SSMS doesn’t retain your prompts, responses, or metadata, and doesn’t use your data to train or retrain models — a clear, documented commitment worth crediting. In Agent mode, Copilot also executes queries and reads their results to decide its next step, so result sets enter the assistant’s loop; for the precise data-handling terms, Microsoft points to the GitHub Copilot Trust Center.

SQL Sage’s stated default is narrower in one specific way: it sends schema and SQL text only, and never your data rows unless you opt in per session. That’s the commitment we publish. I go deeper into the schema-versus-rows distinction in what leaves your machine when AI writes SQL.

The honest takeaway: both avoid shipping your rows just to draft a query, both are backed by a documented data posture, and the right move is the same either way — read each vendor’s own data terms and match them to your compliance needs before you connect anything to production.

Can either one change your database?

This is the criterion I refuse to compromise on, and it’s also where the two tools are more alike than different.

GitHub Copilot’s Agent mode is configured as READ_ONLY by default and requests your approval before running each query or command; Ask mode is read-only queries only. You can switch Agent mode to READ_WRITE in configuration, and Microsoft is explicit that the real safety boundary is SQL Server’s own permissions, not the approval prompt — Copilot executes under your login’s permissions, nothing more.

SQL Sage follows the same shape: SELECT runs immediately, while UPDATE / DELETE / INSERT and DDL wait for your explicit confirmation before anything executes.

So “read-only by default with confirmation for writes” is not a SQL Sage exclusive — it’s the responsible pattern, and Microsoft implements its own version of it. I argue for why this should be the default regardless of tool. Whichever you choose, the non-negotiable advice stands: pair the tool’s approval step with least-privilege database permissions, because a confirmation dialog is a convenience, not a security control.

Where does GitHub Copilot have the edge?

Several places, and pretending otherwise would be the kind of dishonest comparison this article exists to avoid.

It’s first-party. GitHub Copilot in SSMS is built by Microsoft and GitHub, installed through the Visual Studio Installer’s AI Assistance workload, and tied into the ecosystem: autocompletions, next-edit suggestions, an autonomous Agent mode with MCP server support, and admin controls for managing it across an organisation. If you want the SSMS-native assistant with Microsoft’s backing and an org-wide management story, that’s Copilot, and that matters for a lot of teams. There’s also a free personal Copilot plan, and a documented no-retention, no-training commitment. Those are real advantages — weigh them honestly.

How are they licensed and sold?

GitHub Copilot in SSMS needs a GitHub Copilot subscription; there’s a free personal plan, with paid Pro, Business, and Enterprise tiers through GitHub.

SQL Sage for SSMS has a 30-day trial with no card, then a free tier; paid Personal plans start at $29/year or $39 lifetime, up to Team, sold through Paddle as merchant of record. If your team lives in DBeaver instead of SSMS, there’s a sibling plugin (Windows-only). You can see both from the LumaSoft products overview.

So which should you choose?

Honestly, it depends on what you already own and who you answer to.

Choose GitHub Copilot in SSMS if you want the first-party, Microsoft-backed assistant, you value the deepest SSMS/Visual Studio integration and autonomous Agent mode, or you need organisation-wide admin controls. Choose SQL Sage if you’d rather run the assistant on a Claude or ChatGPT subscription you already pay for, you want the narrowest documented default for what leaves your machine (schema and SQL, never rows unless you opt in), and you want a flat per-seat or lifetime licence instead of another per-service subscription.

Either way, run both through the same questions — which account carries the cost, what the vendor documents leaving your machine, how writes are gated, and how it’s licensed — and pick the set of tradeoffs you can defend to whoever owns that database.

SQL Sage is made by LumaSoft (LUMA sp. z o.o.). Not affiliated with Microsoft, GitHub, Anthropic, or OpenAI; “GitHub Copilot” is their trademark, used here only to identify the product being compared.