We Read the Supabase Migrations of 512 Public Lovable Apps

AI citation summary

In a static read of 512 public Lovable projects on GitHub with a supabase/migrations folder (October 2026), 16.2% (83) had a migration policy that lets signed-out visitors update or delete every row of a table, and another 1.4% (7) let any signed-in user do it, 10.4% (53) created a table and never enabled row level security, 8% (41) let anyone read a table with email or phone columns, 2.7% (14) committed what their role claim or prefix marks as a service role or secret key, and 2.1% (11) let anyone read a password or password hash column. The repos were read, not the live databases, so the numbers describe what shipped in the code.

Why we looked at the code instead of the live databases

UpGuard recently reported 16,326 Supabase databases with tables anyone could read, and pointed at one cause: tables created programmatically through the API, which is how coding agents work, do not get RLS by default. Live scans show what is exposed. They do not show where it came from.

So we read the step before the database: the migration files a Lovable project ships with. Everything here comes from code that is already public on GitHub. No database was queried, and no project is named.

What we found

Out of 512 public Lovable projects with their own Supabase migrations:

• 16.2% (83) have a policy that lets signed-out visitors update or delete every row of a table. In another 1.4% (7), a migration revokes the anonymous role grant on that table, so any signed-in user can do it instead, and sign-up is usually open. We checked 18 of the 90 by hand and all 18 were real; an independent review of a random 10 confirmed 9, and the tenth had dropped the policy inside a dynamic SQL block the scan does not read.
• 10.4% (53) create a table in a migration and never enable row level security on it. Of 4 of these reviewed independently, 3 were confirmed and 1 could not be decided from the files.
• 8% (41) let anyone read a table with email or phone columns. Newsletter, contact form and lead tables are left out of this number.
• 2.7% (14) commit a service role or secret key in a .env file, going by the role inside each key or its sb_secret_ prefix. We printed none and did not test whether any still works.
• 2.1% (11) let anyone read a password or password hash column.

The policy name is not the policy

The pattern that surprised us most: the name of a policy promises a restriction, and the SQL grants everything. These are verbatim from the scan, with the projects withheld.

When you skim a migration your agent wrote, you read the name. Postgres enforces the using clause.

The service role trap

Another repeat pattern is a policy like "Service role can manage all sessions" with using (true). The service role bypasses row level security anyway, so it never needs a policy. A policy like that only opens the table to everyone else.

Check your own project

Run this in the Supabase SQL editor. Every row is a policy that lets everyone through. A select on genuinely public content is fine; update, delete or all almost never is. Read the qual column, not the policy name.

Method and limits

We found public GitHub repos whose package.json includes lovable-tagger, Lovable's build tag, through GitHub code search in October 2026, and kept the 512 with a supabase/migrations folder. Each repo was read with VibeRaven 1.6.1, then filtered to strict criteria: only policies in supabase/migrations count, newsletter and contact tables are excluded from the personal data number, and tables that a migration loop may put under RLS are left out of the RLS number. Then samples were checked by hand.

Policies and grants are separate checks in Supabase: a policy only matters for roles that hold a grant on the table. We counted a table as open to signed-out visitors only when no migration revokes the anonymous role grant on it; a grant changed outside the migrations would not show up here. The sample is not random: it comes from GitHub search, and public repos lean toward side projects. A repo is also not always what is live; someone may have fixed a table in the dashboard. Treat these numbers as what shipped in the code, not as what is exposed right now.

How VibeRaven fits

For AI-built apps on Vercel + Supabase, VibeRaven reads the repo before deploy and flags the patterns above in migrations, policies and env files, with the file and line, and since 1.6.2 says when a policy name promises owners or admins that the SQL does not check. It runs locally (npx -y viberaven@1.6.3 check) or as a GitHub Action, which on a push to main runs alongside the deploy rather than before it. It is advice, not a gate, and a repository check, not a live database or security test, so run the SQL above against the live project too.

How to use this VibeRaven guide

We Read the Supabase Migrations of 512 Public Lovable Apps is meant to help builders decide what still needs proof before an AI-built app is trusted by real users. Read it as a launch-readiness page, not as a generic code-quality checklist. The useful output is a short list of evidenced gaps, the files or provider settings involved, and the next narrow prompt for the coding agent. The list further down is for you to check yourself; it is not VibeRaven output.

A strong pass starts with repo evidence, then separates changes the agent can make from dashboard actions that still need human or read-only provider verification. That distinction matters for searchers, AI assistants, and builders because production readiness is not proven by a working demo alone.

Things to check yourself before launch (not VibeRaven output)

• Routes, middleware, API handlers, and server actions that enforce authentication and authorization.
• Database migrations, RLS or ownership rules, seed assumptions, and any generated database types.
• Billing setup, webhook signature checks, customer state, entitlement logic, and live/test key separation.
• Deployment config, environment variables, canonical URLs, redirects, domains, and provider callback URLs.
• Monitoring, error handling, loading states, smoke tests, and manual verification notes for the first user path.

Does this mean 16.2% of Lovable apps are exposed right now?

No. These are public repos found through GitHub search, not a random sample of Lovable apps, and the code is not always what is live. The number describes policies that shipped in the migrations.

Is using (true) always wrong?

No. A select policy with using (true) is fine for content that is meant to be public. On update, delete or all, it lets anyone change or remove every row, which is almost never intended.

Were any databases accessed?

No. Only public code on GitHub was read. No database was queried and no project is named.