Supabase Data API from 30 October 2026: why new tables need GRANT and what to check in your AI-built app

From 30 October 2026, the Supabase Data API will not see any new table in the public schema until someone grants it access with an explicit GRANT statement. A feature your AI tool adds to the app after that date can therefore return a "permission denied" error instead of data. According to Supabase, existing tables keep their current grants, so an app that works today will not break on its own. The risk sits in the next change. This applies to apps that read data through supabase-js or REST, including Lovable and Bolt projects connected to their own Supabase project.

Below you will find what exactly changes, how to tell whether it affects your app, and what to check before the deadline. If you are dealing with an AI-built app more broadly, start with our first-aid checklist for vibe-coded websites. Why an AI tool may not know about a change that arrived after its training is explained in What an LLM is and what AI cannot do. If your AI-built app throws errors and you do not want to fix it blind, see our AI-built website repair service.

What changes in the Supabase Data API on 30 October 2026

A new table in the public schema will no longer be reachable through the Data API automatically; access has to be granted with an explicit GRANT statement.

The Data API is the layer your app uses to read and write data: the auto-generated REST and GraphQL interface that the supabase-js library calls. Until now, every new table in the public schema received select, insert, update and delete privileges for the anon, authenticated and service_role roles on creation. The table was reachable through the API the moment it existed. Supabase describes the change in its changelog announcement as follows:

Step	Before	After
Create a table in public	Table is reachable through the Data API at once	Table exists, but the Data API cannot see it
Access for anon, authenticated and service_role	Automatic, through default privileges	Explicit GRANT statement required
Enable RLS on the table	No change	No change
RLS policies	No change	No change

The change arrives in three steps. From 28 April 2026 the new behaviour could be switched on when creating a project. From 30 May 2026 it is the default for all new projects. From 30 October 2026 it applies to all existing projects. According to the plan in the announcement, Supabase was to email owners and admins of active projects a notice on 23 September and a final reminder on 23 October. Self-hosted Supabase installations are not affected, according to the announcement.

If a table is missing a grant, the API returns an error with code 42501 and the message "permission denied for table", and the hint field states which role is missing which privilege and which statement fixes it. Supabase explains the change by the fact that tables are no longer created only by people, but also by AI agents, scripts and AI platforms, often without anyone reviewing the change. The default grants therefore also exposed tables that someone forgot to secure.

Supabase Data API and apps built with Lovable or Bolt: are you affected?

You are affected if your app reads tables through the Data API and new tables will still be added to the project.

Supabase lists three situations that require action: the app reads or writes tables in public through the Data API (supabase-js, another client library or direct calls to /rest/v1/ or /graphql/v1), migrations create tables without GRANT statements, or an AI tool or script creates tables and expects them to be reachable at once. If the app talks to the database only over a direct Postgres connection (connection string, ORM, your own server), the change does not affect it.

With AI builders, what matters is where the data actually runs. According to its Supabase integration docs, Lovable designs the schema for a connected project of your own, runs migrations after your approval and saves them in the supabase/migrations/ folder of your code. By default, however, it uses its own built-in backend, Lovable Cloud, built on Supabase's open-source foundation and managed by Lovable. According to its Supabase integration help page, Bolt creates new projects with its own Bolt database and offers Supabase as an alternative on the Pro and Teams plans.

Your situation	Does the change affect you?	What to do
Lovable or Bolt connected to your own Supabase project	Yes, if the app uses the Data API	Check migrations and new tables with the steps below
Your own app on Supabase with supabase-js	Yes	Add GRANT to every migration that creates a table
Lovable Cloud or Bolt database	The Supabase announcement does not mention these managed backends	Check the docs or changelog of the tool
Direct Postgres connection via connection string	No	Nothing
Self-hosted Supabase	No	Nothing

If Supabase emailed you about "affected projects", that does not mean your app will go down on 30 October. A Supabase maintainer explained in the GitHub discussion about the change that the affected-project count refers to the 30 October change, when new tables in existing projects start to require explicit grants. Existing tables will not be affected, according to the maintainer. So the decision depends on whether you will keep adding features to the project.

Grants and RLS: two layers you must not confuse

GRANT decides whether a role can reach a table at all; RLS decides which rows it sees. You need both.

Supabase describes this in its Securing your API guide as two layers of access control. Grants determine which roles can reach a table, view or function through the Data API. Row Level Security (RLS) determines which rows those roles can read or modify. The 30 October change only touches the first layer. RLS works as before.

Fixing this error carries a different risk. The "permission denied" error can be silenced with one bulk statement that grants access to all tables at once. If a table does not have RLS enabled, however, the Supabase docs say any role with a grant can read and modify it, including the anon role used by visitors who are not signed in. RLS is on by default for tables created in the Dashboard. Tables from the SQL editor or another tool need it enabled explicitly.

Supabase therefore recommends treating three steps as one unit: granting privileges, enabling RLS and writing the policies that decide who sees which rows. Privileges can be granted per role, so an anonymous visitor may only read a table while a signed-in user may also edit it. If you split these steps and do only the first, you fix the error but open the data to visitors who are not signed in.

What to check before 30 October: a 6-step process

Run the check before the deadline, not after a new feature returns a blank screen in production.

1. Find out whether the app uses the Data API. Look for the supabase-js library or calls to /rest/v1/ in the code. If the app talks to the database only through a connection string, you can stop here.
2. Look at the Dashboard. Supabase says the exposure badge in the Table Editor and the Data API settings show which tables are reachable through the Data API, and until 30 October the Security Advisor flags affected tables together with the SQL to fix them.
3. Go through the migrations. In a Lovable project you will find them in the supabase/migrations/ folder. Every create table statement in the public schema should sit next to grant statements, RLS being enabled and the policies.
4. Add privileges only where the app needs them. Per role, and always together with RLS enabled. Leave tables that should not be reachable through the API without access.
5. Try the new behaviour on a copy. Supabase has published statements that switch the change on for an existing project today, plus statements to roll it back. Run them on a test project first, not on the live app.
6. Update the instructions for your AI tool. Supabase recommends adding the grants step to the system prompt of the tool that creates tables, or using the Supabase agent skill, which includes this step.

This is the core of the example Supabase gives for a new table. The RLS policies for specific rows follow after it:

grant select on public.your_table to anon;
grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;
alter table public.your_table enable row level security;

A project created after 30 May 2026 already has the new behaviour, so if you load old migrations without GRANT statements into it, for example when setting up a test copy, its tables will not be reachable through the API. For local development the Supabase CLI added a temporary auto_expose_new_tables setting, which a project maintainer says is scheduled for removal on 30 October 2026. The only lasting fix is GRANT statements inside the migrations.

Where it breaks in practice and how we handle it

The biggest risk comes with the first new feature after the deadline that nobody tests on real data.

A model scenario looks like this: a company builds an internal tool or client portal with an AI builder, it runs for months, and in November the company asks for a new section. The AI tool creates a table, but the app cannot see it and the section stays empty or shows an error. When the same tool "fixes" the error with a bulk grant and no RLS, the problem moves from a visible error to a silent data leak. The second weak point is a test copy or a new project filled from old migrations, which behaves differently from the live app.

For companies that had such an app built by an outside vendor, the deciding question is who adds tables after 30 October and whether they know about this change. If that is an AI tool with unchanged instructions or a vendor who no longer maintains the project, it is better to run the check now. If you supply the app to customers, also read our article on the new Slovak product liability law and what it means for software. The principle of testing on a copy before touching production is the same as with WordPress updates through staging and rollback.

How we handle it at Denva: when repairing AI-built sites, we start with a technical audit and turn the findings into a fixed-price plan before any work begins. Before the first change we make a backup and work on a development copy so the live app keeps running, and we switch to production only after everything is verified. Supabase is one of the technologies we regularly work with when repairing AI-built sites.

When you can do it yourself and when to bring us in

You can handle it yourself if:

• the app talks to the database only over a direct connection, not through the Data API,
• you are not adding any new tables to the project,
• you understand migrations and can test the change on a test project.

It is worth bringing us in if:

• the Security Advisor reports tables without RLS, or you do not know which tables are public through the API,
• the app handles customers' personal data and a mistake in the grants would expose it,
• the code was written by an AI tool or a former vendor and nobody knows how the migrations fit together.

Conclusion: what to decide before 30 October

If your app does not use the Data API or nothing more will be added to it, you can note the change and move on. If you keep developing it with an AI tool, do two things before the end of October: check that the migrations contain GRANT statements together with RLS, and add this step to the tool's instructions. If you do not know which tables are public through the API today, start there, because that is a security question even without any change on the Supabase side.

FAQ

Frequently asked questions.

Will my existing Supabase app stop working on 30 October 2026?

Not on its own. According to Supabase, existing tables keep their current grants and stay reachable through the Data API. The change applies to tables created after 30 October, which the app will not see without a GRANT statement.

How do I know whether my app uses the Supabase Data API?

It does if you find the supabase-js library or calls to /rest/v1/ or /graphql/v1 in the code. An app that connects to the database only through a connection string, an ORM or its own server is not affected.

Does the change also affect Lovable Cloud or the Bolt database?

The Supabase announcement does not mention these managed backends, so check the documentation of the tool. The change directly affects your own Supabase project connected to Lovable or Bolt. Lovable Cloud is built on Supabase's open-source foundation, but Lovable manages it.

Can I fix the permission denied error with a GRANT on all tables?

It removes the error, but it can expose data. If a table does not have RLS enabled, every role with a grant gets access to it, including an anonymous visitor. Grant privileges only on tables the app needs, per role, and always with RLS and policies in place.

Can I switch the new behaviour on early and test it?

Yes. Supabase has published SQL editor statements that switch the change on for an existing project now, plus statements to roll it back. Try them on a test project first, then add GRANT statements to your migrations, and only then run them on the live app.