I’m working on moving my n8n version 1.51.2 setup from local to Google Cloud Platform. The plan was to migrate the existing PostgreSQL database to Cloud SQL and run n8n on Cloud Run.
Here’s what I did:
Exported all data from my current postgres database
Imported everything into the new Cloud SQL instance
Built and deployed the Docker container with n8n 1.51.2
Updated connection settings to point to the new Cloud SQL database
The connection works fine, but when n8n starts up I keep getting this error:
Error: There was an error running database migrations
QueryFailedError: relation "migrations" already exists
This is confusing because the migrations table is already there from the imported data. Why would n8n try to create it again? I thought it would just check the existing schema and skip any unnecessary migration steps.
Can someone explain how n8n decides when to run migrations and what might be causing this issue? I expected it to start normally without trying to recreate existing tables.
sounds like a schema ownership problem. did you check the migrations table permissions after importing the dump? cloud sql imports sometimes create tables that the n8n process can’t read properly - it thinks they don’t exist and tries recreating them. connect directly to your cloud sql instance and run \dt migrations to verify the table structure matches what n8n expects.
Same thing happened to me last month. It’s not permissions or version issues - n8n checks for the migrations table in a weird way. When you dump and restore the database, the table gets created but n8n’s migration runner doesn’t recognize it made the table itself. Drop just the migrations table from your Cloud SQL instance and let n8n recreate it on startup. It’ll detect the existing schema and populate the migrations table automatically. Obviously backup first, but this worked when I moved from local postgres to AWS RDS. Let n8n handle its own migration state instead of importing it.
I’ve hit this exact problem when moving between PostgreSQL environments. It’s usually a version mismatch in the migration tracking, not missing tables. Your migrations table exists, but n8n’s probably reading an incompatible schema version or the migration records don’t match what your n8n version expects. Connect to your Cloud SQL instance and run SELECT * FROM migrations ORDER BY timestamp; to see if all the expected entries are there. Missing entries will make n8n try to run them again. Also check for timezone differences between your local setup and Cloud SQL - they can mess with timestamp comparisons in the migration logic.