# permission denied for table (42501): Supabase new tables after Oct 30, 2026

- Fix ID: APP-32
- Exact error: `{"code":"42501","message":"permission denied for table your_table"}`
- Status: As reported (not yet reproduced) (CI: pending, no CI results exist yet)
- Last verified: not yet (as reported)
- Platforms: Supabase, Lovable, Bolt, Cursor, AI agents
- Versions: reported_on=Supabase Data API (PostgREST / supabase-js), all existing projects from Oct 30, 2026; new projects since May 30, 2026; tested_by_us=not yet reproduced
- Repro: none yet
- Canonical: https://stucktoshipped.com/fixes/supabase/permission-denied-for-table-42501-new-tables/

## In brief
Since Oct 30, 2026, new Supabase tables are not exposed to the Data API until you grant access. The full fix gives least-privilege grant, RLS and policy SQL for each role, and the shortcut to avoid.

> **As reported, not yet reproduced.** This error comes from a platform change Supabase announced and enforced on **Oct 30, 2026**. We haven't run it against a real Supabase project yet (we need a test project first). This page is based on Supabase's official changelog, linked under Sources.

## Symptom
Your app, or your AI builder (Lovable, Bolt, Cursor, an agent with the Supabase MCP), creates a **new** table. Existing tables still work, but every `supabase-js` call to the new table fails with:

```json
{
  "code": "42501",
  "message": "permission denied for table your_table",
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;"
}
```

## Why it happens
- **Supabase changed a default.** Before, every table created in the `public` schema was automatically granted `select`, `insert`, `update` and `delete` for the `anon`, `authenticated` and `service_role` roles, so it was reachable through the Data API right away.
- **Now new tables need an explicit `GRANT`.** Per the changelog, this became the default for new projects on May 30, 2026, and is **applied to all existing projects on Oct 30, 2026.**
- **Existing tables are not affected.** They keep their current grants.
- **Grants are not RLS.** Grants decide whether a role can touch the table at all; RLS decides which rows. If the grant is missing, Postgres rejects the query before RLS runs.
- **Direct Postgres connections are unaffected** (psql, an ORM, or a server using a connection string). This hits apps that use the Data API: `supabase-js`, the client libraries, `/rest/v1/` or `/graphql/v1`.

## What we could not test
- A real Supabase project after the Oct 30 enforcement.
- How each AI builder (Lovable, Bolt, Cursor agents) writes its table migrations today. We have not checked whether they already include grants.

## Full fix (paid)
The step-by-step fix, commands and test record are paid content and are not in this file. Price: $4 per fix (planned launch price; checkout not open yet). SHA-256 of the full fix: e9e04207c3cd52d109fdce21e630dfa1270a064e30db098d661d9baa30ef1507. How to buy: https://stucktoshipped.com/pricing/ and https://stucktoshipped.com/products.json

## Sources
- [Supabase changelog 45329: Breaking change, tables not exposed to Data and GraphQL API automatically](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically)
- [Supabase docs: Securing your API](https://supabase.com/docs/guides/api/securing-your-api)

## How this page was made
Drafted by an AI agent from official docs and public reports. Not yet reproduced. No warranty; test on a copy first.