PatchLabs vs Supabase Security Advisor
The Advisor says a rule looks risky. PatchLabs proves who can read the rows.
Supabase’s Security Advisor is free, built into every project and worth running. It checks your database against documented rules. PatchLabs rebuilds your database from your migrations, tests it as three different people, writes the fix and proves it. Most teams should use both.
Choose the Security Advisor when
You want instant, free checks on the database that’s actually running.
- You want results in seconds, inside Supabase Studio, the CLI or their MCP server
- You also want performance and health checks, which we don’t do
- You changed policies in the dashboard without a migration: the Advisor sees your live project, we only see your repo
- You’re comfortable writing and testing the fix yourself
Choose PatchLabs when
You want the fix written, and proof that it works, before it ships.
- You want every fix tested as an anonymous visitor, a signed-in stranger and the owner
- Your code lives in GitHub (exported from Lovable, Bolt, Replit or Cursor) and you want a migration to review
- You need to know whether a “permissive” table is actually leaking personal data, or meant to be public
- You want scheduled re-checks, alerts, keys found in git history and signed receipts
Side by side
Same database, two different questions.
The Advisor asks “does this database break a known rule?” PatchLabs asks “who can actually read these rows, and does the fix stop them?”
| PatchLabs | Supabase Security Advisor | |
|---|---|---|
| What it is | A lab check that starts from your GitHub repo | Deterministic lints built into every Supabase project |
| What it looks at | Your supabase/migrations, code and full git history | Your live project’s database |
| How it decides | Runs real queries as anon, a signed-in stranger and the owner on a rebuilt copy | Documented rulese.g. RLS disabled in public, sensitive columns exposed, permissive policy |
| Writes the fix | SQL migration, plus code notes | Docs suggest SQLYou write and apply it |
| Tests the fix | Every fix, as three identities, before you see it | You re-run the lintsSome lint docs explain how to verify |
| Tables meant to be public | Asks you in plain English, then remembers your answer | Docs note some findings may be intentional |
| Keys in code and git history | AI, payment and database keys | Not in scope |
| Performance and health checks | No | Yes, alongside security |
| Monitoring and alerts | Scheduled re-checks, email, webhook | On demandScheduled runs and email alerts not described in the docs |
| Connects to your live database | Never | It is your project’s own tool, so it reads your live project |
| For agents | Remote MCP server | Supabase MCP server (get_advisors) |
| Time | Median 3.5 min to a proven fixLab study, n=20, 9 Nov 2026 | Instant |
| Price | Free for 1 appThen from £19/month | Included in every Supabase project |
Last checked 10 Nov 2026 against Supabase’s public docs. Report a correction.
Engineers
Advisor lints and our findings, mapped.
Our free RLS check and full reports use stable finding IDs. This is the closest match to Supabase’s lint IDs. The rules aren’t identical; it’s a reading aid, not an official mapping.
| Supabase lint | Closest PatchLabs finding | What the lab adds |
|---|---|---|
0013 RLS disabled in public | PL-008 RLS never enabled | Shows whether anyone can actually read rows, and which columns |
0023 sensitive columns exposed | PL-001 anon can read personal data | Runs the read as an anonymous visitor and counts the rows returned |
0024 permissive RLS policy | PL-005 always-true policy · PL-002 any signed-in user reads all rows | Separates real leaks from tables meant to be public, then asks you |
0008 RLS enabled, no policy | PL-003 RLS enabled but no policies | Checks the owner can still read their own rows after the fix |
0011 function search path mutable · 0028/0029 security definer function executable | PL-006 SECURITY DEFINER function without search_path, or granted to anon | Flags it in the report; the fix migration sets the search path or revokes the grant |
0025 public bucket allows listing | PL-007 storage bucket made public in a migration | Related, not identical: we read it from your migrations |
| No direct match in the lints we reviewed | PL-004 UPDATE policy without WITH CHECK | Catches updates that let a user move a row to someone else |
Behaviour, not lint
A rule can look fine and still leak. Or look risky and be exactly right.
A product catalogue that anyone can read is meant to be public. A profiles table with a policy that looks scoped can still return every row to a signed-in stranger. Only running the query as each person tells you which is which.
Our limit. The lab is only as complete as the migrations in your repo. If you changed a policy in the Supabase dashboard without a migration, the Advisor sees it and we don’t. Our report says what it couldn’t check.
[PROBE] anon → public.products 12 rows · name, price no personal columns [ASK] Meant to be public? recommended: yes, mark intended [PROBE] stranger → public.profiles 2 rows · email •••••@••••• LEAK [PROVE] after fix: stranger 0 rows DENIED owner → own row OK
Use both
A sensible routine for a Supabase app.
Run the Advisor
Open Security Advisor in Supabase Studio, or run it from the CLI. Fix anything that’s obviously a mistake.
seconds, freePaste your repo here
PatchLabs rebuilds the database from your migrations and tests every table as three people.
median 3.5 minApprove the proven fix
Download the migration or commit it on GitHub in one click. Answer any business questions.
your engineer decidesKeep both running
Re-run the Advisor after dashboard changes; let PatchLabs re-check on a schedule and email you if a leak returns.
weekly or monthly
Questions
Asked about the Advisor.
If the Advisor shows no errors, am I safe?
It means your database doesn’t break the rules it checks. It doesn’t run queries as different users, so a policy that looks correct but still returns other people’s rows can pass. That is the gap our lab tests. Neither tool can promise an app is secure.
Does PatchLabs connect to my Supabase project?
No. We never need your database password or service-role key. We rebuild a disposable copy from the migrations in your public GitHub repo, with Supabase’s roles, auth functions and default grants, seeded with fake rows.
Why would a lint flag a table that’s fine?
Some tables are meant to be readable by anyone, such as a public product list. Supabase’s docs acknowledge findings can be intentional. Our report asks you in plain English, with a recommended answer, and remembers when you mark a table as intended.
Which should I run first?
The Advisor, because it’s instant and already in your project. Then run PatchLabs for proof that the fix works as each kind of user.
Sources
Where these facts come from.
- Supabase docs: Database Advisors · lint IDs, levels, remediation and false-positive notes, access via Studio, CLI, MCP and Management APIchecked 10 Nov 2026
- Supabase pricing · Advisors are built into projects; the pricing page doesn’t mention plan gatingchecked 10 Nov 2026
- PatchLabs methodology · the 3.5-minute median (n=20, 9 Nov 2026)ours
Independent
PatchLabs is independent and not affiliated with Supabase. Product names are used only to identify them. Facts were checked on 10 Nov 2026 and may have changed since; we update these pages when we hear about a change.
Free check
See the proof for your own app. The first one is free.
Paste your public repo. You’ll get the leaks, the fix and the proof on one page, in a few minutes.