I’m having trouble with my n8n setup. I moved my 1.51.2 installation to a cloud SQL database and GCP cloud run. I got the data moved over fine, and the Docker container is up. But when it tries to connect to the new database, I keep getting this error:
Error: There was an error running database migrations
QueryFailedError: relation "migrations" already exists
I’m confused because the migrations table is already there. Why is it trying to create it again? Does anyone know how n8n decides when to run migrations?
I thought it would just start up normally without trying to do any migrations. Any ideas what’s going on or how to fix this?
hey there, i ran into somethin similar when i moved my n8n setup. have u tried clearing the migrations table completely? sometimes leftover data can mess things up. also, double-check ur connection string - a tiny typo there could cause weird errors. good luck troubleshooting!
I’ve dealt with this exact issue before when migrating n8n. The problem likely stems from a mismatch between the database state and what n8n expects. Here’s what worked for me:
First, try running n8n with the ‘–reinstall-missing-packages’ flag. This forces n8n to check and reinstall any missing dependencies.
If that doesn’t work, you might need to manually reset the migrations. Back up your database, then drop the ‘migrations’ table entirely. Let n8n recreate it from scratch on the next startup.
Also, ensure your database user has sufficient permissions to create/alter tables. Sometimes cloud SQL setups have stricter default permissions that can cause these kinds of errors.
Lastly, double-check your n8n version matches between your old and new setups. Version mismatches can lead to unexpected migration behavior.
I encountered a similar issue during an n8n migration. One thing that resolved it for me was ensuring the database schema was completely empty before starting n8n in the new environment. This allows n8n to create all necessary tables from scratch.
If you’ve already populated the database, you might need to drop all tables and let n8n recreate them. Be sure to back up your data first. Also, check your n8n configuration to ensure it’s not trying to use both the old and new database simultaneously. Sometimes conflicting connection strings can cause unexpected behavior.
Another potential fix is to manually set the ‘migrations_locked’ table to false if it exists. This can sometimes get stuck and prevent new migrations from running properly.