Let your bot get your Supabase app ready for the 30 October grants change
By Šarūnas Vaitkus · about a 6-minute read
From 30 October 2026, Supabase stops giving new tables in the public schema automatic access through its Data API. Your existing tables keep working. But the next table your bot, your app builder or a migration creates will answer "permission denied" until someone grants access. Your bot can find where you're exposed, add the grants through a reviewed pull request, and add a check so it never forgets. You send the prompts below, in order, and it asks you before anything touches a live database.
A Supabase project that your app reaches through supabase-js, the REST API or GraphQL. If your app only uses a direct database connection, you're not affected.
Your bot connected to Supabase, or access to the repo that holds your migrations.
About 10 minutes for reading the access plan and approving the pull request.
How it works
You send a prompt, the bot does the work, and you approve what matters.
Highlighted [brackets] are yours to replace. Copy keeps them in the prompt.
1
Step 1. Check if you're affected (read-only)
Prompt to send
Check whether the Supabase change on 30 October 2026 affects my projects. Don't change anything. For each project, tell me if my app uses the Data API (supabase-js, REST or GraphQL) or only a direct database connection. List every migration, setup script or seed script that creates a table in the public schema, and say which ones already include GRANT statements. Run the Security Advisor and list what it flags. Finish with a plain summary: affected or not, and why.
Why you're sending it
Most apps are fine today. The risk is the next table, or a fresh copy of your database built from old migrations.
What you'll get
A short list per project: affected or not, the scripts that create tables without grants, and the advisor warnings.
2
Step 2. Agree who can read what
Prompt to send
For every table in the public schema of [your project], propose who should have access through the Data API: anon (visitors who aren't signed in), authenticated (signed-in users) and service_role (server code only). Give anon read access only where the app really shows data to visitors. Check each table's existing grants and row-level security (RLS) policies and tell me where the grant you propose is wider than what's there now. Show me the plan as a table and wait for my OK.
Why you're sending it
A grant decides which role can reach a table at all. Row-level security then decides which rows. You want the narrowest grant that keeps the app working.
What you'll get
One table per project showing each role's access, with any widening flagged for your decision.
3
Step 3. Add the grants in a migration
Prompt to send
Write one new migration for [your project] that adds the grants from the plan I approved. Use only GRANT statements, so replaying it can't remove anything. Don't touch tables that already have narrower grants on purpose. Keep row-level security on for every table. Open it as a pull request I can review, with a plain note per table. Don't apply it to any database.
Why you're sending it
A grant-only migration is safe to replay, and a pull request means nothing reaches your data without your OK.
What you'll get
A pull request with one migration file and a table-by-table note on who can do what.
4
Step 4. Fix the setup scripts too
Prompt to send
Find every other place that builds my schema from scratch: full schema scripts, sync scripts, scripts my app builder runs, and seed files. After each CREATE TABLE in the public schema, add the same grants as the migration. Add it to the same pull request.
Why you're sending it
The change also hits new projects, preview branches and local resets. A script that rebuilds your database without grants gives you an app that loads but shows nothing.
What you'll get
The same pull request, now covering every script that creates tables.
5
Step 5. Add a check so it never happens again
Prompt to send
Add an automated test to [your repo] that fails when a new migration creates a table in the public schema without a GRANT in the same file. Allowlist the migrations that already exist so the test passes today. Explain in the pull request how to fix a failure.
Why you're sending it
You, your bot and your app builder will all create tables later. A failing test is cheaper than a broken screen after release.
What you'll get
A test that runs with your other tests and names the file and the missing grant when it fails.
6
Step 6. Prove it on a throwaway copy
Prompt to send
Replay all my migrations on a throwaway database: a local reset if you can, or a preview branch if I approve the cost first. Then call each table through the Data API as anon and as a signed-in test user. Confirm the app's pages load their data, that anon can't read anything outside the plan, and that no request returns a 42501 permission error. Report pass or fail per table.
Why you're sending it
A fresh replay is exactly the situation that breaks after 30 October, so test that, not the old database.
What you'll get
A pass or fail for each table and role, with a fix for anything that failed.
7
Step 7. Make it a standing rule
Prompt to send
Save this as a standing rule for you and any coding agent you brief: every new table in the public schema gets its GRANT statements in the same migration that creates it, anon gets read access only where visitors need it, and row-level security stays on. Add the rule to the repo's agent instructions file too.
Why you're sending it
The next table might come from a different agent or tool. A written rule travels with the repo.
What you'll get
A saved rule, and a one-paragraph note in the repo that other agents read before they work.
8
Step 8. Watch for errors after the change
Prompt to send
From 30 October, check my Supabase logs once a week for 42501 "permission denied" errors from the Data API. If you find one, tell me the table, the role and the GRANT that would fix it, and open a pull request with the fix. Only message me if something's wrong.
Why you're sending it
If something slips through, the error message already names the missing grant, so the fix is quick if someone is looking.
What you'll get
A quiet weekly check that speaks up only when a table is blocked.
All in one (optional)
Prefer one prompt? Send this instead.
Prompt to send
Get [your Supabase project] ready for the 30 October 2026 Data API grants change, in this order: a read-only check of whether I'm affected, an access plan per table and role that I approve, a grant-only migration and fixed setup scripts in one pull request, a test that fails when a new table has no grant, a replay on a throwaway database, a standing rule for future tables, and a weekly error check. Pause after each step to show me what you did. Ask me before applying anything to a live database, spending money on a branch, deleting anything or sending anything outside.
What your bot will always ask you first
Applying a migration to a live database.
Opening anon (visitor) access to a table that didn't have it.
Creating a paid preview branch or any other spend.
Deleting tables, policies or grants.
Sending anything externally.
It bundles its questions, so you're not pinged all day.