Construindo um SaaS do zero, parte 2: como estruturar o banco de dados no Supabase
Segunda parte da série Construindo um SaaS do zero: como estruturar o banco de dados no Supabase, com tabelas, relações e os erros mais comuns de quem está começando.
Sumário do artigo
- Por que começar pelo banco, e não pela tela
- O que é uma tabela, em termos simples
- Passo 1: liste as "coisas" do seu produto
- Passo 2: defina as relações entre as tabelas
- Passo 3: monte as tabelas no Supabase
- Passo 4: pense em quem pode ver o quê
- Erros comuns de quem está começando
- Como isso conversa com o Lovable
- O que vem na parte 3
Na parte 1 desta série, você validou se a sua ideia de SaaS merece ser construída. Se você chegou até aqui, é porque os sinais foram bons — pessoas reais, com um problema real, dispostas a pagar por uma solução.
Agora vem a primeira decisão técnica de verdade: como guardar os dados do seu produto. Antes de desenhar uma tela, antes de escrever um prompt no Lovable, o banco de dados é o que decide se o seu SaaS vai crescer com facilidade ou vai travar em cada funcionalidade nova. Errar aqui não é fatal, mas conserta com dor. Acertar aqui é invisível para o usuário e decisivo para você.
Esta é a parte 2 da série Construindo um SaaS do zero. Hoje: como estruturar o banco de dados do seu SaaS no Supabase, pensando em tabelas, relações e no que vai em cada uma.
Por que começar pelo banco, e não pela tela
É tentador abrir o Lovable e pedir logo a interface — afinal, é o que você vê primeiro. Mas toda tela existe pra mostrar ou coletar algum dado, e se o dado não está bem organizado por trás, a tela vira remendo.
Pense assim: a interface muda o tempo todo, conforme você testa, ajusta e aprende com os usuários. O banco de dados muda pouco, e mudar depois de ter usuários reais é caro. Decidir bem agora economiza retrabalho depois.
O que é uma tabela, em termos simples
Se você nunca trabalhou com banco de dados, pense numa tabela como uma planilha organizada. Cada linha é um registro (um cliente, um pedido, uma tarefa). Cada coluna é uma informação sobre aquele registro (nome, e-mail, data).
A diferença entre uma planilha comum e um banco de dados de verdade é que as tabelas se conectam entre si. Um pedido pertence a um cliente. Uma tarefa pertence a um projeto. Essa conexão entre tabelas é chamada de relação, e é o que dá poder ao banco de dados — sem ela, você teria que repetir informação em todo lugar.
O que é o Supabase de novo? É uma plataforma que te dá um banco de dados PostgreSQL completo, com autenticação de usuários e armazenamento de arquivos, sem você precisar configurar servidor nenhum. É o backend que o Lovable usa nativamente quando você pede pra salvar dados ou criar login.
Passo 1: liste as "coisas" do seu produto
Antes de pensar em colunas, pense em substantivos. Quais são as principais "coisas" que o seu SaaS precisa guardar?
Para o exemplo da nutricionista da parte 1 (ferramenta que gera plano alimentar com a marca dela), as coisas seriam: usuária (a nutricionista), paciente (cliente da nutricionista), plano alimentar, e refeição (cada item dentro de um plano).
Cada uma dessas "coisas" tende a virar uma tabela. Não se preocupe em acertar de primeira — é normal ajustar essa lista conforme você entende melhor o produto.
Passo 2: defina as relações entre as tabelas
Com a lista de tabelas em mãos, pergunte: como elas se conectam?
No nosso exemplo:
Uma usuária tem vários pacientes
Um paciente tem vários planos alimentares
Um plano alimentar tem várias refeições
Esse padrão — "um tem vários" — é o mais comum em SaaS e é chamado de relação um-para-muitos. Uma nutricionista, muitos pacientes. Um paciente, muitos planos.
Tabela | Pertence a | Tipo de relação |
|---|---|---|
pacientes | usuárias | um-para-muitos |
planos_alimentares | pacientes | um-para-muitos |
refeicoes | planos_alimentares | um-para-muitos |
Passo 3: monte as tabelas no Supabase
Com a estrutura clara, é hora de criar de verdade. No painel do Supabase, você pode criar tabelas visualmente ou usar SQL diretamente no SQL Editor. Para quem está começando, o SQL parece assustador, mas seguir um modelo pronto resolve:
create table pacientes (
id uuid primary key default gen_random_uuid(),
usuaria_id uuid references auth.users(id),
nome text not null,
email text,
criado_em timestamp default now()
);
create table planos_alimentares (
id uuid primary key default gen_random_uuid(),
paciente_id uuid references pacientes(id) on delete cascade,
nome text not null,
objetivo text,
criado_em timestamp default now()
);
create table refeicoes (
id uuid primary key default gen_random_uuid(),
plano_id uuid references planos_alimentares(id) on delete cascade,
horario text,
descricao text not null,
calorias int
);
Repare no padrão: cada tabela tem um id único, e as tabelas "filhas" têm uma coluna que aponta pro id da tabela "mãe" (paciente_id, plano_id). É essa coluna que cria a relação.
O que significa
references? É a forma de dizer "esse valor precisa existir na outra tabela". Um plano alimentar só pode ter umpaciente_idque realmente existe na tabela de pacientes — o banco impede dado órfão.
O que significa
on delete cascade? Se você apagar um paciente, todos os planos dele são apagados automaticamente junto — em vez de ficarem soltos no banco sem dono.
Passo 4: pense em quem pode ver o quê
Um erro comum de quem está começando: esquecer que, num SaaS com vários usuários, cada um só deve enxergar os próprios dados. Sem isso, em teoria, uma nutricionista poderia ver os pacientes de outra.
O Supabase resolve isso com o Row Level Security (RLS) — uma regra que filtra automaticamente o que cada usuário consegue acessar:
alter table pacientes enable row level security;
create policy "usuária vê só os próprios pacientes"
on pacientes for all
using (auth.uid() = usuaria_id);
Ative o RLS em toda tabela que guarda dado de usuário, desde o início. Adicionar depois, com dados reais no ar, é mais arriscado do que configurar certo desde o primeiro dia.
Erros comuns de quem está começando
Erro | Por que atrapalha |
|---|---|
Guardar tudo numa tabela só | Dificulta relação e gera dado repetido |
Esquecer o RLS | Um usuário pode acessar dado de outro |
Não usar | Deixa registros órfãos quando algo é apagado |
Nomear tabelas de forma vaga ( | Confunde você mesmo daqui a três meses |
Criar tabela nova pra cada funcionalidade sem pensar na relação | Banco vira uma colcha de retalhos difícil de consultar |