The moment that started it
A colleague of mine was cleaning up some old records in a staging environment. Same query he'd run a dozen times before, except this time he was connected to production. He hit F5. No WHERE clause.
47,000 rows gone in milliseconds.
We recovered from a backup, lost about two hours, and nobody got fired. But it stuck with me:** SSMS will let you delete an entire production table with the same amount of friction as running a SELECT 1**. No pause, no confirmation, nothing. The tool that DBAs and backend developers spend all day in has zero built-in protection against the single most common way people destroy data.
So I built one.
What SQL Guard does
SQL Guard is a free SSMS extension (18 through 22) that inspects your query the moment you press F5, and pauses execution if it matches a known destructive pattern:
- DELETE without WHERE
- UPDATE without WHERE
- TRUNCATE TABLE
- DROP TABLE / DROP DATABASE / DROP PROCEDURE
- ALTER DATABASE
- Dangerous EXEC calls
- MERGE without a filter
When one of these fires, you get a dialog showing exactly what object would be affected, with three options: cancel, run anyway, or run and ignore for the rest of the session. The point isn't to block you — it's to make the action conscious. Most accidental damage happens because muscle memory took over, not because someone genuinely meant to wipe a table.
How the detection works
Nothing exotic here, and honestly that's by design. SQL Guard runs a lightweight pattern-matching pass over the query text before it hits the connection. No parsing tree, no round-trip to the server, no measurable latency — it runs in under a millisecond, so you never notice it on normal queries.
The core idea is simple: certain statements are only safe when scoped by a WHERE clause, and the extension checks for that clause's absence rather than trying to understand the full semantics of the query. That keeps false positives low and means it works the same way whether you're on SQL Server 2016 or the latest version.
A conscious design choice: whitelisting is per-table, per-rule — never a blanket bypass. If you have a staging table that legitimately gets truncated on every import, you whitelist that specific table for that specific rule. You don't get an "ignore everything" switch, because that switch is exactly what erases the safety net the first time you forget you flipped it.
Why it stays local
SQL Guard never sends your query text, connection strings, or database names anywhere. Everything happens inside the SSMS process. The only optional telemetry is anonymous crash reporting (via Sentry) for stack traces — never query content. For anyone working with production data, that's not a nice-to-have, it's the only acceptable design.
Installing it
Windows, SSMS 18–22
Zero configuration — the installer registers with every SSMS version it finds
Free, no license key, no trial period
If you want to try it: https://sqlguard.app/
What I'd love feedback on
The rule set covers the "classics" — the patterns that show up over and over in production-incident postmortems. If you've got a destructive pattern that's bitten you and isn't in that list, I want to hear about it. I read every piece of feedback myself.
Backups and a recovery plan are still non-negotiable — SQL Guard reduces the chance of a destructive query, it doesn't replace either. But reducing the chance is worth a lot when the alternative is a Saturday spent restoring from a transaction log.
SOCIAL SHARE CARD GENERATOR