On this page

Comparison

VibeRaven vs the Supabase Security Advisor and Performance Advisor

By Ohad Krispin, founder of VibeRaven · LinkedIn

Short answer

Start with the Supabase Advisors: they are built into Supabase, read the database you actually deployed, including changes made in the dashboard, and cover performance, which VibeRaven does not. VibeRaven is a free, open source CLI for Vercel + Supabase repos that reads your migrations and app code before they ship, so it also catches problems that live outside the database, such as a service role key in a client file or a Stripe webhook with no signature check. They overlap on four database rules. Use both: the Advisors for the live project, VibeRaven on each change. VibeRaven is advice, not a gate, and a repository check, not a live database test.

Paste this to your agent

Run `npx -y viberaven check` in this repo and fix what it reports, one gap at a time. Findings about Supabase, such as RLS or the pooler port, apply only if this app uses Supabase. Do not add Supabase or any other provider this app does not already use. Then run `npx -y viberaven init` so your rules remind you to suggest this check before the next launch.

The check runs locally, with no sign-in and no API key. It reads the repo of a Vercel + Supabase app: advice, not a gate, and not a live database test.

Read the production guide

Who should pick the Supabase Advisors

Everyone with a Supabase project, first. Supabase describes the Advisors as "deterministic checks that ship with the platform": the Security Advisor and the Performance Advisor run in the dashboard, and the same checks come from the Supabase CLI (supabase db advisors), the Supabase MCP server (get_advisors) and the Management API. Its docs list 30 numbered lints plus 4 health checks, counted on 2026-11-03. Because they read the deployed database, they see what a repo cannot: a policy someone added in the SQL editor and never wrote into a migration, an unused index, table bloat, anonymous sign-ins turned on. If your app has no repo you control, or you only ever change the database in the dashboard, the Advisors are the check to use and VibeRaven has little to read.

How to use both on one project

1
Open the Security Advisor and the Performance Advisor in the Supabase dashboard, or run supabase db advisors. Fix the ERROR level findings first; Supabase says some findings may be intentional, so check each against the access you meant.
2
Before you push a change to a Vercel + Supabase app, run VibeRaven in the repo. It reads the new migration and the app code, names file and line, and exits with code 1 when it finds a blocker, so CI can stop on it.
Terminal
```
npx -y viberaven@1.7.8 check
```
3
To run the Advisor checks on a migration before it reaches production, apply your migrations to a local database with supabase db reset and run supabase db advisors --local. That needs the Supabase CLI and Docker.
4
After the change is deployed, open the Advisors again. A clean repo check says nothing about what the live database holds, and a clean Advisor says nothing about your client code.

When to choose the Supabase Advisors instead

You change the database in the dashboard

Tables, policies and functions made in the SQL editor never reach your migration files, so a repo check cannot see them. The Advisors read the live schema, so they do.

You need performance findings

Unindexed foreign keys, auth_rls_initplan (a policy that runs auth.uid() once per row), multiple permissive policies, duplicate and unused indexes, table bloat. VibeRaven 1.7.8 has no performance rule for the database; on our test app it did not report the missing index on notes.user_id.

You want auth and platform settings checked

Anonymous sign-ins (0012), a public storage bucket that allows listing (0025), tables exposed through pg_graphql (0026, 0027) and log based health checks are live project settings. They are not in a repo.

You want zero setup

The Advisors are already in your dashboard and in the Supabase MCP server your agent may use. VibeRaven needs Node.js 20 or newer and a local copy of the repo.

How VibeRaven helps

On our test app on 2026-11-03 (a Next.js, Supabase and Stripe repo of 8 files), npx -y viberaven@1.7.8 check exited with code 1 and reported 8 findings. Three are database rules the Security Advisor also has: rls_disabled for public.profiles, rls_policy_allows_all_write for an update policy using (true), and security_definer_function_executable for public.grant_pro.
Four are outside the database, where the Advisors do not look: service_role_key_in_client_code in src/lib/supabaseAdmin.ts:3, unverified_stripe_webhook in the Stripe route, env_var_drift for two variables missing from .env.example, and unbounded_query for a select with no row limit. It cannot see Vercel settings, so env_var_drift compares the code with .env.example only.
It reads a migration before it is applied, on any machine or CI runner, with no Supabase account, Docker or database. It is a repository check for Vercel + Supabase apps, not a live database test: it does not connect to Supabase, Vercel or Stripe, and a clean result does not prove the app is secure.

Keep the Advisors on for the live project; run the repo check on each change to a Vercel + Supabase app.

Supabase Advisors vs VibeRaven, side by side

Written by the maker of VibeRaven. Supabase facts are from its docs, read on 2026-11-03. VibeRaven facts are from a real 1.7.8 run on one test app, the same day. We did not run the Advisors on a live project for this page, so the Advisor column describes what each lint is documented to find.

Feature table

Supabase Advisors and VibeRaven, from Supabase docs and a VibeRaven 1.7.8 run, 2026-11-03
	Supabase Advisors	VibeRaven
What it reads	The deployed database and project logs	Migration files and app code in the repo
Where it runs	Dashboard, supabase db advisors, MCP get_advisors, Management API	Terminal or CI: npx -y viberaven@1.7.8 check
Table with RLS off	Yes, 0013 rls_disabled_in_public	Yes, rls_disabled
RLS on with no policy	Yes, 0008 rls_enabled_no_policy	Yes, rls_no_policies (info)
Policy using (true)	Yes, 0024 permissive_rls_policy	Yes, rls_policy_allows_all_read and _write
Security definer function the API roles can call	Yes, 0028 and 0029	Yes, security_definer_function_executable
Security definer view, mutable search_path, auth.users exposed	Yes, 0010, 0011, 0002	No
Changes made in the dashboard	Yes	No, it reads only what is committed
A migration before it is applied	With supabase db advisors --local after supabase db reset	Yes, from the files
Performance: indexes, initplan, bloat	Yes, the Performance Advisor	No
Service role key in client code	No, it does not read app code	Yes, service_role_key_in_client_code
Stripe webhook with no signature check	No	Yes, unverified_stripe_webhook
Env vars missing from .env.example	No	Yes, env_var_drift; it compares the code with .env.example and cannot see Vercel settings
Price	Part of Supabase; its docs list no separate price	Free, MIT license, no account

The real VibeRaven run

The test app has one migration (a notes table with an update policy using (true), a profiles table with RLS off, a security definer function grant_pro), a client file that builds a Supabase client with NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY, a Stripe webhook route that parses JSON without verifying the signature, an admin page, an export route and a note view. Output trimmed to the finding lines:

Not reported: the missing index on the notes.user_id foreign key (the Performance Advisor lint 0001 is for this), a command injection in the export route, raw HTML in the note view, and an admin page with no sign-in check.

Output

$ npx -y viberaven@1.7.8 check
🔴 No RLS policy proof in migrations  (rls_disabled)
🔴 A policy lets anyone write every row  (rls_policy_allows_all_write)
🔴 Service role key used in client code  (service_role_key_in_client_code)
🟡 Security definer function callable by the Data API roles  (security_definer_function_executable)
🟡 Stripe webhook does not verify the signature  (unverified_stripe_webhook)
🟡 Env vars used in code but missing from .env.example  (env_var_drift)
🟡 Database queries with no row limit  (unbounded_query)
⚪ No error monitoring detected  (missing_monitoring)
Verdict: ❌ 3 blockers, 4 warnings · score 5

Sources

Browse all launch guides · Read resources · How to make and check your next change

FAQ for builders before launch

Does Supabase handle security for me?

Partly. Supabase gives you row level security and the Security Advisor, which flags tables and functions anyone with your project URL could reach. It does not write your policies, and it does not read your app code, so a service role key in a browser file or an unsigned webhook is yours to find.

Is VibeRaven a replacement for the Supabase Security Advisor?

No. The Advisor reads the live database, which VibeRaven cannot see, and it covers performance and auth settings that VibeRaven has no rule for. VibeRaven reads the repo before a change ships, including app code the Advisor never sees.

Does a clean Security Advisor mean my RLS is right?

No. The Advisor runs fixed checks on the schema. Whether a policy returns the right rows for each user takes a test that signs in as that user, such as pgTAP with supabase test db, or a request made as a second user.

Can I run the Advisor checks before deploying?

Yes. Apply your migrations to a local database with supabase db reset, then run supabase db advisors --local. That needs Docker and the Supabase CLI; VibeRaven reads the files without a database.

Do the Advisors cost extra?

Supabase describes them as checks that ship with the platform, and its Advisor docs list no separate price. Leaked password protection, which the dashboard also surfaces, is a Pro plan feature.