RowShield vs sqlcheck: script anti-patterns vs running-system checks

Head to head: sqlcheck vs RowShield

Column claims about sqlcheck are sourced below. Where the edge is theirs, the page says so — and the sections that follow explain why Supabase teams still pick RowShield.

What sqlcheck does

sqlcheck is an open-source research project that detects anti-patterns in SQL scripts. It implements a catalogue drawn from published database research and reports where scripts exhibit those patterns, with references back to the literature — which makes it genuinely educational in code review, not merely a checker.

It is free, and its grounding in published work is a real virtue: every finding is something the field has already argued about. Its frame is the script, handed to it at review time, judged against patterns rather than against a running system.

Where the scopes differ

The inputs differ first. sqlcheck examines files you give it; RowShield examines the system you run. A script can be free of every documented anti-pattern and still deploy beside a policy with an always-true predicate, a table with RLS disabled, or a bucket that quietly became public — because posture, behaviour and drift are properties of the running database, not of the text.

Mapped onto RowShield's three lenses: sqlcheck holds none of them. Its value is different — pattern literacy at review time, engine-agnostic, grounded in research. RowShield holds catalog posture on every scan, a GET-only probe as the anon caller, and snapshot diffing that classifies every change as created, resolved or regressed.

Remediation differs too: a warning points at a pattern; RowShield generates fix SQL from your actual columns, always including FORCE ROW LEVEL SECURITY where relevant. And the scope differs in kind: the literature's anti-patterns are general, while the failures that matter on Supabase — tautological policies, missing WITH CHECK, unwrapped auth.uid() calls, exposed service_role keys — are platform-specific by construction.

Why Supabase teams choose RowShield over sqlcheck

Review-time pattern literacy and operational assurance answer different questions, and only one of them is current next Tuesday. RowShield's nine shipped rules — RLS_DISABLED, RLS_TAUTOLOGY, RLS_NO_POLICIES, MISSING_WITH_CHECK, UNINDEXED_RLS_PREDICATE, RLS_UNWRAPPED_AUTH_CALL, PUBLIC_BUCKET_EXPOSURE, SERVICE_ROLE_KEY_EXPOSED, ANON_TABLE_READABLE — run on a schedule from daily to every fifteen minutes by plan, with transition alerts to Slack, Discord, email or webhooks.

Because scans diff, a regression is named as a regression — the finding a stateless script reviewer cannot produce. Remediation SQL arrives generated from your real columns, and the CLI wraps the same engine with CI-safe exit codes.

Where sqlcheck is the right choice

For teaching contexts, early-stage projects establishing SQL habits, and review workflows that benefit from findings grounded in published research, sqlcheck is a reasonable and free instrument. Its frame — scripts, patterns, review time — is honest about what it is. RowShield does not read scripts for general authoring habits; the two overlap far less than the word "linter" suggests.

Using both

They divide along the review/runtime line: sqlcheck educates at review time, RowShield verifies in production. A script can pass every documented anti-pattern check and still deploy into a posture that leaks; when the two disagree, the running system wins the argument, and the scan is how you hear about it.

Frequently asked

Is RowShield affiliated with the sqlcheck maintainers?

No. RowShield is an independent product by Veristria, unaffiliated with the sqlcheck project and its maintainers. sqlcheck is referenced descriptively and remains the mark of its project.

Is RowShield a good sqlcheck alternative?

For script review against published anti-patterns, no — sqlcheck does that and costs nothing. For continuous verification of a live Supabase project, RowShield covers what a script reviewer cannot see; the two serve different moments.

Which SQL anti-patterns matter most for RLS?

The consequential ones are platform-specific: predicates that evaluate to always true, INSERT and UPDATE policies with no WITH CHECK, unindexed auth.uid() predicates, and RLS left disabled. RowShield ships a rule for each and reports them as findings with remediation SQL.