Supabase Data API od 30. října 2026: proč nová tabulka bez GRANT nefunguje a co zkontrolovat v aplikaci z AI

Od 30. října 2026 neuvidí Supabase Data API žádnou novou tabulku ve schématu public, dokud jí někdo výslovně nepřidělí přístup příkazem GRANT. Funkce, kterou vám AI nástroj do aplikace přidá po tomto datu, proto může místo dat vrátit chybu „permission denied“. Stávající tabulky si podle Supabase dosavadní přístupy ponechají, takže dnes fungující aplikace se sama od sebe nerozbije. Riziko je v další změně. Týká se to aplikací, které čtou data přes supabase-js nebo REST, tedy i projektů z Lovable a Bolt napojených na vlastní Supabase projekt.

Níže najdete, co přesně se mění, jak zjistit, zda se to týká právě vaší aplikace, a co zkontrolovat ještě před termínem. Pokud řešíte aplikaci z AI nástroje i v širším smyslu, začněte naším checklistem první pomoci pro vibe-coded weby. Proč AI nástroj nemusí znát změnu, která přišla po jeho tréninku, vysvětluje článek Co je LLM a co AI opravdu neumí. Když aplikace z AI hází chyby a nechcete ji opravovat naslepo, podívejte se na službu oprava webů po AI.

Co se v Supabase Data API mění 30. října 2026

Nová tabulka ve schématu public už nebude přes Data API dostupná automaticky, přístup jí je třeba přidělit explicitním příkazem GRANT.

Data API je vrstva, přes kterou aplikace čte a zapisuje data: automaticky generované REST a GraphQL rozhraní, které volá knihovna supabase-js. Dosud platilo, že každá nová tabulka ve schématu public dostala při vytvoření oprávnění ke čtení, vkládání, úpravě i mazání pro role anon, authenticated a service_role. Tabulka byla přes API dostupná v okamžiku, kdy vznikla. Supabase to v oznámení o změně v changelogu mění takto:

Krok	Dosud	Po změně
Vytvoření tabulky v public	Tabulka je přes Data API dostupná hned	Tabulka existuje, ale Data API ji nevidí
Přístup pro anon, authenticated a service_role	Automaticky přes výchozí oprávnění	Povinný explicitní příkaz GRANT
Zapnutí RLS na tabulce	Beze změny	Beze změny
Pravidla RLS (policies)	Beze změny	Beze změny

Změna přichází ve třech krocích. Od 28. dubna 2026 šlo nové chování zapnout při zakládání projektu. Od 30. května 2026 je výchozí pro všechny nové projekty. Od 30. října 2026 se uplatní na všechny stávající projekty. Podle plánu v oznámení měl Supabase vlastníkům a správcům aktivních projektů poslat upozornění 23. září a poslední připomenutí 23. října. Self-hosted instalace Supabase podle oznámení zasaženy nejsou.

Pokud tabulce přístup chybí, API vrátí chybu s kódem 42501 a zprávou „permission denied for table“, přičemž v poli hint přímo napíše, které roli chybí jaké oprávnění a jaký příkaz to opraví. Supabase změnu zdůvodňuje tím, že tabulky dnes nevytváří jen člověk, ale i AI agenti, skripty a AI platformy, často bez toho, aby někdo změnu zkontroloval. Výchozí oprávnění tak zpřístupnila i tabulky, které někdo zapomněl zabezpečit.

Supabase Data API a aplikace z Lovable nebo Bolt: týká se vás to?

Týká se vás to, pokud aplikace čte tabulky přes Data API a do projektu ještě přibudou nové tabulky.

Supabase uvádí tři situace, ve kterých je třeba jednat: aplikace čte nebo zapisuje tabulky v public přes Data API (supabase-js, jiná klientská knihovna nebo přímá volání na /rest/v1/ či /graphql/v1), migrace vytvářejí tabulky bez příkazů GRANT, nebo AI nástroj či skript vytváří tabulky a očekává, že budou dostupné hned. Naopak pokud aplikace s databází mluví jen přes přímé připojení k Postgresu (connection string, ORM, vlastní server), změna se jí netýká.

U AI builderů rozhoduje, kde data skutečně běží. Lovable podle své dokumentace k napojení Supabase u připojeného vlastního projektu sám navrhuje schéma, po vašem schválení spouští migrace a ukládá je do složky supabase/migrations/ v kódu. Ve výchozím stavu však používá vlastní vestavěný backend Lovable Cloud, postavený na open-source základu Supabase a spravovaný Lovable. Bolt podle nápovědy k integraci Supabase zakládá nové projekty s vlastní databází Bolt a Supabase nabízí jako alternativu v plánech Pro a Teams.

Vaše situace	Zasáhne vás změna?	Co udělat
Lovable nebo Bolt napojený na váš vlastní Supabase projekt	Ano, pokud aplikace používá Data API	Zkontrolovat migrace a nové tabulky podle postupu níže
Vlastní aplikace na Supabase se supabase-js	Ano	Doplnit GRANT do každé migrace, která vytváří tabulku
Lovable Cloud nebo databáze Bolt	Oznámení Supabase tyto spravované backendy nezmiňuje	Ověřit v dokumentaci nebo changelogu daného nástroje
Přímé připojení k Postgresu přes connection string	Ne	Nic
Self-hosted Supabase	Ne	Nic

Pokud vám od Supabase přišel e-mail o „affected projects“, neznamená to, že aplikace 30. října spadne. Správce projektu Supabase v diskusi ke změně na GitHubu vysvětlil, že počet dotčených projektů se vztahuje ke změně z 30. října, kdy nové tabulky ve stávajících projektech začnou vyžadovat explicitní oprávnění. Stávající tabulky podle něj zasaženy nebudou. Rozhodnout se tedy je třeba podle toho, zda do projektu ještě budete přidávat funkce.

Granty a RLS: dvě vrstvy, které se nesmí zaměnit

GRANT rozhoduje, zda se role k tabulce vůbec dostane, RLS rozhoduje, které řádky uvidí. Potřebujete obojí.

Supabase to v návodu Securing your API popisuje jako dvě vrstvy kontroly přístupu. Granty určují, které role se k tabulce, pohledu nebo funkci přes Data API dostanou. Row Level Security (RLS) určuje, které řádky tyto role mohou číst nebo měnit. Změna z 30. října se týká jen první vrstvy. RLS funguje dál stejně.

Při opravě této chyby hrozí jiný problém. Chybu „permission denied“ lze umlčet jedním hromadným příkazem, který přidělí přístup ke všem tabulkám najednou. Pokud však tabulka nemá zapnuté RLS, podle dokumentace Supabase ji může číst i měnit každá role s oprávněním, tedy i role anon, pod kterou chodí nepřihlášení návštěvníci. RLS je ve výchozím stavu zapnuté u tabulek vytvořených v Dashboardu. Tabulky ze SQL editoru nebo z jiného nástroje ho potřebují zapnout výslovně.

Supabase proto doporučuje brát tři kroky jako jeden celek: přidělení oprávnění, zapnutí RLS a pravidla, kdo vidí které řádky. Oprávnění lze přidělit po rolích, takže anonymní návštěvník může tabulku jen číst a přihlášený uživatel i upravovat. Pokud tyto kroky rozdělíte a uděláte jen první, chybu sice opravíte, ale data otevřete i nepřihlášeným návštěvníkům.

Co zkontrolovat před 30. říjnem: postup v 6 krocích

Kontrolu udělejte před termínem, ne až když nová funkce v ostrém provozu vrátí prázdnou obrazovku.

1. Zjistěte, zda aplikace používá Data API. Hledejte v kódu knihovnu supabase-js nebo volání na /rest/v1/. Pokud aplikace mluví s databází jen přes connection string, můžete skončit.
2. Podívejte se do Dashboardu. Supabase uvádí, že tabulky dostupné přes Data API ukazuje odznak v Table Editoru a nastavení Data API, a Security Advisor do 30. října označuje dotčené tabulky i s SQL příkazem k nápravě.
3. Projděte migrace. V projektu z Lovable je najdete ve složce supabase/migrations/. Každý příkaz create table ve schématu public by měl mít vedle sebe příkazy grant, zapnutí RLS a pravidla.
4. Doplňte oprávnění jen tam, kde je aplikace opravdu potřebuje. Pro každou roli zvlášť a vždy spolu se zapnutým RLS. Tabulky, které přes API dostupné být nemají, nechte bez přístupu.
5. Vyzkoušejte nové chování na kopii. Supabase zveřejnil příkazy, kterými lze změnu zapnout na stávajícím projektu už dnes, i příkazy pro návrat zpět. Spusťte je nejprve na testovacím projektu, ne na ostré aplikaci.
6. Upravte instrukce pro AI nástroj. Supabase doporučuje doplnit krok s oprávněními do systémového promptu nástroje, který vytváří tabulky, nebo použít Supabase agent skill, který tento krok obsahuje.

Takto vypadá jádro příkladu, který Supabase uvádí pro novou tabulku. Za ním následují pravidla RLS pro konkrétní řádky:

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;

Projekt založený po 30. květnu 2026 už nové chování má, takže pokud do něj nahrajete staré migrace bez příkazů GRANT, například při zakládání testovací kopie, tabulky v něm přes API dostupné nebudou. Pro lokální vývoj přidalo Supabase CLI dočasné nastavení auto_expose_new_tables, které má podle správce projektu zmizet 30. října 2026. Trvalým řešením jsou jen příkazy GRANT přímo v migracích.

Kde se to v praxi rozbije a jak to řešíme

Největší riziko přináší první nová funkce po termínu, kterou nikdo neotestuje na reálných datech.

Modelový scénář vypadá takto: firma si přes AI builder postaví interní nástroj nebo klientský portál, ten měsíce funguje a v listopadu si nechá doplnit novou sekci. AI nástroj vytvoří tabulku, aplikace ji však nevidí a sekce zůstane prázdná nebo hlásí chybu. Když tentýž nástroj chybu „opraví“ hromadným přidělením přístupu bez RLS, problém se přesune z viditelné chyby na tichý únik dat. Druhé místo, kde se to láme, je testovací kopie nebo nový projekt naplněný ze starých migrací, který se chová jinak než ostrá aplikace.

Pro firmy, které si takovou aplikaci nechaly postavit externě, je rozhodující, kdo po 30. říjnu přidává tabulky a zda o této změně ví. Pokud je to AI nástroj bez upravených instrukcí nebo dodavatel, který projekt už nespravuje, kontrolu je lepší udělat teď. Pokud aplikaci dáváte zákazníkům na Slovensku, přečtěte si i to, co pro software znamená nový slovenský zákon o odpovědnosti za vadný výrobek. Princip testování na kopii před zásahem do ostrého provozu je stejný jako u aktualizací WordPressu přes staging a rollback.

Jak to řešíme v Denvě: při opravě webů po AI začínáme technickým auditem a z nálezů děláme plán s pevnou cenou ještě před začátkem práce. Před prvním zásahem uděláme zálohu a pracujeme na vývojové kopii, aby živá aplikace běžela dál, a naostro přepínáme až po ověření. Supabase patří mezi technologie, se kterými při opravách AI webů běžně pracujeme.

Kdy to zvládnete sami a kdy s námi

Zvládnete sami, pokud:

• aplikace mluví s databází jen přes přímé připojení, ne přes Data API,
• do projektu už žádné nové tabulky nepřidáváte,
• rozumíte migracím a umíte si změnu vyzkoušet na testovacím projektu.

Vyplatí se přizvat nás, pokud:

• Security Advisor hlásí tabulky bez RLS nebo nevíte, které tabulky jsou přes API veřejné,
• aplikace pracuje s osobními údaji zákazníků a chyba v oprávněních by je otevřela,
• kód psal AI nástroj nebo bývalý dodavatel a nikdo neví, jak jsou migrace poskládané.

Závěr: co rozhodnout do 30. října

Pokud vaše aplikace nepoužívá Data API nebo do ní už nic nepřibude, můžete změnu jen zaznamenat a pokračovat. Pokud ji dál rozvíjíte přes AI nástroj, do konce října udělejte dvě věci: zkontrolujte, zda migrace obsahují příkazy GRANT spolu s RLS, a doplňte tento krok do instrukcí nástroje. Pokud nevíte, které tabulky jsou dnes přes API veřejné, začněte tím, protože to je otázka bezpečnosti i bez jakékoli změny na straně Supabase.

FAQ

Časté otázky.

Přestane mi 30. října 2026 fungovat stávající aplikace na Supabase?

Sama od sebe ne. Podle Supabase si stávající tabulky ponechají dosavadní oprávnění a zůstanou přes Data API dostupné. Změna se týká tabulek vytvořených po 30. říjnu, které bez příkazu GRANT aplikace neuvidí.

Jak zjistím, zda moje aplikace používá Supabase Data API?

Používá ho, pokud v kódu najdete knihovnu supabase-js nebo volání na adresy /rest/v1/ či /graphql/v1. Aplikace, která se k databázi připojuje jen přes connection string, ORM nebo vlastní server, změnou zasažena není.

Týká se změna i Lovable Cloud nebo databáze Bolt?

Oznámení Supabase tyto spravované backendy nezmiňuje, proto si to ověřte v dokumentaci daného nástroje. Přímo se změna týká vlastního Supabase projektu, který jste k Lovable nebo Bolt připojili. Lovable Cloud je postavený na open-source základu Supabase, ale spravuje ho Lovable.

Stačí chybu permission denied opravit příkazem GRANT pro všechny tabulky?

Chybu to odstraní, ale může to otevřít data. Pokud tabulka nemá zapnuté RLS, přístup k ní dostane každá role s oprávněním, i anonymní návštěvník. Přidělte oprávnění jen tabulkám, které aplikace potřebuje, po rolích a vždy se zapnutým RLS a pravidly.

Mohu nové chování zapnout dřív a otestovat ho?

Ano. Supabase zveřejnil příkazy pro SQL editor, které změnu zapnou na stávajícím projektu už teď, i příkazy pro návrat zpět. Vyzkoušejte je nejprve na testovacím projektu, potom doplňte příkazy GRANT do migrací a teprve nakonec je spusťte na ostré aplikaci.