Backend para Lovable: Lovable Cloud, Supabase ou SuperDB.

A resposta curta

Se você está validando uma ideia e o app vai viver dentro do Lovable, use o Lovable Cloud. Ele já vem ligado, cria tabelas e login sozinho e não pede conta em lugar nenhum. É o caminho mais curto até a primeira tela funcionando, e ninguém precisa de outra coisa nessa fase.

A conversa muda quando o app ganha usuários de verdade. Aí aparecem perguntas que o protótipo não fazia:

• De quem é o banco? No Lovable Cloud, o banco fica dentro da conta do Lovable. Num Supabase ou no SuperDB, o projeto é seu, com painel, chaves e connection string próprios.
• Quanto custa por mês, e em que moeda? O uso do Lovable Cloud sai dos créditos do plano do Lovable, que é cobrado em dólar. O Supabase também cobra em dólar. O SuperDB cobra em real.
• A empresa precisa de nota? O SuperDB emite NFS-e a cada pagamento, no CPF ou no CNPJ do cadastro, nos planos pagos.
• Onde ficam os dados? Para quem trata dado pessoal sob a LGPD, saber o país do servidor ajuda a responder o cliente e o jurídico.

Como ligar o Lovable ao SuperDB

São duas conexões, e as duas são necessárias. O conector MCP dá ao agente do Lovable as ferramentas do SuperDB: ele cria as tabelas, liga a RLS, roda SQL e confere as políticas. O pacote @superdb/client é o que o app gerado usa para cadastrar, entrar e ler e gravar dados. O conector funciona em qualquer plano do Lovable, porque ele aceita servidor MCP personalizado.

1. Crie um projeto no SuperDB e anote o slug e a anon key, que é pública e pode ir no front.
2. No Lovable, abra Connectors, adicione um MCP server com a URL https://mcp.superdb.com.br/mcp e autentique por OAuth.
3. Na janela do SuperDB, marque só o projeto do app e autorize.
4. Cole no Lovable um prompt que diga, com todas as letras, para usar o @superdb/client e não usar o Lovable Cloud nem o Supabase.

O SDK segue os nomes do supabase-js, então o código que o Lovable já sabe escrever muda pouco:

import { createClient } from '@superdb/client'

export const db = createClient(
  'https://auth.superdb.com.br',
  import.meta.env.VITE_SUPERDB_ANON_KEY,
  { project: 'meu_app' }
)

// cadastro, login e dados, com a RLS valendo
await db.auth.signInWithPassword({ email, password })
const { data } = await db.from('tarefas').select('*')

O supabase-js puro não funciona apontando para o SuperDB, porque o login e a sessão são do SuperDB. O passo a passo completo, com o prompt pronto, as telas da autorização e o que fazer se o conector falhar, está no guia do SuperDB no Lovable.

O que o Lovable costuma pedir ao backend

Antes de escolher, vale olhar o que o seu app vai precisar. A maior parte dos apps do Lovable pede quatro coisas, e as três opções cobrem todas:

• Login. No SuperDB: e-mail e senha, Google, GitHub, Apple, link mágico e MFA, e código pelo WhatsApp nos planos Pro e Escala.
• Tabelas com dono. Cada pessoa vê só o que é dela. Isso é RLS: uma política user_id = auth.uid() em cada tabela. O agente cria as políticas pelo conector; confira no painel quando ele terminar.
• Arquivos. Foto de perfil, PDF, anexo. No SuperDB, buckets públicos ou privados; no privado, toda leitura pede o token de um usuário logado do projeto.
• Atualização ao vivo. Chat, painel, fila de pedidos. O Realtime avisa o app quando uma linha muda.

A diferença aparece na quinta coisa: código que roda no servidor. Cobrar com um gateway de pagamento, chamar um modelo de IA com uma chave secreta ou receber um webhook de outro sistema pede um lugar onde a chave não fique exposta no navegador. O Lovable Cloud e o Supabase resolvem isso com Edge Functions, no mesmo lugar do banco. O SuperDB não tem esse recurso: o que é regra de dados vira gatilho SQL no próprio banco, e o que precisa chamar uma API com chave secreta vai para um servidor seu ou para uma função na hospedagem do front. Se o seu app depende muito disso, essa é uma boa razão para ficar no Lovable Cloud ou no Supabase.

Dois cuidados, qualquer que seja a escolha

• A service role nunca vai no prompt. Ela ignora a RLS. Colada numa conversa com o Lovable, passa a viver no histórico e no código gerado. O front usa só a anon key. A diferença entre as duas está em Service vs anon.
• Teste a RLS com dois usuários. Crie duas contas, grave um dado com a primeira e confira que a segunda não enxerga. É o teste que pega a política esquecida antes do cliente pegar.

Quando cada opção faz sentido

Lovable Cloud

Para protótipo, MVP de fim de semana e app interno pequeno. Nada para configurar, Edge Functions incluídas e uma conta só. O preço é a dependência: o banco fica dentro do Lovable, e sair depois pede exportar, restaurar e refazer login e segredos.

Supabase

Para quem quer o projeto no próprio nome e o maior ecossistema de Postgres: comunidade grande, Edge Functions, região em São Paulo e opção de servidor próprio. A integração com o Lovable é nativa. A conta vem em dólar, então no cartão brasileiro a compra é internacional, e a nota fiscal brasileira não aparece na página de preços deles.

SuperDB

Para quem quer o projeto no próprio nome, com Postgres, RLS e API REST automática, e uma conta que cabe na contabilidade brasileira: plano mensal em real, NFS-e no CPF ou no CNPJ, dados em São Paulo e suporte em português. Os planos pagos começam no Site, a R$ 39/mês, e o Pro custa R$ 119/mês. Não tem Edge Functions nem servidor próprio; se algum dos dois pesa, escolha outra opção da tabela.