I’m trying to move my n8n setup (version 1.51.2) from local postgres to Google Cloud SQL. The database transfer went smoothly and all my old data is there. When I start up the new Docker container on Cloud Run, it connects to the database fine but then crashes during startup.
The error message says:
Error: There was an error running database migrations
QueryFailedError: relation "migrations" already exists
This is confusing because the migrations table is already there from my old setup. Why would n8n try to create it again? I thought it would just check the existing schema and skip any setup steps.
Anyone know what triggers the migration process and how to avoid this issue? The startup should be clean since all the tables are already in place.
yep, that db can get wacked sometimes. just drop that migrations table, n8n should rebuild it on next startup. shouldn’t mess with your data, just makes sure everything’s in sync again!
Had this exact same issue migrating from local to managed PostgreSQL. n8n’s migration system doesn’t recognize the existing state in your transferred database properly. Here’s what fixed it for me: check the migration entries in your existing migrations table first. The checksums or version numbers often don’t match what n8n expects for version 1.51.2. Don’t drop anything yet - connect directly to your Cloud SQL instance and look at what’s in the migrations table. Compare those entries with a fresh n8n install to spot missing or corrupted records. If the data’s inconsistent, manually fix the migration state by updating those specific entries instead of recreating the whole table. You’ll keep all your workflow data and fix the migration conflict.
This happens when n8n spots a mismatch between your database state and its migration tracking. The migrations table exists, but n8n doesn’t think it’s set up right, so it tries to recreate it. I hit this same issue switching between PostgreSQL versions. Don’t drop tables yet - try running your n8n container with the --tunnel flag first to check the connection. Then verify your migration table structure matches your n8n version. Schema formats change between versions and cause these conflicts. Also check that your Cloud SQL instance runs the same PostgreSQL version as your local setup. Version mismatches trigger these unnecessary migration attempts.