I’m in the process of relocating my n8n version 1.51.2 setup to a Cloud SQL database on Google Cloud Platform alongside Cloud Run. This is what I’ve accomplished so far:
I exported all the data from my old PostgreSQL database.
After that, I imported the data into the new Cloud SQL instance.
I successfully deployed n8n 1.51.2 via Docker, linking it to the new database.
While the connection appears to be working, I’m facing an error during the startup:
Error: There was an error running database migrations
QueryFailedError: relation "migrations" already exists
I’m puzzled because the migrations table should already exist from the data I imported. Why is n8n attempting to create it again? I was expecting the startup to proceed without trying to run migrations since the structure is already set up.
Could anyone clarify how n8n determines when to run migrations? I anticipated it would bypass this step given that the schema is already established.
I encountered this same situation when migrating to a new environment. n8n performs internal checks on the migration state and can get confused if it finds discrepancies between the expected and actual database schema after a raw import. One effective approach I found was to set the environment variable N8N_SKIP_MIGRATIONS=true during the initial startup. This allows n8n to bypass the migration checks and accept the existing schema. After a successful startup, simply remove that variable for subsequent runs. Alternatively, consider dropping the migrations table from your database and letting n8n recreate it. This way, it can correctly identify your existing tables as migrated without trying to duplicate them. Always ensure you have backups before making changes.
Database migrations are such a headache when switching environments. I’ve hit this exact problem tons of times with workflow migrations.
Here’s what’s happening: n8n tracks migration state internally, so when you do a raw database import, the tracking gets completely out of sync. Your tables exist, but n8n doesn’t think they’re properly migrated.
Skip the manual migration table fixes - automate this whole thing instead. Set up a workflow that handles database migrations, validates schema states, and manages rollbacks when things break.
I use Latenode for this kind of infrastructure automation. You can build a workflow that checks your database state, handles migrations properly, and integrates with your GCP services. It connects directly to Cloud SQL and manages your entire deployment pipeline.
Best part? Once it’s set up, future migrations run completely automated. No more manual database imports or migration troubleshooting.
This happens when your imported database’s migration records don’t match what n8n expects for version 1.51.2. I ran into the same thing during an upgrade - n8n checks the migrations table to see which database changes have been applied, but when there’s a mismatch between your schema and the recorded migrations, it tries to recreate everything. Run this query to check what’s in your migrations table: SELECT * FROM migrations ORDER BY timestamp;. Compare it with a fresh n8n 1.51.2 install to spot missing or corrupted migration entries. You’ll probably need to manually insert the missing records or clean up duplicates that are causing the startup conflict.
yup, sounds like n8n’s missing the migration history. maybe the import didn’t grab all the records. double-check that migration table and see if all the entries are there. hope that helps!