Como aprendi Supabase construindo produto próprio
Em 2023 precisava de banco, autenticação e storage sem operar infraestrutura. Supabase resolveu em um dia o que teria levado uma semana com stack própria.
Em 2023 precisava de banco de dados, autenticação, e storage para o MEXP.
Tinha duas opções: montar a stack eu mesmo (PostgreSQL no EC2, Auth customizado, S3 para files), ou usar serviço gerenciado que abstraísse tudo isso.
Escolhi Supabase. Não porque estava na moda — porque precisava de velocidade e confiança, e operar PostgreSQL + auth + storage por conta própria adicionava responsabilidade operacional que eu não queria na fase de construção de produto.
O que o Supabase dá:
PostgreSQL hospedado com acesso direto (não ORM proprietário, SQL real). Autenticação com múltiplos providers (email, OAuth). Storage de arquivos. Realtime subscriptions. Edge Functions. API gerada automaticamente via PostgREST.
O mais útil para mim: PostgreSQL real com acesso direto via pooler. Não é proprietary database — é Postgres com a conveniência de não operar.
O que me surpreendeu bem:
Row Level Security (RLS). Você define políticas de acesso diretamente no banco, em SQL:
-- Usuário só vê seus próprios leads
CREATE POLICY "users_own_leads" ON leads
FOR ALL
USING (auth.uid() = user_id);
Quando a API chama o banco com o token do usuário autenticado, o RLS garante que ele só vê os registros do próprio user_id. Sem filtro manual em cada query. A segurança está na camada de dado, não na aplicação.
Isso mudou como penso sobre multi-tenancy. Em vez de filtrar WHERE dealership_id = ? em toda query (e arriscar esquecer em alguma), você define a política uma vez e o banco garante.
O que aprendi que os tutoriais simplificam:
RLS tem custo. Para cada query, o banco avalia as políticas. Em tabelas grandes com queries complexas, isso pode ser significativo.
E migração de schema em produção com RLS ativado precisa de cuidado extra — alterações em tabelas podem invalidar políticas existentes de formas não óbvias.
Supabase é excelente para escala moderada e velocidade de desenvolvimento. Para sistemas com requisitos muito específicos de performance ou compliance, você ainda vai querer PostgreSQL próprio.
A reflexão maior:
Supabase não é substituto de entender banco de dados. É abstração de operação, não de conhecimento.
Você ainda precisa entender índices, quando usar transações, como escrever queries eficientes. A diferença é que você não precisa acordar às 3h para resolver problema de replicação ou failover — isso é problema deles.
Para produto próprio em estágio inicial, essa troca de controle por velocidade é o cálculo certo. Para sistema crítico em empresa com time de DBA — você quer controle total.
Em 2023 com MEXP: Supabase foi a escolha certa. Produto lançou mais rápido porque não passei semanas operando infra de banco.