Self-initiated demo by Flow Lab · checked on our own test Supabase project (schema copied from our own Lovable demo app) · no client data · the flagged table was created by us for the test and deleted afterwards

Sample report · Supabase October 30 readiness

Will your app still reach its new tables after October 30?

From October 30, 2026 Supabase stops opening new tables in the public schema to the Data API automatically — on every existing project. Tables you already have keep working. A table added after that date without an explicit GRANT answers every app request with permission denied (error 42501), however good its row level security is. Source: Supabase changelog.

16tables in public checked

15ready: RLS on, a policy, API roles have access

1the app can’t reach it (42501) — fix included

0tables open without RLS

What was checked

One read-only query in the project’s SQL Editor (the owner runs it with their own login — no passwords or keys leave the account). For every table in public: is row level security on, how many policies it has, and what the API roles anon, authenticated and service_role are allowed to do. If the app keeps its migrations in a repository, the same check runs on the migration files: which tables are created without an explicit GRANT or without RLS.

Summary

#	What we found	Risk	Result
1	`t_after_1030` — created the way every new table will be created after October 30: no grants for the API roles. Any screen reading it would get “permission denied”.	Breaks new features	Fix SQL generated
—	15 existing tables (bookings, clients, dogs, leads, outbox, services, settings…) — RLS on, one policy each, API roles have access	OK	No change
—	Tables readable by anyone because RLS is off	None found	—

Finding

Breaks new features

A new table the app can’t see

What: The table exists, but anon, authenticated and service_role have no privileges on it. The app’s request fails with 42501 before row level security is even consulted.
Why now: In projects created before May 30, 2026, Supabase adds these grants for you until October 30. After it, every table created by a migration, by an AI builder or in the dashboard starts like this one.
Fix: Explicit grants in the same migration that creates the table — generated by the check, applied only after the table’s RLS policies are reviewed:

grant select, insert, update, delete on public.t_after_1030 to authenticated;
grant select, insert, update, delete on public.t_after_1030 to service_role;
-- anon: only if guests are meant to see it and an RLS policy allows them

Retest: the same query then shows the table as ready.

The check, as it ran

tbl            rls    policies  anon  authenticated  service_role  risk
t_after_1030   false  0         —     —              —             API can't see it (42501) — needs GRANT
automation_runs true  1         ✓     ✓              ✓             ready; write GRANT for new tables
bookings       true   1         ✓     ✓              ✓             ready; write GRANT for new tables
clients        true   1         ✓     ✓              ✓             ready; write GRANT for new tables
…               15 tables ready in total

Run on September 30, 2026 in the SQL Editor of our own test project. The query only reads the system catalog; it changes nothing.

What you get for your app

You run one read-only query in your SQL Editor (we send it as text) — or give us read access to the repository with your migrations.
Within a day: the list of tables at risk, tables open without RLS, and ready-to-apply SQL.
We add the grants to your migrations (or hand them over), you apply, we re-run the check together.
Fixed price USD 150. Built with Claude Code; every change is checked before it ships.

Flow Lab · trading.flowlab@gmail.com · The Supabase change applies to new tables only: existing tables keep their access before and after October 30.