Supabase verandert op 30 oktober: waarom je nieuwe tabel ineens een permissiefout geeft

Je vraagt Lovable om een nieuwe functie, er komt een tabel bij, en het scherm blijft leeg. Of je ziet in de console permission denied for table. Je oude tabellen werken gewoon, alleen de nieuwe niet. Dat is geen bug in je app. Supabase verandert op 30 oktober 2026 hoe nieuwe tabellen bereikbaar zijn, en als je AI-tool een tabel aanmaakt zonder de rechten erbij, krijg je precies deze fout.

Wat Supabase verandert

Tot nu toe kreeg elke tabel in het schema public automatisch de rechten select, insert, update en delete, voor de rollen anon, authenticated en service_role. Wat je ook aanmaakte, het was meteen bereikbaar via de Data API: supabase-js, REST en GraphQL.

Dat stopt. Sinds 28 april 2026 konden nieuwe projecten daar al voor kiezen, sinds 30 mei is het de standaard voor nieuwe projecten, en op 30 oktober 2026 geldt het voor alle bestaande projecten. Een nieuwe tabel in public is vanaf dan niet bereikbaar via de Data API totdat je er zelf rechten op geeft.

Wat niet verandert: je bestaande tabellen houden hun rechten. Een directe Postgres-verbinding werkt zoals altijd, en storage, auth, realtime en eigen schema's vallen erbuiten. Het gaat alleen om tabellen die je na de overgang nieuw aanmaakt in public.

Supabase noemt zelf als reden dat AI-tools tabellen aanmaken zonder dat iemand ernaar kijkt, en een tabel die vanzelf openstaat is dan een risico dat niemand heeft gezien. Voor jou betekent het vooral dat een nieuwe functie het niet doet terwijl de rest van je app gewoon doorloopt.

Waarom het bij jou ineens misgaat

Het patroon is bijna altijd hetzelfde. Je vraagt je AI-tool na 30 oktober om iets nieuws: een lijst met afspraken, notities bij een klant, een instellingenpagina. De tool maakt een tabel aan, schrijft de code die ernaar leest en schrijft, en in de preview zie je een lege lijst of een foutmelding. Opslaan doet niets. Vraag je de tool om het te repareren, dan gaat hij makkelijk in je frontendcode zoeken, terwijl het probleem in de database zit.

Zo herken je het: fout 42501

Open je app, druk op F12 en kijk in het tabblad Network naar het verzoek naar je Supabase-project. Bij deze fout komt er een antwoord terug dat er zo uitziet:

{
  "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;"
}

Op de plek van your_table staat de naam van je nieuwe tabel. Ook in de console van je browser zie je permission denied for table voorbijkomen. In de Table Editor van Supabase staat bovendien per tabel een badge die laat zien of hij via de Data API bereikbaar is, dus daar zie je in één oogopslag welke tabel het is.

Twee dingen maken het verwarrend. De hint die Supabase meestuurt stelt voor om anon rechten te geven, en dat is precies wat je niet blind moet doen. En veel schermen tonen een fout niet maar laten de lijst gewoon leeg, waardoor het lijkt alsof er geen gegevens zijn.

De oplossing, en de fout die je niet moet maken

Supabase geeft zelf deze SQL als oplossing, uit te voeren in de SQL Editor van je project. Vervang your_table door de naam van je tabel en user_id door de kolom waarin de eigenaar van de rij staat:

grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;

-- Alleen als anonieme bezoekers (niet ingelogd) deze tabel mogen lezen:
-- grant select on public.your_table to anon;

alter table public.your_table enable row level security;

create policy "users can read their own rows"
  on public.your_table
  for select
  to authenticated
  using (auth.uid() = user_id);

De eerste twee regels zijn de rechten, de grants: welke rol de tabel überhaupt mag bereiken. De regel voor anon staat bewust uit: haal de streepjes alleen weg als anonieme bezoekers deze tabel echt mogen lezen. De laatste twee zetten Row Level Security aan en maken een regel die bepaalt welke rijen iemand te zien krijgt. Dat zijn twee aparte lagen, en je hebt ze allebei nodig.

Grants zonder RLS betekent dat je tabel weer openstaat. Dan heb je met de hand teruggezet wat Supabase net heeft dichtgedaan.

Plak die eerste regel dus niet bij elke tabel. Geef anon alleen rechten op tabellen waarvan anonieme bezoekers echt iets mogen zien, zoals openbare producten of blogberichten, en dan alleen select. Een tabel met klantgegevens, facturen of berichten heeft voor anon niets nodig. Zet op elke tabel RLS aan, met een policy die past bij wie wat mag zien. Een policy met using (true) is geen afscherming, dat is de deur openzetten met extra stappen.

Het voorbeeld hierboven regelt alleen lezen. Mogen gebruikers ook toevoegen, wijzigen of verwijderen, dan heb je daar per actie een eigen policy voor nodig. Daarna laat de Security Advisor van Supabase zien welke tabellen het waard zijn om nog eens na te lopen.

Laat je AI-tool het goed doen

Werk je in Lovable, Bolt of een vergelijkbare tool, dan kun je dit in één keer laten regelen. Plak dit in de chat, met de naam van je tabel erin:

De tabel [naam] geeft permission denied for table (42501), omdat Supabase nieuwe tabellen niet meer automatisch via de Data API bereikbaar maakt. Schrijf een migratie die per rol alleen de rechten geeft die nodig zijn: anon alleen als anonieme bezoekers deze gegevens mogen zien, authenticated en service_role wat de app echt gebruikt. Zet Row Level Security aan en schrijf per actie een policy die bepaalt welke rijen een gebruiker mag lezen en wijzigen. Gebruik nooit using (true). Laat me de SQL eerst zien voordat je hem uitvoert.

Dat laatste is het belangrijkst. Lees de SQL voordat je op akkoord drukt en let op twee dingen: staat er ergens to anon bij een tabel die privé hoort te zijn, en staat er een policy bij die iedereen alles toestaat. Zie je een van de twee, vraag dan waarom.

Waar het geen klusje meer is

De grants zijn mechanisch. De policy is het lastige deel, want daar moet iemand bedenken wie welke rijen mag zien, en precies daar gaan AI-tools de mist in: een policy die in de preview werkt omdat je als jezelf test, maar die gebruiker A de gegevens van gebruiker B laat zien. Hoe je dat controleert staat in waarom kunnen mijn gebruikers elkaars gegevens zien. De rest van de lijst voordat je live gaat staat in is je AI-gebouwde app veilig voor echte klanten.

Heb je meerdere tabellen en weet je niet meer welke regels er eigenlijk gelden, dan is dat het moment om het uit handen te geven. Op vastgelopen met AI-coding staat hoe ik dat overneem, en een vibecode-assessment zet alle tabellen, rechten en policies op een rij met wat er moet gebeuren.

Wil je eerst alleen weten waar je staat, begin dan met de gratis vibecode-scan. Ik kijk tien minuten naar je project en je krijgt een eerlijk oordeel terug.