Por 
Supabase é uma plataforma de backend construída em torno de PostgreSQL. Cada projeto recebe um banco Postgres completo e pode combinar autenticação, armazenamento, realtime e funções server-side.
O que você recebe
O banco é a base do projeto. A plataforma também oferece Auth, Storage, Realtime e Edge Functions, permitindo montar boa parte do backend sem começar toda a infraestrutura do zero.
Autenticação
Supabase Auth suporta fluxos como senha, magic link, OTP e provedores sociais. A autorização pode ser combinada com Row Level Security no Postgres para controlar quais linhas cada usuário pode acessar.
Quando faz sentido
É interessante para protótipos, SaaS, aplicações web e projetos que se beneficiam de Postgres e de serviços integrados. Ainda assim, você precisa entender modelagem, permissões, backups e limites do plano.
Cuidado com a facilidade inicial
Criar uma tabela rapidamente não elimina decisões de segurança. Revise RLS, chaves, segredos, políticas de acesso e como cada ambiente será separado. Autenticação confirma quem entra; autorização decide quais dados essa pessoa pode acessar. Habilite RLS nas tabelas expostas pela API e teste as políticas com usuários diferentes.
Chaves publicáveis podem estar no cliente quando as permissões estão corretas. Chaves secretas e a chave legada service_role têm privilégios elevados e devem ficar somente no backend. Não coloque esses valores em código entregue ao navegador.
Antes de trabalhar com dados reais, veja cuidados com banco de dados em produção.
Um primeiro projeto simples
Uma boa prática é começar com uma lista de tarefas com login. Isso permite aprender tabela, autenticação, políticas e leitura/escrita sem um domínio complexo.
Primeiro projeto: tarefas privadas por usuário
Use um projeto de estudo com dados fictícios. O objetivo é que cada pessoa veja apenas suas próprias tarefas, em vez de criar uma lista compartilhada por acidente.
- Crie o projeto e configure o método de login escolhido no Auth.
- Modele uma tabela de tarefas com identificador, título e identificador do proprietário.
- Habilite RLS na tabela exposta e revise os privilégios dos papéis que acessam a API.
- Crie políticas para as operações necessárias, relacionando o proprietário à identidade autenticada. Uma política de leitura não libera automaticamente criação, atualização ou exclusão.
- Conecte o cliente usando uma chave publicável e a sessão do usuário.
- Teste pelo mesmo caminho que a aplicação usa, com duas contas distintas e uma sessão sem login.
Como saber se as permissões funcionam
| Teste | Resultado esperado neste projeto |
|---|---|
| Conta A cria uma tarefa própria | Operação aceita conforme a política |
| Conta B tenta ler a tarefa de A | Nenhum dado privado de A é exposto |
| Conta B tenta alterar a tarefa de A | Alteração recusada ou sem linhas afetadas |
| Sessão sem login tenta acessar tarefas | Dados privados indisponíveis |
| Cliente tenta criar uma tarefa para outro usuário | Operação recusada pela política |
Não use uma conexão administrativa ou chave privilegiada para provar que a política funciona: esse acesso pode contornar RLS. Revise também concessões de privilégios; autenticação, grants e políticas cumprem funções diferentes.
Antes de levar o exemplo para produção, confira limites atuais de banco, armazenamento, tráfego, funções e recursos de backup do seu plano. A existência de um plano gratuito não garante capacidade ilimitada nem a estratégia de recuperação necessária ao seu sistema.
Fontes oficiais
Referências desta revisão
Documentação consultada em 13/10/2026; recursos e condições podem mudar.
