Software · Desenvolvimento Web & Stacks

Supabase e Backend as a Service: Postgres como Plataforma Completa

Como o Supabase transforma o PostgreSQL em uma plataforma completa de desenvolvimento: segurança na linha (RLS), eventos em tempo real, armazenamento e quando migrar para backend próprio.

Diagrama conceitual ilustrando supabase e backend as a service: postgres como plataforma completa

Historicamente, plataformas do tipo Backend as a Service (BaaS) como o Firebase popularizaram o desenvolvimento acelerado de aplicações, mas ao custo de impor bancos proprietários baseados em documentos NoSQL e aprisionamento tecnológico (vendor lock-in).

O Supabase adota uma abordagem oposta e fundamentada em padrões abertos: em vez de esconder o banco de dados atrás de abstrações fechadas, ele coloca o PostgreSQL no centro da arquitetura, expondo toda a robustez do ecossistema relacional através de APIs seguras.

flowchart TD
    ClientApp["Aplicação Web / Mobile"] --> Gateway["Kong API Gateway"]
    
    subgraph SupabaseServices["Serviços Supabase"]
        Gateway --> GoTrue["Auth (Autenticação JWT / OAuth)"]
        Gateway --> PostgREST["PostgREST (Gera REST automaticamente sobre o Postgres)"]
        Gateway --> Realtime["Realtime Engine (Elixir WebSocket sobre WAL)"]
        Gateway --> Storage["Storage (Buckets S3 com políticas no banco)"]
    end
    
    SupabaseServices --> Postgres["PostgreSQL Central com Row Level Security (RLS)"]

O Coração da Segurança: Row Level Security (RLS)

No modelo tradicional, o controle de acesso de quem pode ler ou alterar um registro reside no código do backend (nos controllers ou middlewares). No Supabase, o cliente web conecta-se diretamente ao banco de dados via API REST gerada pelo PostgREST, e a segurança é garantida no próprio kernel do PostgreSQL através de políticas de Row Level Security (RLS):

-- Habilita a política de isolamento na tabela de pedidos
ALTER TABLE pedidos ENABLE ROW LEVEL SECURITY;

-- Usuários só podem visualizar os pedidos que pertencem ao seu próprio ID
CREATE POLICY "Pedidos visiveis apenas pelo proprietario"
ON pedidos FOR SELECT
USING (auth.uid() = usuario_id);

Como as políticas são avaliadas pelo próprio banco em cada comando SELECT, UPDATE ou DELETE, torna-se matematicamente impossível um usuário vazar dados de outro tenant, permitindo lançar produtos no mercado em dias sem abrir mão da segurança.

Explorar este tema no Grafo de Conhecimento