Dez coisas para conferir em um projeto Supabase antes que ele dê problema em produção
Supabase é ótimo para tirar um produto do papel. Em um fim de semana você tem banco, autenticação e API. O risco aparece depois: o projeto cresce, ninguém volta para olhar a base, e os problemas chegam todos juntos.
Montei uma lista de dez verificações para projetos que já atendem gente de verdade. Todas dão para fazer sozinho, e os comandos SQL são só de leitura. Rode no editor SQL do painel.
1. Toda tabela exposta tem RLS ligada
Tabela no schema public sem RLS fica aberta para qualquer um que tenha a chave pública da API. E a chave pública, como o nome diz, está no seu front-end.
select schemaname, tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;
O resultado ideal é vazio. O painel também mostra isso nos avisos de segurança.
2. As políticas não rodam a função de usuário linha por linha
Este é o motivo mais comum de consulta que piora conforme a tabela cresce. Uma política escrita assim:
using (auth.uid() = user_id)
chama auth.uid() para cada linha. Escrita assim:
using ((select auth.uid()) = user_id)
a função roda uma vez e o resultado é reaproveitado. Junto com um índice em user_id, a diferença em tabela grande é enorme.
Para achar as políticas que ainda estão no primeiro formato:
select schemaname, tablename, policyname, qual
from pg_policies
where qual like '%auth.uid()%'
and qual not like '%select auth.uid()%';
3. A chave service_role não está no front-end nem no repositório
Essa chave ignora a RLS. Vale procurar em três lugares: no código do front-end, nas variáveis públicas do build e no histórico do git, não só na versão atual.
Se achar, trocar a chave no painel. Apagar o arquivo não resolve, porque ela continua no histórico.
4. A aplicação conecta pelo pooler quando roda em serverless
Cada instância de função serverless abre as próprias conexões. Em horário de pico, o número de instâncias sobe e o banco esgota.
select count(*) as conexoes_abertas from pg_stat_activity;
show max_connections;
Se os dois números andam próximos, confira se a aplicação usa a string de conexão do pooler e qual é o tamanho do pool.
5. As consultas mais lentas são conhecidas
select calls,
round(mean_exec_time::numeric, 1) as media_ms,
left(query, 120) as consulta
from pg_stat_statements
order by total_exec_time desc
limit 10;
Quase sempre uma ou duas consultas respondem pela maior parte do tempo. O painel mostra o mesmo em Query Performance e sugere índices. Vale olhar isso antes de aumentar o compute, porque o custo do compute maior fica para sempre.
6. O backup já foi restaurado alguma vez
Backup que nunca foi restaurado é uma suposição. O teste responde duas perguntas: ele volta, e em quanto tempo.
Faça em um projeto separado, nunca em cima da produção. Depois confira a contagem de linhas das tabelas principais e anote o tempo que levou.
7. Os arquivos do Storage têm cópia separada
O backup do banco não inclui os arquivos enviados ao Storage. Se o seu produto guarda documento, foto ou anexo de usuário, isso precisa de uma cópia própria, em outro lugar.
8. Disco, CPU e memória são acompanhados antes do limite
select pg_size_pretty(pg_database_size(current_database())) as tamanho_do_banco;
Os relatórios do painel mostram o uso ao longo do tempo. O que importa não é o número de hoje, é a inclinação da curva.
9. A fatura é olhada por projeto
Cada projeto paga o próprio compute, mesmo parado. Projeto de teste esquecido cobra todo mês. Vale conferir também o tráfego de saída e o que o teto de gasto cobre e não cobre.
10. O e-mail de autenticação usa SMTP próprio
O SMTP padrão do Supabase serve para teste. Em produção, cadastro e recuperação de senha dependem dele, então configure o seu e confira os limites de envio.
Por onde começar
Se o tempo é curto, eu começaria por três: RLS ligada (item 1), chave service_role (item 3) e backup restaurado (item 6). São os que doem mais quando falham.
A lista completa, com uma versão equivalente para AWS, está em um repositório aberto. Pode copiar, adaptar e usar na sua empresa:
https://github.com/dradecaike/checklist-infra-aws-supabase
Se você conferir no seu projeto e achar algo que eu deixei de fora, comenta aqui que eu acrescento.
Eu sou o Caike e cuido de ambientes em Supabase e AWS pela Kami.