Documentação

• Extensions, schemas, enums e domains declarados nas migrations.
• Tabelas, colunas, defaults, constraints, índices e views.
• Funções, triggers e event triggers compatíveis.
• Políticas de RLS e o estado de RLS de cada tabela.
• Dados das tabelas do schema public, com checksum de conferência.
• Usuários de auth.users, preservando o id para não quebrar chaves estrangeiras.
• Edge functions (com a pasta _shared) e seus secrets.

Não são migrados: buckets e arquivos de Storage, jobs de cron que apontem para recursos inexistentes no destino, réplicas de Realtime configuradas fora das migrations e logs históricos.

• Um projeto Lovable com Lovable Cloud ativo (origem).
• Um projeto Supabase vazio ou novo (destino).
• Saldo de projeto e de migração na sua conta SupaMerge.
• A rota administrativa gerada pelo prompt da página Como usar, que expõe a função exec_sql na origem.

Cada projeto cadastrado guarda a rota da migração. Na execução são usadas:

• Origem — Project URL e service_role key, usadas para ler schema e dados via exec_sql.
• Destino — Project URL, service_role key e um access token da Management API, usado para aplicar migrations e publicar edge functions.

As chaves trafegam apenas entre o seu navegador e as funções do SupaMerge durante a execução. Gere um access token temporário e revogue-o depois da migração.

O SupaMerge espera um único arquivo .sql com todas as migrations concatenadas na ordem cronológica. O prompt da página Como usar faz o Lovable gerar esse arquivo por você.

A aplicação é feita em lotes retomáveis, com estas proteções:

• Instruções com dependências ainda inexistentes são adiadas e repetidas em novas passadas.
• Valores de enum ausentes no destino são reconciliados automaticamente.
• Erros conhecidos e inofensivos (cron ausente, schema de sistema) são registrados como aviso.
• Falhas isoladas não abortam a migração: elas aparecem no relatório final.

Se você fechar a aba no meio do processo, o progresso fica salvo e a migração é retomada exatamente de onde parou.

Os usuários são copiados antes dos dados públicos, para que chaves estrangeiras apontando para auth.users sejam satisfeitas. A cópia de dados usa ON CONFLICT DO NOTHING, então repetir uma migração não duplica linhas.

Cada tabela recebe uma contagem e um checksum comparando origem e destino. Divergências causadas por triggers do próprio destino (por exemplo, uma trigger que insere um papel padrão) são reportadas como aviso, não como falha.

Envie um arquivo .zip com a pasta supabase/functions preservando a estrutura, incluindo _shared. Também são aceitos arquivos .ts soltos ou um único arquivo consolidado com banners // Edge Function: nome.

Antes do deploy, o SupaMerge resolve os imports relativos de cada função e avisa se algum arquivo compartilhado estiver faltando. A publicação é feita em lotes para não estourar os limites da API.

• function public.exec_sql does not exist — a rota administrativa não foi criada na origem. Rode o prompt da etapa 1.
• Module not found file:///_shared/... — o zip das edge functions não incluiu a pasta _shared.
• Too Many Requests — limite da Management API. O motor faz backoff e continua sozinho.
• SEM_CREDITO_PROJETO ou SEM_CREDITO_MIGRACAO — sem saldo. Compre um pacote na página de assinaturas.

A cobrança é por projeto e por migração, em pacotes (Lite, Pro e Business). Cada projeto cadastrado consome um crédito de projeto e cada execução consome um crédito de migração. Retomar uma migração interrompida não consome crédito novo.

A direção suportada é Lovable Cloud → Supabase. Não fazemos o caminho inverso.