The evolve command is responsible for setting up databases and applying any evolutions or migrations.

This is a replacement for both the syncdb and migrate commands in Django. Running either of this will wrap evolve (though not all of the command’s arguments will be supported when Django Evolution is enabled).

Creating/Updating Databases

To construct a new database or apply updates, you will generally just run:

$ ./manage.py evolve --execute

This is the most common usage for evolve. It will create any missing models and apply any unapplied evolutions or migrations.

Changed in version 2.0: evolve now replaces both syncdb and migrate. In previous versions, it had to be run after syncdb.

Generating Hinted Evolutions

When making changes to a model, it helps to see how the evolution should look before writing it. Sometimes the evolution will be usable as-is, but sometimes you’ll need to tweak it first.

To generate a hinted evolution, run:

$ ./manage.py evolve --hint

Hinted evolutions can be automatically written by using --write, saving you a little bit of work:

$ ./manage.py evolve --hint --write my_new_evolution

This will take any app with a hinted evolution and write a appdir/evolutions/my_new_evolution.py file. You will still need to add your new evolution to the SEQUENCE list in appdir/evolutions/__init__.py.

If you only want to write hints for a specific app, pass the app labels on the command line, like so:

$ ./manage.py evolve --hint --write my_new_evolution my_app



Zero or more specific app labels to evolve. If provided, only these apps will have evolutions or migrations applied. If not provided, all apps will be considered for evolution.

--database <DATABASE>

The name of the configured database to perform the evolution against.


Display sample evolutions that fulfill any database changes for apps and models managed by evolutions. This won’t include any apps or models managed by migrations.


Perform evolutions automatically without any input.


Remove information on any non-existent applications from the stored project signature. This won’t remove the models themselves. For that, see DeleteModel or DeleteApplication.


Display the generated SQL that would be run if applying evolutions. This won’t include any apps or models managed by migrations.


Write any hinted evolutions to a file named appdir/evolutions/EVOLUTION_NAME. This will not include the evolution in appdir/evolutions/__init__.py.

-x, --execute

Execute the evolution process, applying any evolutions and migrations to the database.


This can be used in combination with --hint to apply hinted evolutions, but this is generally a bad idea, as the execution is not properly repeatable or trackable.