Como funciona
São duas conexões independentes, e as duas são necessárias:
- O conector MCP dá ao agente do Lovable as ferramentas do SuperDB: ele cria tabelas, liga RLS, roda SQL e confere as políticas. Vale para o workspace inteiro do Lovable.
- O pacote
@superdb/clienté o que o app gerado usa em tempo de execução para entrar, cadastrar e ler e gravar dados.
O conector funciona em qualquer plano do Lovable, porque ele aceita servidor MCP personalizado.
Peça para não usar o Lovable Cloud nem o Supabase. Sem essa instrução o Lovable pode escolher o backend dele. O prompt do Passo 4 já traz essa frase.
Pré-requisitos
- Conta no SuperDB e um projeto criado em app.superdb.com.br
- Você logado no painel do SuperDB no mesmo navegador, porque a autorização abre uma janela do SuperDB
- Um workspace no Lovable com um projeto aberto
Passo 1: adicione o conector no Lovable
No projeto do Lovable, abra Connectors, clique no botão + e escolha MCP server. Preencha assim:
| Campo | Valor |
|---|---|
| Nome | SuperDB |
| URL | https://mcp.superdb.com.br/mcp |
| Autenticação | OAuth (já vem selecionado) |
Clique em Add & authorize. O Lovable abre uma janela do SuperDB para você autorizar o acesso.
Passo 2: autorize o projeto
A janela do SuperDB tem quatro etapas. Só na última existe o botão Autorizar.
| Etapa | O que mostra |
|---|---|
| Pedido | Quem está pedindo acesso e o destino, api.lovable.dev |
| Permissões | Ler e alterar dados e estrutura, rodar SQL (inclusive comandos que criam e apagam) e ver e criar buckets |
| Projetos | A lista dos seus projetos. Nenhum vem marcado, e dá para buscar pelo nome |
| Confirmar | O nome do projeto escolhido e o botão Autorizar |
Dica: marque só o projeto do app que o Lovable vai construir. Como a permissão inclui rodar SQL que cria e apaga, quanto menos projetos você liberar, menor o estrago possível. Confira o nome do projeto na última etapa antes de autorizar.
Nota: conclua a autorização na janela que o próprio Lovable abriu. Se você abrir o link em outra aba, o Lovable não recebe a resposta. Nesse caso, repita o Passo 1.
As ferramentas que o conector oferece estão descritas em MCP.
Passo 3: separe a anon key e o slug
O app precisa de dois valores do projeto:
- A anon key, no painel, em API Keys do projeto. Ela é pública e pode ir no código do front.
- O slug do projeto, que entra no
createClientcomoproject.
A service role nunca vai no front nem no prompt. Ela ignora a RLS. Se você colar essa chave numa conversa com o Lovable, ela passa a viver no histórico e no código gerado. A diferença entre as duas chaves está em Service vs anon.
Passo 4: cole o prompt no Lovable
Troque SEU_SLUG pelo slug do projeto e cole_aqui_a_anon_key pela anon key. O exemplo pede um app de tarefas, mas você pode trocar essa parte pela ideia do seu app e manter o resto.
Crie um app de lista de tarefas com cadastro e login por e-mail e senha.
Cada usuário vê e altera só as próprias tarefas.
IMPORTANTE: NÃO use o Lovable Cloud nem o Supabase. O backend é o SuperDB,
pelo pacote npm @superdb/client, que tem os mesmos nomes de método do
supabase-js. Não use o pacote @supabase/supabase-js.
import { createClient } from '@superdb/client'
const db = createClient('https://auth.superdb.com.br', ANON_KEY, { project: 'SEU_SLUG' })
Use db.auth.signUp, db.auth.signInWithPassword, db.auth.onAuthStateChange e
db.auth.signOut para o login, e db.from('tarefas').select, insert, update e
delete para os dados. A anon key é pública e pode ficar no front:
ANON_KEY = cole_aqui_a_anon_key
Use o conector MCP SuperDB para criar as tabelas com RLS ligada, para cada
usuário ver e alterar só as próprias linhas. A coluna do dono é
user_id uuid not null default auth.uid(), para o app não precisar mandar o
user_id ao criar. Confira as políticas com as ferramentas do MCP antes de
terminar.O supabase-js puro não funciona apontando para o SuperDB, porque o login e a sessão são nossos. O Lovable precisa usar o @superdb/client, e é por isso que o prompt diz isso com todas as letras. Os métodos do SDK estão em SDK JS.
O que o agente faz
Em um teste com o prompt acima, o agente do Lovable usou o conector para criar a tabela do app com RLS ligada e políticas de select, insert, update e delete, todas com a condição user_id = auth.uid(). Depois ele conferiu as políticas com as ferramentas do MCP, como o prompt pediu.
-- o dono vem do login: o app não precisa mandar user_id
alter table tarefas alter column user_id set default auth.uid();
alter table tarefas enable row level security;
create policy "ler as proprias" on tarefas
for select using (user_id = auth.uid());
create policy "criar as proprias" on tarefas
for insert with check (user_id = auth.uid());
create policy "alterar as proprias" on tarefas
for update using (user_id = auth.uid())
with check (user_id = auth.uid());
create policy "apagar as proprias" on tarefas
for delete using (user_id = auth.uid());O nome da tabela e das políticas muda de app para app. A ideia é a mesma: com a RLS ligada e sem política, ninguém lê nada, e com user_id = auth.uid() cada pessoa só enxerga o que é dela. Para entender isso a fundo, veja RLS explicado.
Dica: quando o agente terminar, abra o painel do SuperDB e confira as tabelas e as políticas você mesmo.
Se o conector falhar
Se você revogar o acesso no painel do SuperDB, em Conta, Aplicativos conectados, o Lovable pode continuar mostrando o conector como conectado e mesmo assim falhar com "não autorizado".
A solução é refazer a conexão: remova o conector SuperDB nos Connectors do Lovable e adicione de novo, seguindo o Passo 1 e o Passo 2.
Próximos passos
- Já tem um app no Supabase? Veja Migrar do Supabase.
- Quer saber o que cada plano inclui? Veja os preços.