I’m trying to migrate my n8n version 1.51.2 setup to Google Cloud Platform using Cloud SQL and Cloud Run. The migration process involved exporting my current PostgreSQL database and importing it into the new Cloud SQL instance.
The Docker deployment went smoothly and n8n connects to the Cloud SQL database without issues. However, during startup I keep getting these migration errors:
Error: There was an error running database migrations
QueryFailedError: relation "migrations" already exists
This is confusing because the migrations table is already present in the database from the import. Why would n8n try to create it again? I’m trying to understand the migration logic and what triggers these migration attempts during startup.
I expected n8n to start normally without attempting any migrations since all the database tables are already in place.
This happens because n8n validates schemas on startup no matter what tables already exist. The migration system needs specific metadata in the migrations table that matches your n8n version - when there’s a mismatch, it tries to recreate everything. I hit this exact problem moving between cloud providers last year. My exported database had migration records from a slightly different n8n build. Here’s what fixed it for me: connect directly to your Cloud SQL instance and run SELECT * FROM migrations ORDER BY timestamp; to see what migration entries you have versus what n8n 1.51.2 expects. You’ll probably need to manually adjust those migration records or just clear the migrations table completely and let n8n rebuild it while keeping your actual data tables. Definitely backup everything first though - you’re messing with core migration tracking.
sounds like a version mismatch. your old setup’s migration table prob has records that don’t match what 1.51.2 expects on GCP. drop just the migrations table (keep your data!) and restart n8n - it’ll recreate the migrations table without touching ur workflows or credentials.
I’ve encountered similar problems when upgrading n8n. The challenge often lies in the discrepancies between the existing database schema and the expected schema of the new n8n version. The migration errors you’re seeing generally indicate that n8n is not recognizing the state of your migrations table as valid. To resolve this, it’s essential to verify that your migrations table has the complete set of migration entries matching the version you are upgrading to. If you discover discrepancies, consider backing up the current migrations table, allowing n8n to regenerate a fresh one, then carefully reintroducing any required migration history.