O comando migrate do Django

✅ Artigo atualizado em Setembro 2026 Corrigimos o papel do makemigrations (ele não cria o banco), o comando de criação do projeto (django-admin startproject) e trocamos as saídas pelas reais do Django 6.1.1 (versão estável atual; a LTS é a 5.2). Também incluímos as opções --check e --prune.

Salve salve Pythonista!

Nesse post, vamos ver o que o comando migrate faz, as opções do comando e como ele ajuda a vida do desenvolvedor Django na hora de criar a estrutura do banco de dados da nossa aplicação!

Bora nessa!

Este artigo faz parte do Guia Completo de Django. Lá você encontra o caminho inteiro, da instalação ao deploy: Models, Views, Templates, Forms, Admin, bancos de dados, boas práticas e DRF.

Vá Direto ao Assunto…

• Onde estamos…
• O comando migrate
• DB Browser for SQLite
• Opções do comando migrate

Onde estamos…

Como usual, vamos nos situar nesse mundão Django!

No primeiro post da nossa Série de Django, tratamos de conceitos introdutórios do framework, uma visão geral da sua arquitetura, sua instalacão e a criação do Hello World, Django.

Já no segundo post da Série, tratamos da camada Model, onde definimos as entidades do nosso sistema, a interface com o banco de dados e aprendemos como utilizar a API de acesso a dados provida pelo Django - que facilita muito nossa vida!

Agora, vamos ver o funcionamento de um dos comandos mais importantes da camada Model do Django: o migrate.

Entender o migrate de verdade fica mais fácil dentro de um projeto Django completo, do model às APIs REST. É esse caminho que a Jornada Python ensina, com suporte de professor:

Domine Python: A Linguagem da Inteligência Artificial, do Desenvolvimento Web e das Carreiras do Futuro.

A mais completa formação para você se tornar um especialista em Python, pronto para construir desde aplicações web robustas com Django até projetos de Inteligência Artificial e Ciência de Dados .

Quero conhecer!

Nota 4,9 de 5 na Hotmart O curso de Python mais bem avaliado da Hotmart!

O comando migrate

Quando executamos o comando makemigrations, o Django apenas gera os arquivos de migration (como o 0001_initial.py) a partir das mudanças nos modelos. Ele não cria tabelas nem aplica nenhuma alteração no banco de dados.

Com SQLite, pode aparecer um arquivo db.sqlite3 vazio (0 bytes) logo depois do makemigrations: o comando abre uma conexão para conferir o histórico de migrations e o SQLite cria o arquivo nesse momento. Mas ele continua sem nenhuma tabela - quem cria a estrutura é o migrate.

Para que o Django as aplique, são necessárias três coisas, basicamente:

• 1. Que a configuração da interface com o banco de dados esteja descrita no arquivo de configurações settings.py.
• 2. Que os modelos e migrations estejam definidos para esse projeto.
• 3. Execução do comando migrate.

Se você acompanhou os últimos posts, você criou o projeto Hello World, Django através do comando django-admin startproject helloworld e, portanto, a configuração padrão foi aplicada.

Procure pela configuração DATABASES no settings.py. Nas versões atuais do Django ela vem assim (o BASE_DIR é um pathlib.Path, por isso o operador /):

1
2
3
4
5
6

DATABASES = {
    'default': {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": BASE_DIR / "db.sqlite3",
    }
}

Por padrão, o Django utiliza um banco de dados leve e compacto chamado SQLite. Já já vamos falar mais sobre ele.

Sobre os modelos e migrations, eles já foram feitos com a definição dos modelos no arquivo models.py e com a execução do comando makemigrations.

Agora só falta executar o comando migrate, propriamente dito!

Para isso, vamos para a raiz do projeto e executamos: python manage.py migrate. A saída no Django 6.1.1 é esta:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

$ python manage.py migrate

Operations to perform:
  Apply all migrations: admin, auth, contenttypes, helloworld, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying helloworld.0001_initial... OK
  Applying sessions.0001_initial... OK

Calma lá… O comando makemigrations que executamos havia definido apenas uma Migration e foram aplicadas 19!!! Por quê???

Se lembra que a configuração INSTALLED_APPS contém vários apps (e não apenas os nossos)?

Pois então, cada app desses contém seus próprios modelos e migrations. Sacou?!

Com a execução do migrate, o Django irá criar as diversas tabelas desses outros apps no banco de dados E as tabelas definidas nos nossos arquivos de modelo.

Quer ver o SQL exato que uma migration executa? Use o comando sqlmigrate: python manage.py sqlmigrate helloworld 0001. No SQLite, a saída para a nossa tabela é esta (quebramos a linha do CREATE TABLE para facilitar a leitura):

1
2
3
4
5
6
7
8
9
10
11
12
13

BEGIN;
--
-- Create model Funcionario
--
CREATE TABLE "helloworld_funcionario" (
    "id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
    "nome" varchar(255) NOT NULL,
    "sobrenome" varchar(255) NOT NULL,
    "cpf" varchar(14) NOT NULL,
    "tempo_de_servico" integer NOT NULL,
    "remuneracao" decimal NOT NULL
);
COMMIT;

Em outro banco o SQL muda (no PostgreSQL, por exemplo, a chave primária vira bigint ... GENERATED BY DEFAULT AS IDENTITY), mas a migration é a mesma: o Django traduz para o dialeto de cada banco.

Isso está muito abstrato! Como eu posso ver o banco, as tabelas e os dados na prática?

Está curtindo esse conteúdo?

Que tal receber 30 dias de conteúdo direto na sua Caixa de Entrada?

Sua assinatura não pôde ser validada.

Você fez sua assinatura com sucesso.

Assine as PyDicas e receba 30 dias do melhor conteúdo Python na sua Caixa de Entrada: direto e sem enrolação!

Seu nome

Seu e-mail

ASSINAR PYDICAS

DB Browser for SQLite

Apresento-lhes uma ferramenta MUITO prática: o DB Browser for SQLite!

Com ela, podemos ver a estrutura do banco de dados, alterar dados em tempo real, fazer queries, e muito mais!

Clique aqui para fazer download do DB Browser for SQLite e instalá-lo. Ao terminar a instalação, abra o DB Browser for SQLite.

Temos:

Nele, podemos clicar em “Abrir banco de dados” e procurar pelo banco de dados do nosso projeto db.sqlite3.

Ao importá-lo, teremos uma visão geral, mostrando Tabelas, Índices, Views e Triggers.

Para ver os dados de cada tabela, vá para a aba “Navegar dados”, escolha nossa tabela helloworld_funcionario e…

Voilá! O que temos? NADA

Calma jovem… Ainda não adicionamos nada

Mas, se você está ansioso para continuar nossa jornada Django, você pode ir direto para o próximo post, onde tratamos da Camada View do Django!

Estou construindo o Ebookr.ai, uma plataforma onde você cria ebooks profissionais com IA sobre qualquer assunto - do zero ao PDF pronto, com capas e infográficos gerados automaticamente. Dá uma olhada!

Opções do comando migrate

O formato padrão do comando migrate é o seguinte:

1

django-admin migrate [label_app] [nome_migration] [opções]

Abaixo vamos ver as opções do comando.

• Sem argumentos: aplica todas as migrações disponíveis de todos os apps definidos em INSTALLED_APPS.
• <label_app>: Aplica-se todas as migrações do app especificado até a mais recente. Pode envolver a aplicação de outras migrações, pois pode haver dependência entre migrações.
• <label_app> <nome_migrations>: Leva a estrutura do banco de dados a um estado em que a migração é aplicada, sem aplicar as migrações seguintes. Se a migração indicada for anterior às já aplicadas, as posteriores são desfeitas. Use o nome zero (ex.: python manage.py migrate helloworld zero) para desfazer todas as migrações do app.
• --database DATABASE: Especifica o banco de dados para executar as migrações. As opções disponíveis são aquelas que foram definidas pela configuração DATABASES no settings.py.
• --fake: Opção avançada que permite marcar migrações como aplicadas, sem realmente aplicá-las (ou seja, sem modificar a estrutura do seu banco de dados). Opção geralmente utilizada para recuperação da base de dados, ou quando se quer alterar manualmente a tabela interna de estados das migrações do Django.
• --fake-initial: Permite ao Django pular a migração inicial, caso todas as tabelas já tenham sido previamente criadas. Essa opção é usada quando a estrutura inicial de tabelas já foi criada previamente no banco de dados (por exemplo, sistema legado ou se um DBA já executou um script de criação das tabelas).
• --plan: Apenas mostra as migrações que serão aplicadas com a execução do comando migrate.
• --run-syncdb: Cria as tabelas de apps que não têm migrações. Essa opção não verifica a estrutura das tabelas nem as dependências entre elas. Não é recomendada no dia a dia; a documentação cita seu uso em sistemas muito grandes, com centenas de modelos, onde o framework de migrações do Django pode ser lento.
• --check: Não aplica nada; apenas termina com código de saída diferente de zero se existirem migrações não aplicadas. Muito útil em pipelines de CI/CD e em health checks de deploy.
• --prune: Remove da tabela interna django_migrations os registros de migrações cujos arquivos não existem mais (útil depois de fazer squash e apagar as migrações antigas).
• --noinput ou --no-input: Evita confirmações de usuário. Opção útil quando o comando é executado em scripts bash.
• --skip-checks: Pula as verificações do sistema (system checks) que o Django roda antes do comando.

Conclusão

Vimos nesse post como utilizar o comando migrate, suas opções e como ele facilita nossa vida.

Já imaginou ter que montar toda a estrutura de banco de dados na unha - com SQL e tudo mais?

Tá curtindo o conteúdo? Que tal levar esse conteúdo para onde for com nosso ebook GRÁTIS sobre Desenvolvimento Web com Python e Django?

Então aproveita essa chance

Ebook GRÁTIS

DESENVOLVIMENTO WEB COM PYTHON E DJANGO

Conteúdo:

• Veja como modelar sua aplicação
• Utilize a robusta API de Acesso a Dados do Django
• Aprenda sobre Class Based Views
• Construa Middlewares próprios
• Desenvolva filtros e tags customizados para criar lindos templates

Baixe já!

Se você quer ir além das migrations e construir um projeto Django completo, do model às APIs REST, dá uma olhada no curso de Django da Jornada Python.

Até a próxima!

Bom desenvolvimento!

Por Vinícius Ramos em 07/06/2018

Engenheiro de Computação pela UnB com especialização em Inteligência Artificial. Sr. Software Engineer com 10+ anos de experiência desenvolvendo sistemas críticos em Python e Django. Atuei no Banco do Brasil liderando equipes para monitoramento de mainframe, trabalhei como desenvolvedor sênior em projetos forenses para a Polícia Federal, e atualmente sou engenheiro de software na Labcorp (Estados Unidos), desenvolvendo soluções escaláveis para testes genéticos. Fundador da Python Academy, compartilhando conhecimento técnico com a comunidade brasileira desde 2018.

Bora se conectar no LinkedIn! vinicius-aramos

Minhas redes:

• 
• 
•