O que é o Supabase e como ter seu próprio banco de dados gerenciado na ArduMaker

Publicado em 2026-09-12 por frfrand

Postgres con API automática, autenticación y almacenamiento encima. Qué resuelve de verdad, qué significa que sea open source, y cuándo conviene armarlo vos mismo.

Supabase se apresenta como "a alternativa open source ao Firebase". A descrição é útil para situá-lo e esconde o mais interessante: por baixo é PostgreSQL puro.

Não é um mecanismo próprio com um dialeto raro. É o Postgres, com uma série de peças ao redor que resolvem o que normalmente se escreve à mão.

O que realmente tem dentro

PostgREST. Lê o esquema do seu banco e gera uma API REST automaticamente. Cria uma tabela e já tem endpoints para consultá-la, filtrá-la, ordená-la e paginá-la. Sem escrever um controlador.

GoTrue. Autenticação: registro, login, recuperação de senha, provedores externos, tokens.

Realtime. Escuta as mudanças do banco e as transmite por WebSocket. Sua interface se atualiza quando alguém modifica uma linha, sem que você programe nada para isso.

Storage. Arquivos, com permissões baseadas nas mesmas regras do banco.

Edge functions. Código do lado do servidor para o que não cabe em uma consulta.

A peça que faz funcionar: segurança em nível de linha

Isso é o que mais surpreende e o que mais importa entender.

Se você expõe seu banco diretamente como API, a pergunta óbvia é: o que impede que um usuário consulte os dados de outro?

A resposta não está na API. Está no Postgres, com uma função que existe há anos e quase ninguém usava: segurança em nível de linha. Escrevem-se políticas que dizem quais linhas cada usuário pode ver ou modificar, e o mecanismo do banco as aplica.

create policy "cada um vê o seu" on pedidos for select using (auth.uid() = usuario_id);

A consequência: não importa por onde a consulta entre, a regra é cumprida. A segurança deixa de depender de que cada endpoint se lembre de filtrar.

É também onde se cometem os erros. Uma tabela sem políticas ativas, exposta pela API, é pública. Vale revisar tabela por tabela antes de publicar.

O que significa ser open source

Todas as peças são projetos abertos e podem ser executadas no seu próprio servidor. Isso muda duas coisas:

Não há encerro. Seus dados estão em um Postgres padrão. Se amanhã quiser mudar, é um despejo e uma restauração. Comparado com plataformas onde exportar significa reescrever o aplicativo, a diferença é enorme.

Você pode autoalojar. Com Docker Compose, no seu VPS. Ganha controle e custo fixo; perde a parte gerenciada.

Quando convém, e quando não

Convém para protótipos e produtos onde a maior parte do backend é CRUD com permissões. Economiza semanas.

Não convém quando a lógica de negócios é complexa: se cada operação envolve várias validações, chamadas externas e regras, você termina brigando com a API gerada. Aí um backend próprio é mais simples.

Um caminho intermediário que funciona bem: Supabase (ou simplesmente Postgres) para os dados, e seu próprio backend para as operações com regras, sem expor essas tabelas pela API automática.

A versão sem camadas

Vale dizer: para muitos projetos, o Postgres sozinho é suficiente. Se você já tem um backend, o que o Supabase adiciona é, em grande parte, o que seu backend já faz.

Na ArduMaker você pode subir o Postgres no seu VPS pelo painel, com seu usuário, seus backups e acesso por túnel em vez de porta aberta. E se quiser o pacote completo, o Supabase auto-hospedado roda com Docker no mesmo VPS. Nos dois casos, a base é sua e os dados não saem da sua infraestrutura.