Graphic: Vibecode Beratung · Based on the sources below
Imagine you ask your AI builder for a small new feature on Friday: a table for saved searches. The builder creates the table, turns on row level security (RLS) and writes policies, just as it always has. The preview loads, but nothing saves. The browser console shows permission denied for table saved_searches with code 42501.
Nothing is wrong with your prompt. Supabase changed a platform default, and on October 30, 2026 it reaches every existing project. If your app was built with Lovable, Bolt or another tool that talks to Supabase from the browser, this note explains what changed, what to check first and how to fix it without opening a new hole.
What Supabase changed
Until now, a project created with default settings granted select, insert, update and delete on every table in the public schema to the anon, authenticated and service_role roles. A new table was reachable through the Data API the moment it existed.
According to Supabase’s announcement, new tables in public now start with no access for those roles. Supabase rolled this out in steps: an opt-in setting at project creation from April 28, 2026, the default for new projects from May 30, 2026, and enforcement on all existing projects on October 30, 2026.
Three points limit the impact:
- Existing tables are not affected. They keep their grants and stay reachable.
- It only concerns the Data API, the generated REST and GraphQL layer that
supabase-jsand the other client libraries call. Apps that use a direct Postgres connection through psql, an ORM or an app server are not affected. - Other schemas are unchanged. Tables in
storage,auth,realtimeand custom schemas keep their current grants and defaults.
Supabase gives a clear reason: agents, CLI scripts and AI platforms now create tables, often without a human reviewing the change, and the old default exposed tables before anyone had secured them.
Grants and RLS are two different layers
This is the part that confuses AI builders and people alike. A grant decides whether a role can touch a table at all. RLS decides which rows that role may see or change. If the grant is missing, Postgres rejects the query before RLS is even evaluated.
That is why adding more policies will not fix a 42501 error. It also explains a second error that looks similar: new row violates row-level security policy means the grant exists, but a policy blocked the row. In a Reddit discussion about the change, commenters pointed out that telling these two errors apart saves a lot of guessing. You can also ask Postgres directly with has_table_privilege('authenticated', 'public.your_table', 'select'), which returns true or false.
The fix, in the right order
The order matters more than the statements. Supabase recommends treating grant, RLS and policies as one unit for every new table.
SEV-1: never grant before RLS is on. A grant on a table without RLS makes that table readable with your public key, which is the exact leak this change was meant to prevent. Before you add any grant, list the tables in public that have RLS switched off and fix those first. The earlier note on RLS mistakes in Lovable and Bolt apps covers what a correct policy looks like.
SEV-2: grant only what each role needs. Most apps do not need the same rights for anon and authenticated. Signed-out visitors often need select on a few public tables and nothing else. Logged-in users may need select, insert, update and delete. Write the grants per role, not as one bulk statement.
SEV-3: make the builder do it every time. Supabase suggests updating the system prompt of your AI coding tool, or using the Supabase agent skill, which includes the grant step. The PostgREST error also returns a hint with the missing grant, so an agent can correct itself. If you run your own migrations, put the grant statements in the same migration as the RLS and policy statements.
One open question from the Reddit thread is whether Lovable Cloud projects follow the same date. The sources do not answer it, so check your own project rather than assuming.
Use the change as a review moment
Supabase’s Security Advisor and the Data API exposure badge in the Table Editor list the tables worth reviewing. You can also revoke Data API access from existing tables you never meant to expose. This is a good moment to walk through every table, together with the other checks in the production readiness checklist.
What this means for your project
If your app only adds tables rarely, the impact is small: one failed feature, one clear error, a short fix. The real risk sits in the fix itself. A founder who copies a broad grant from a forum post onto a table without RLS turns a broken feature into a data leak. Make “RLS on, then grant, then policy” a fixed step in how your app gets built, and check that the existing tables in public are exposed only on purpose.
Conclusion
This change makes Supabase safer by default, and it does not break the tables you already have. It does mean every new table needs a deliberate access decision, and that decision now sits with you or your AI builder.
Not sure which of your tables are exposed, or whether your grants and policies match what your app needs? Book a free intro call and we will tell you honestly whether a production-readiness review makes sense for your app.
Frequently asked questions
Will my existing Supabase tables stop working after October 30, 2026?
No. Existing tables keep their current grants and stay reachable through the Data API. The change only affects tables created in the public schema after the new behavior reaches your project.
What does the error permission denied for table (42501) mean in Supabase?
It means the role making the request, for example anon or authenticated, has no grant on that table. The PostgREST response includes a hint with the exact grant statement that is missing.
Does adding row level security policies fix the missing grant error?
No. Grants and row level security are separate layers. A grant decides whether a role can access the table at all, and row level security decides which rows that role can see. You need both.
Is it safe to just run grant select on a table to anon?
Only if row level security is enabled on that table with correct policies. A grant on a table without row level security makes it readable with the public key, so check row level security first, then add the grant.
Does the Supabase grants change affect apps that use a direct Postgres connection?
No. Supabase says the change applies to the Data API, its generated REST and GraphQL layer used by supabase-js and the client libraries. Apps that only use a direct connection through psql, an ORM or an app server are not affected.