Changing database credentials or the JDBC URL during a migration is riskier than it sounds. The impact depends on when and how you change them, but the common failure mode is schema history divergence and partial application.
Here’s how I’d explain it at a senior interview level.
1) You may point to a different database or schema
Impact
- Migrations run against the wrong DB (stage instead of prod, wrong shard, wrong tenant).
- A new, empty
flyway_schema_history/DATABASECHANGELOGtable appears → tool thinks nothing was applied. - Result: migrations re-run from scratch against an unexpected target.
Typical causes
- Different DB name in URL
- Different
search_path/ default schema - Different service endpoint (proxy, reader vs writer)
Mitigation
- Hard-validate environment:
- expected DB name
- expected schema
- expected current schema version
- Fail fast if mismatch is detected.
2) Schema history table ownership / visibility breaks
Impact
- Migration tool can’t see or write to its history table.
- Errors like:
- “relation flyway_schema_history does not exist”
- “permission denied on DATABASECHANGELOG”
- Or worse: tool silently creates a new history table in another schema.
Root causes
- Changed DB user
- Changed default schema
- Different privileges/ownership
Mitigation
- Ensure:
- migration user owns (or has full rights on) schema history tables
- schema is explicitly configured (
flyway.schemas, Liquibase default schema)
- Never rely on implicit defaults.
3) Privilege mismatch causes mid-migration failures
Impact
- Some statements succeed, others fail:
- add column succeeds
- create index fails (“must be owner of relation”)
- Leaves DB in a half-applied state.
Root causes
- New credentials lack DDL rights
- Objects owned by a different role
Mitigation
- Separate roles:
migration_role(DDL + controlled DML)app_role(runtime only)
- Validate privileges before migration (pre-flight checks).
4) Checksum / metadata inconsistencies
Impact
- Tool sees applied migrations but checksums don’t match expectations.
- Or the history table differs between environments because migrations ran under different configs.
Root causes
- Same migrations applied in different DBs/environments unintentionally
- Placeholder or schema differences tied to connection settings
Mitigation
- Keep migration configuration deterministic:
- same schemas
- same placeholders
- same tool version
- Never “repair” to hide environment mistakes.
5) Read-replica or proxy misrouting (very common)
Impact
- Migrations executed against a read replica or a DB proxy that routes to readers.
- Results:
- failures (“cannot execute DDL on read-only transaction”)
- or delayed application via replication → app breaks on primary
Mitigation
- Explicitly target writer endpoints for migrations.
- Separate URLs:
DB_URL_MIGRATIONDB_URL_APP_READDB_URL_APP_WRITE
6) GitOps / CI retries amplify the blast radius
Impact
- GitOps controller retries a failed migration with different credentials.
- Multiple attempts against different targets → inconsistent state.
Mitigation
- Single migration runner per environment.
- Credentials bound to environment identity.
- Clear observability: which job ran against which DB.
7) Interview-quality summary (say this)
“Changing DB credentials or the URL during migration can cause migrations to run against a different database or schema, lose access to the schema history table, or fail mid-way due to privilege differences. The worst case is silent re-execution of migrations because the tool thinks it’s a fresh database. To prevent this, I pin migrations to a dedicated writer endpoint, use a stable migration role with explicit schema configuration, and add pre-flight checks to verify DB identity and expected schema version before applying anything.”
Senior signal (bonus)
If you add:
- “We fail the migration if the current schema version doesn’t match the expected release baseline”
- “We never change credentials during a running migration job”
- “We separate migration and runtime URLs/roles”