Versionar tabelas com migrations

Crie a primeira alteração

Com a CLI inicializada, gere uma migration para uma tabela de estudo:

1
npx supabase migration new criar_notas

Abra o arquivo criado em supabase/migrations e adicione:

1
create table public.notas (
2
  id uuid primary key default gen_random_uuid(),
3
  texto text not null
4
);
5
alter table public.notas enable row level security;

A tabela começa sem políticas para o cliente. O SQL Editor administrativo pode acessar registros com privilégios diferentes dos usados pelo navegador. Não use essa consulta administrativa como comprovação de acesso do usuário.

Reproduza o schema

Em um banco local descartável, execute:

1
npx supabase db reset

O reset recria o banco local a partir das migrations e seeds. Ele apaga alterações e registros locais não representados nesses arquivos. Confirme o ambiente antes de executar o comando e mantenha fora dele qualquer informação necessária.

No Studio, abra a tabela criada. Compare as colunas com o arquivo SQL e consulte o estado de RLS. Rode o reset novamente para conferir se a sequência completa permanece reproduzível. Se houver falha, corrija a migration ainda não compartilhada e repita a conferência.

Compartilhe o histórico

Versione os arquivos SQL junto com a aplicação. Depois que uma migration tiver sido aplicada em ambiente compartilhado, registre alterações posteriores em outro arquivo. Reescrever o histórico já aplicado dificulta reproduzir o estado do banco.

Para um projeto remoto existente, siga o fluxo oficial de vínculo e captura do schema antes de enviar migrations. Confira a referência do projeto, o histórico remoto e a estratégia de backup. O envio remoto não faz parte deste exercício local.

Inclua políticas, índices e grants nas migrations correspondentes. Uma tabela criada corretamente pode continuar indisponível para o cliente se as permissões não acompanharem a mudança.