Supabase muda Data API: grants explícitos obrigatórios em 30 maio
Supabase torna padrão o opt-out da exposição automática da Data API em 30 de maio de 2026. Tabelas sem grants PostgreSQL explícitos deixam de ser acessíveis via PostgREST.
Por Vitor Morais
Fundador do MochaLabz ·
A Supabase anunciou em maio de 2026 uma mudança no comportamento padrão da Data API: a partir de 28 de abril, novos projetos já podem optar por não expor automaticamente tabelas do schema público via PostgREST ou GraphQL — e em 30 de maio esse comportamento se torna padrão para todos os novos projetos. O changelog oficial confirma que "new Supabase projects can opt out of automatic Data API exposure for public schema tables", com grants PostgreSQL explícitos agora necessários para tornar uma tabela alcançável.
O que mudou e por que importa
Até agora, qualquer tabela criada no schema public de um projeto Supabase ficava automaticamente exposta via PostgREST — a camada REST que transforma o banco em API HTTP. Isso funcionava bem para prototipagem rápida, mas abria superfície de ataque desnecessária em projetos com tabelas internas que nunca deveriam ser acessadas pelo cliente.
Com o novo padrão, a exposição passa a ser opt-in por tabela: é necessário conceder grants PostgreSQL explícitos (GRANT SELECT, INSERT, UPDATE, DELETE) para o role anon ou authenticated antes que PostgREST ou o endpoint GraphQL consiga alcançar a tabela. Projetos sem esses grants simplesmente retornam erro 404 ou resposta vazia nas queries.
- Tabelas novas sem
GRANTexplícito ficam invisíveis para o PostgREST após 30 de maio. - Projetos criados antes de 28 de abril não são afetados automaticamente — a mudança vale para novos projetos.
- A opção de opt-out já está disponível no dashboard desde 28 de abril para quem quiser testar antes do prazo.
- GraphQL (via pg_graphql) segue as mesmas regras de grant que o PostgREST.
Impacto prático: quem precisa agir antes de 30 de maio
Quem já tem projetos rodando em produção não sofre breaking change automático — as regras mudam apenas para projetos criados a partir do novo padrão. O risco real está em dois cenários: criar um projeto novo após 30 de maio esperando o comportamento antigo, ou clonar/recriar um banco sem replicar os grants do ambiente original.
Para quem usa Supabase em stack com migrations versionadas (via supabase db push ou Prisma), o passo mais seguro é incluir os grants diretamente nas migrations — assim o comportamento fica explícito e rastreável no repositório, independente do projeto ser novo ou antigo.
- Novo projeto após 30 mai: adicionar
GRANT SELECT ON tabela TO anon;(leitura pública) ouTO authenticated;(requer JWT) para cada tabela que o cliente precisa acessar. - Staging/clone de produção: verificar se o dump inclui os grants —
pg_dumpexporta grants por padrão, mas scripts manuais frequentemente omitem. - CI/CD com seed de banco: incluir os grants no script de seed para evitar falhas silenciosas em ambientes efêmeros.
- RLS ativo: grants são necessários mesmo com Row Level Security habilitado — RLS filtra linhas, mas não substitui o grant de acesso à tabela.
Breaking change em 30 de maio para novos projetos
Qualquer projeto Supabase criado a partir de 30 de maio de 2026 não vai expor tabelas automaticamente. Uma query PostgREST sem o grant correspondente retorna erro — sem aviso de deprecation em tempo de execução. Se o seu setup de staging ou onboarding cria projetos do zero, adicione os grants explícitos nas migrations antes dessa data.
Como adicionar os grants agora
O SQL abaixo cobre o padrão mais comum: leitura pública para anon e escrita autenticada para authenticated. Adapte os verbos (INSERT, UPDATE, DELETE) conforme o que cada tabela precisa expor:
-- Leitura pública (sem login)
GRANT SELECT ON TABLE public.produtos TO anon;
-- Leitura + escrita para usuário autenticado (JWT válido)
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE public.pedidos TO authenticated;
-- Verificar grants existentes em todas as tabelas do schema público
SELECT grantee, table_name, privilege_type
FROM information_schema.role_table_grants
WHERE table_schema = 'public'
ORDER BY table_name, grantee;Para um panorama completo sobre índices e performance em queries PostgreSQL que passam por essa camada, o artigo Índices no PostgreSQL: o que muda na prática cobre os padrões que complementam a configuração de grants — especialmente útil quando a tabela exposta via PostgREST recebe volume de leitura alto.
Para ler em seguida
bcrypt vs Argon2 vs scrypt vs PBKDF2: Qual Usar para Senhas (2026)
Comparativo técnico OWASP-aligned entre bcrypt, Argon2id, scrypt e PBKDF2 para hashing de senhas em 2026. Recomendações, parâmetros corretos por hardware, exemplos em Node.js/Python/Go/PHP e estratégia de migração.
Performance SQL com Índices: Guia Completo 2026 (PostgreSQL e MySQL)
Aprenda a usar índices em SQL para acelerar queries de segundos para milissegundos. Tipos de índice (B-tree, GIN, GiST, BRIN), índices compostos, parciais, funcionais, EXPLAIN ANALYZE, anti-padrões e checklist de manutenção.
LGPD para Sites: Checklist Completo de Adequação (2026)
Guia LGPD para sites brasileiros: 30+ itens de checklist, bases legais explicadas, multas reais aplicadas pela ANPD, prioridade de implementação por fase e ferramentas recomendadas.
UUID v7 no PostgreSQL: quando migrar e ganhar 2x de performance
Guia prático: por que UUID v7 é melhor que v4, impacto real em índices B-tree, como migrar sem downtime e quando vale a pena.