This section describes the DDL commands pertaining to migrations.

Like all DDL commands, start migration and other migration commands are considered low-level. Users are encouraged to use the built-in migration tools instead.

Start a migration block.

start migration to "{"
    sdl-declaration ;
    [ ... ]
"}" ;

Complete schema defined with the declarative EdgeDB schema definition language.

The command start migration defines a migration of the schema to a new state. The target schema state is described using SDL and describes the entire schema. This is important to remember when creating a migration to add a few more things to an existing schema as all the existing schema objects and the new ones must be included in the start migration command. Objects that aren’t included in the command will be removed from the new schema (which may result in data loss).

This command also starts a transaction block if not inside a transaction already.

While inside a migration block, all issued EdgeQL statements are not executed immediately and are instead recorded to be part of the migration script. Aside from normal EdgeQL commands the following special migration commands are available:

  • describe current migration – return a list of statements currently recorded as part of the migration;

  • populate migration – auto-populate the migration with system-generated DDL statements to achieve the target schema state;

  • abort migration – abort the migration block and discard the migration;

  • commit migration – commit the migration by executing the migration script statements and recording the migration into the system migration log.

Create a new migration to a target schema specified by the EdgeDB Schema syntax:

start migration to {
    module default {
        type User {
            property username -> str;

Create a new migration using an explicit EdgeQL script.

create migration "{"
    edgeql-statement ;
    [ ... ]
"}" ;

Any valid EdgeQL statement, except database, role, configure, migration, or transaction statements.

The command create migration executes all the nested EdgeQL commands and records the migration into the system migration log.

Create a new migration to a target schema specified by the EdgeDB Schema syntax:

create migration {
    create type default::User {
        create property username -> str;

Abort the current migration block and discard the migration.

abort migration ;

The command abort migration is used to abort a migration block started by start migration. Issuing abort migration outside of a migration block is an error.

Start a migration block and then abort it:

start migration to {
    module default {
        type User;

abort migration;

Populate the current migration with system-generated statements.

populate migration ;

The command populate migration is used within a migration block started by start migration to automatically fill the migration with system-generated statements to achieve the desired target schema state. If the system is unable to automatically find a satisfactory sequence of statements to perform the migration, an error is returned. Issuing populate migration outside of a migration block is also an error.

The statements generated by populate migration may drop schema objects, which may result in data loss. Make sure to inspect the generated migration using describe current migration before running commit migration!

Start a migration block and populate it with auto-generated statements.

start migration to {
    module default {
        type User;

populate migration;

Describe the migration in the current migration block.

describe current migration [ as {ddl | json} ];

The command describe current migration generates a description of the migration in the current migration block in the specified output format:

as ddl

Show a sequence of statements currently recorded as part of the migration using valid DDL syntax. The output will indicate if the current migration is fully defined, i.e. the recorded statements bring the schema to the state specified by start migration.

as json

Provide a machine-readable description of the migration using the following JSON format:

  // Name of the parent migration
  "parent": "<parent-migraiton-name>",

  // Whether the confirmed DDL makes the migration complete,
  // i.e. there are no more statements to issue.
  "complete": {true|false},

  // List of confirmed migration statements
  "confirmed": [
    "<stmt text>",

  // The variants of the next statement
  // suggested by the system to advance
  // the migration script.
  "proposed": {
    "statements": [{
      "text": "<stmt text template>"
    "required-user-input": [
        "placeholder": "<placeholder variable>",
        "prompt": "<statement prompt>",
    "confidence": (0..1), // confidence coefficient
    "prompt": "<operation prompt>",
    "prompt_id": "<prompt id>",
    // Whether the operation is considered to be non-destructive.
    "data_safe": {true|false}


<stmt text>

Regular statement text.

<stmt text template>

Statement text template with interpolation points using the \(name) syntax.

<placeholder variable>

The name of an interpolation variable in the statement text template for which the user prompt is given.

<statement prompt>

The text of a user prompt for an interpolation variable.

<operation prompt>

Prompt for the proposed migration step.

<prompt id>

An opaque string identifier for a particular operation prompt. The client should not repeat prompts with the same prompt id.

Commit the current migration to the database.

commit migration ;

The command commit migration executes all the commands defined by the current migration and records the migration as the most recent migration in the database.

Issuing commit migration outside of a migration block initiated by start migration is an error.

Create and execute the current migration:

commit migration;

Reset the database schema to its initial state.

reset schema to inital ;

This command will drop all entities and, as a consequence, all data. You won’t want to use this statement on a production instance unless you want to lose all that instance’s data.

Migration rewrites allow you to change the migration history as long as your final schema matches the current database schema.

Start a migration rewrite.

start migration rewrite ;

Once the migration rewrite is started, you can run any arbitrary DDL until you are ready to commit your new migration history. The most useful DDL in this context will be create migration statements, which will allow you to create a sequence of migrations that will become your new migration history.

Establish a new savepoint within the current migration rewrite.

declare savepoint savepoint-name ;

The name which will be used to identify the new savepoint if you need to later release it or roll back to it.

Destroys a savepoint previously defined in the current migration rewrite.

release savepoint savepoint-name ;

The name of the savepoint to be released.

Rollback to the named savepoint.

rollback to savepoint savepoint-name ;

All changes made after the savepoint are discarded. The savepoint remains valid and can be rolled back to again later, if needed.


The name of the savepoint to roll back to.

Rollback the entire migration rewrite.

rollback ;

All updates made within the transaction are discarded.

Commit a migration rewrite.

commit migration rewrite ;

We use ChatGPT with additional context from our documentation to answer your questions. Not all answers will be accurate. Please join our Discord if you need more help.