Upgrading to v7

Upgrading an existing install to v7 is one-way. This page covers what the upgrade changes, where the backup of your database is, how to go back to an older version and return to v7, and how to try v7 without touching your current install.

The upgrade is one-way

The first time v7 starts on an existing install, it updates the database at <root>/databases/invokeai.db in place. After that, older versions cannot use it:

• v6.14 and later, and earlier v7 builds, stop at startup with an error that begins Database contains unknown applied migration IDs.
• v6.13 and earlier do not recognize the update. They start, log Database update needed, write a backup, and log Database updated successfully, though they changed nothing. They then run on a database they were not written for, where they can misbehave or damage it. They do this on every start, and each of these backups holds the v7 database, not a v6 one.

Restore a backup before you run any older version on this install.

The update changes the database only. Your images in outputs/ and your models are left as they are.

Backups

Before every update of the database, Invoke copies it to a backup in the same folder, <root>/databases/:

invokeai_backup_<YYYYMMDD>-<HHMMSS>.db

When two backups are made in the same second, the later one gets a number, e.g. invokeai_backup_20261019-093000-1.db. Before the update, the startup log shows a warning that names the backup:

Updating the database at <root>/databases/invokeai.db. Older versions of InvokeAI cannot use it after this update. Its current state is backed up to <root>/databases/invokeai_backup_20261019-093000.db; ...

Invoke never deletes backups. Delete old ones yourself once you no longer need them.

Which backup to restore

To go back to v6, restore the backup written when you first started v7. It holds your database as v6 left it. Its name carries the date and time of that first start, in your computer’s local time, and the names sort by time: it is the first backup at or after that start.

• Not an older backup. v6 writes backups with the same name when it updates the database itself, so older files are earlier v6 states, without your work since then.
• Not a newer backup. Each holds a database v6 cannot use: v7 writes one each time it updates the database, and v6.13 and earlier write one each time they start on it, as described above. If you already started an older version on the v7 database, the newest backup is one of these.

The log of that first v7 start names the file in the line Backing up database to <root>/databases/invokeai_backup_<YYYYMMDD>-<HHMMSS>.db. v7.0.0-alpha.1 to alpha.3 log only that line; later versions also name it in the warning shown above. Without that log, go by the time of the first start.

Nothing you did in v7 after that start is in the backup. Images you generated in v7 stay in outputs/, but v6’s gallery does not show them. Models you installed in v7 stay in the models folder, but v6’s model list does not have them.

Models installed in v7

v6 lists the models you installed in v7 as orphaned, and its Sync Models in the Model Manager offers to delete them. Keep them if you may go back to v7: the v7 database you set aside, invokeai.db.v7, still uses them.

MySQL and MariaDB

Invoke makes no backup of a server database. Back it up yourself before upgrading, as MySQL and MariaDB describes. To go back, restore that backup.

Restore a backup

1. Stop Invoke.

2. Open the databases folder in your root directory.

3. Move the current database aside: rename invokeai.db to invokeai.db.v7.

4. Required: if invokeai.db-wal or invokeai.db-shm exist, rename them to invokeai.db.v7-wal and invokeai.db.v7-shm. Left in place, the v7 database’s write-ahead log would be applied to the restored file and could corrupt it. Renamed this way, the three files stay a complete copy of your v7 database.

5. Copy the backup you chose to invokeai.db. Copy it rather than rename it, so the backup stays as it is.

6. Start the older version.

Steps 3 to 5 as commands, with your root directory and the backup’s name filled in:

Windows

cd <root>\databases
Rename-Item invokeai.db invokeai.db.v7
if (Test-Path invokeai.db-wal) { Rename-Item invokeai.db-wal invokeai.db.v7-wal }
if (Test-Path invokeai.db-shm) { Rename-Item invokeai.db-shm invokeai.db.v7-shm }
Copy-Item invokeai_backup_<YYYYMMDD>-<HHMMSS>.db invokeai.db

Linux/MacOS

cd <root>/databases
mv invokeai.db invokeai.db.v7
if [ -e invokeai.db-wal ]; then mv invokeai.db-wal invokeai.db.v7-wal; fi
if [ -e invokeai.db-shm ]; then mv invokeai.db-shm invokeai.db.v7-shm; fi
cp invokeai_backup_<YYYYMMDD>-<HHMMSS>.db invokeai.db

Starting v7 on the restored database updates it again, as your first v7 start did: v7 writes another backup and logs the warning. The updated database has none of your earlier v7 work; that is in invokeai.db.v7. To continue with it, switch back to it instead.

Switch back to the v7 database

To return to v7 after restoring a backup, put the v7 database you set aside back in place. What you did in v6 since the restore is not in it. Models you installed in v6 since then are missing from v7’s model list, and v7 lists them as orphaned.

1. Stop Invoke.

2. Open the databases folder in your root directory.

3. Move the restored database aside: rename invokeai.db to invokeai.db.v6, and, if they exist, invokeai.db-wal and invokeai.db-shm to invokeai.db.v6-wal and invokeai.db.v6-shm.

4. Rename invokeai.db.v7 to invokeai.db.

5. Required: if invokeai.db.v7-wal or invokeai.db.v7-shm exist, rename them to invokeai.db-wal and invokeai.db-shm. The write-ahead log can hold changes not yet written to the database file, and SQLite finds it only under the database’s name.

6. Start v7.

Steps 3 to 5 as commands:

Windows

cd <root>\databases
Rename-Item invokeai.db invokeai.db.v6
if (Test-Path invokeai.db-wal) { Rename-Item invokeai.db-wal invokeai.db.v6-wal }
if (Test-Path invokeai.db-shm) { Rename-Item invokeai.db-shm invokeai.db.v6-shm }
Rename-Item invokeai.db.v7 invokeai.db
if (Test-Path invokeai.db.v7-wal) { Rename-Item invokeai.db.v7-wal invokeai.db-wal }
if (Test-Path invokeai.db.v7-shm) { Rename-Item invokeai.db.v7-shm invokeai.db-shm }

Linux/MacOS

cd <root>/databases
mv invokeai.db invokeai.db.v6
if [ -e invokeai.db-wal ]; then mv invokeai.db-wal invokeai.db.v6-wal; fi
if [ -e invokeai.db-shm ]; then mv invokeai.db-shm invokeai.db.v6-shm; fi
mv invokeai.db.v7 invokeai.db
if [ -e invokeai.db.v7-wal ]; then mv invokeai.db.v7-wal invokeai.db-wal; fi
if [ -e invokeai.db.v7-shm ]; then mv invokeai.db.v7-shm invokeai.db-shm; fi

Run v7 alongside v6

Each install’s root directory holds its own database, images and models. Give v7 a root of its own, and your v6 install stays as it is. The v7 install starts with an empty gallery and no models.

• Launcher: install v7 into a new, empty folder. Do not select your existing install: that upgrades it in place. The folder you install into is v7’s root directory.
• Manual install: install v7 into a new directory, as Manual Installation describes, and start it with --root set to that directory, or set the INVOKEAI_ROOT environment variable. --root takes precedence over INVOKEAI_ROOT, which takes precedence over the directory of the active virtual environment; see InvokeAI Root Directory.

Keep the models folders apart

Do not point both installs’ models_dir at the same folder. Each install knows only the models it installed itself, so Clean up orphaned models in one install’s Model Manager lists the other install’s models as orphaned and offers to delete them.