I’m trying to migrate my n8n version 1.51.2 setup to Google Cloud Platform using Cloud SQL and Cloud Run. Here’s what I did so far:
- Exported all data from my old PostgreSQL database
- Imported everything into the new Cloud SQL instance
- Deployed n8n 1.51.2 using Docker to Cloud Run
The application connects to the Cloud SQL database without issues, but during startup I keep getting these error messages:
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. Why would n8n try to create it again? I thought it would just start normally since all the tables are already there. Can someone explain how the migration process works and what triggers it to run?
This happens when n8n finds schema mismatches between your exported data and what the database expects. I ran into this during my own cloud migration - turns out importing database dumps doesn’t always keep the migration state that n8n needs to start up properly. The app checks everything on startup and freaks out if it finds gaps or conflicts in the migration history, even when the tables are there. What worked for me was starting fresh with a new Cloud SQL database and using n8n’s export/import feature in the web interface instead of dumping the database directly. This keeps the migration state synced with your app version. If that doesn’t work, you might have to manually fix the migrations table entries to match what version 1.51.2 expects.
I encountered a similar issue during my transition to n8n on Cloud SQL. The problem often arises when there are discrepancies between the existing migration records in your database and what n8n expects for the particular version you’re running. Even if the ‘migrations’ table is present, n8n still checks for specific migration entries tied to its running version and may attempt to create entries it finds missing. It’s a good practice to inspect your migration table’s contents to ensure compatibility with n8n 1.51.2. After migrating, ensure that the migration records from your older database match the expected structure for your new setup. If they don’t line up, n8n could refuse to initialize properly.
had the same headache last month! your migration table probably has entries pointing to different schema versions than n8n expects. clear the migrations table completely and let n8n rebuild it from scratch - it’ll detect your existing tables and skip creating them again.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.