Supabase muda em 30/10: tabelas novas vão precisar de GRANT. Veja se seu projeto está pronto

Se você usa Supabase, chegou (ou vai chegar) um e-mail com o assunto "new tables in public need grants from October 30". Ele parece só mais um aviso, mas pode quebrar o seu app sem que você tenha mudado uma linha de código. Resumo o que muda, quem é afetado e como conferir o seu projeto em poucos minutos.

O que muda

Até hoje, toda tabela nova criada no schema public ficava automaticamente acessível pela Data API, ou seja, pelo supabase-js, pelo PostgREST e pelo GraphQL. A partir de 30 de outubro de 2026, isso deixa de acontecer em todos os projetos existentes. Projetos novos já funcionam assim desde 30 de maio.

Na prática: depois de 30/10, uma tabela nova só aparece na API se você der um GRANT explícito para ela. Sem isso, o app recebe "permission denied".

O que NÃO muda

Tabelas que já existem mantêm as permissões atuais e continuam funcionando. E se o seu app conecta ao Postgres só por connection string (psql, ORM ou backend com conexão direta), essa mudança não te afeta.

Três pegadinhas que pouca gente vai perceber

1. Não é só tabela nova no dia a dia. A regra vale também quando o schema é recriado do zero: projeto novo, preview branch e supabase db reset local. Tudo funciona em produção, e a branch de teste quebra sem motivo aparente.

2. Ferramentas de IA geram SQL sem GRANT. Lovable, Bolt, Cursor e afins costumam criar tabelas sem essa linha. Se você faz vibe coding com Supabase, inclua no seu prompt a instrução de sempre gerar o GRANT junto com o CREATE TABLE.

3. GRANT não substitui RLS. O GRANT decide se a API enxerga a tabela; o Row Level Security decide quais linhas cada usuário pode ver. Dar GRANT para anon numa tabela sem RLS ativo é expor a tabela inteira para qualquer pessoa com a chave pública. Ative o RLS antes de liberar o acesso.

Como conferir seu projeto agora

Rode esta consulta no SQL Editor. Ela só lê, não altera nada:

select c.relname as tabela,
  c.relrowsecurity as rls_ativo,
  has_table_privilege('anon', c.oid, 'SELECT') as anon_le,
  has_table_privilege('authenticated', c.oid, 'SELECT') as autenticado_le,
  has_table_privilege('service_role', c.oid, 'SELECT') as service_role_le
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind in ('r','p')
order by 1;

Dois sinais de alerta no resultado:

- anon_le = true com rls_ativo = false: tabela aberta para o mundo, corrija já, independente do dia 30.

- uma tabela que seu app usa pela API aparecendo com tudo false: ela vai falhar (ou já está falhando).

O que fazer daqui pra frente

Toda migration que cria tabela passa a ter três partes: o CREATE TABLE, o ALTER TABLE ... ENABLE ROW LEVEL SECURITY e o GRANT apenas para os papéis que realmente precisam de acesso. Libere só o necessário: uma tabela que só o backend usa não precisa de GRANT para anon nem para authenticated.

Visto de longe, a mudança é boa: o acesso pela API deixa de ser automático e vira uma decisão explícita, que fica registrada na migration e pode ser revisada em code review. Só não deixe para descobrir no dia 31.

Fonte oficial: https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically