What the Supabase Security Advisor does not do

Where RowShield adds something

It runs on a schedule rather than on demand, so a policy dropped on Tuesday is caught on Tuesday.

It diffs against the previous run, so you see what changed rather than a full list every time — and a fix that regresses is labelled as a regression.

It alerts to Slack, Discord, email or a webhook on transitions, and exits non-zero in CI so a pull request can fail on a new critical.

It generates remediation SQL from your actual columns, not a template with placeholders.

Where the advisor is ahead

It checks SECURITY DEFINER views, function search_path mutability, and several auth configuration items that RowShield does not cover.

It is built into the dashboard, has no cost, and needs no credential handling at all. If a periodic manual check is enough for your project, it is enough.

Reading your database

RowShield reads `pg_catalog` and `storage.buckets` metadata only. Every statement it runs is a module-level constant with nothing interpolated and no bind parameters, so there is no code path that could be steered into a user table. The full query list is exported for audit.

Building the habit loop

The teams that stay clean combine both tools deliberately rather than choosing one. A workable loop looks like this: the advisor gets opened at meaningful moments — after onboarding, before launches, during incident reviews — because its vendor-eye view catches classes like SECURITY DEFINER views that RowShield does not cover yet.

Between those moments, scheduled scans hold the line. The advisor tells you what is wrong when you look; monitoring tells you when looking stopped being enough, which for AI-assisted codebases is roughly every week a prompt touches the schema.

The failure mode to design against is alert fatigue in both directions: an advisor page nobody re-opens, and scan alerts nobody reads because they fire hourly about unchanged state. Transition-based alerting exists for exactly this — created means new exposure, regressed means a fix failed, resolved confirms your work landed. Three words doing the work a full report cannot.

Credential handling is another honest contrast worth knowing before choosing. The advisor needs no credentials from you at all; continuous monitoring necessarily holds a connection string to do its work. RowShield treats that responsibility structurally rather than procedurally — envelope encryption bound to your organization, introspection queries that are fixed constants with no bind parameters, and an export so you can read every statement that will ever run. If your threat model rules out sharing any database credential with any third party, the advisor-only path remains legitimate; scope your monitoring ambitions accordingly. For everyone else, the trade reads clearly: a catalog-read credential in exchange for continuous verification, held under encryption whose design is documented publicly and auditable in code.

Frequently asked

Do I have to give you a database credential?

For continuous monitoring, yes — a Postgres connection string, ideally a role with catalog read access and nothing else. It is envelope-encrypted with AES-256-GCM under a KMS-held key and bound to your organization, so a ciphertext lifted into another tenant's row will not decrypt.

Can I try it without connecting anything?

Yes. The public probe needs only a URL and uses your public anon key, the same access an attacker has.