Short interview answer (30 seconds)
“Migration history is shared by treating migrations as code in Git, reviewing them via pull requests, and relying on the database’s schema history tables maintained by tools like Flyway or Liquibase. Additionally, we expose the current DB version via CI/CD logs or standard queries so the whole team can see what ran in each environment.”
That’s already a strong answer.
1️⃣ Migrations as code (the primary way)
This is non-negotiable.
What you do
- Store all migrations in the repository
- One migration = one commit/PR
- Code review is mandatory
- Never edit applied migrations
Result
- Git history = shared migration history
- You can answer:
- Who added this column?
- Why was this index created?
- In which release did it appear?
👉 This is the most important sharing mechanism.
2️⃣ Database schema history tables (source of truth)
Migration tools automatically store execution history in the DB.
Tools
- Flyway →
flyway_schema_history - Liquibase →
DATABASECHANGELOG
How teams share it
- Standard SQL queries documented in runbooks
- Read-only access for developers
- “What version is prod at?” → one query
Example (Flyway-style):
SELECT version, description, installed_on
FROM flyway_schema_history
WHERE success = true
ORDER BY installed_rank DESC
LIMIT 10;
This avoids guessing and Slack archaeology.
3️⃣ CI/CD output and release notes
Good teams surface migration info automatically.
Common practices
- Print applied migration versions during deployment
- Include migration list in release notes
- Link migrations to PRs or tickets
Example release note excerpt:
DB changes:
- V2026_01_10_01__add_user_status
- V2026_01_10_02__backfill_status
Now everyone (backend, QA, ops) shares the same view.
4️⃣ Conventions that make history readable
History is useless if it’s messy.
Use:
- clear naming (
V2026_01_13__add_order_index.sql) - small, focused migrations
- comments inside SQL explaining why, not what
This makes scanning history fast and safe.
5️⃣ Documentation / runbooks (lightweight)
Not a wiki novel—just essentials:
- where migrations live
- how to check current DB version
- rules (immutability, forward-only, expand–contract)
This is how new team members get aligned quickly.
What NOT to rely on ❌
- “Ask the DBA”
- “I remember running it”
- Manual SQL shared in chat
- Local-only scripts
Those are anti-patterns.
Final polished interview phrasing (memorize)
“We share migration history by keeping migrations under version control with PR reviews, using the database’s schema history tables as the source of truth, and exposing applied migration versions through CI/CD logs or release notes. This way, anyone on the team can see what changed and when.”
That answer signals senior-level operational maturity.
Because those tables are the single source of truth for your database state. Editing them manually breaks guarantees that migration tools—and your team—rely on.
Below is the senior-level explanation interviewers want.
Short interview answer (30 seconds)
“Manually editing the changelog history tables is dangerous because it breaks the migration tool’s consistency guarantees. The database state no longer matches the applied migrations, checksums become invalid, deployments become unpredictable, and you can no longer trust what version the schema is in.”
What those tables actually represent
Migration tools don’t “guess” what ran—they record it:
- Flyway →
flyway_schema_history - Liquibase →
DATABASECHANGELOG
These tables track:
- what migration ran
- when it ran
- whether it succeeded
- what checksum/content it had
They are not logs.
They are state.
Why manual edits are bad (real reasons)
1) You desynchronize reality from recorded state
Example:
- Migration created a column
- You delete its row from
flyway_schema_history
Now the tool thinks:
“Column doesn’t exist.”
But the DB says:
“It does.”
Next deploy:
- migration re-runs
- fails or corrupts data
This is how mysterious prod-only failures are born.
2) Checksums no longer protect you
Both tools use checksums to detect tampering.
If you:
- edit history rows
- “fix” versions
- mark failed migrations as successful
You’ve disabled the safety net that prevents:
- re-running modified migrations
- inconsistent environments
3) You destroy reproducibility
A core promise of migrations:
“Any environment can be recreated from scratch and end up identical.”
Manual edits break this:
- new env ≠ prod
- staging ≠ prod
- no one can explain why
That’s an ops nightmare.
4) Rollouts and rollbacks become unsafe
CI/CD assumes:
- history table is correct
- migration ordering is reliable
If history is manually altered:
- deploys may skip required migrations
- or reapply destructive ones
- rollbacks become meaningless
This turns releases into Russian roulette.
5) You hide real problems instead of fixing them
Common anti-pattern:
“Migration failed in prod—just fix the history row.”
What actually happened:
- migration was wrong
- data state was unexpected
- environment drift exists
Editing history masks the bug and guarantees it will resurface later.
What to do instead (the correct fixes)
If a migration is wrong
- Create a new migration that fixes it
- Never rewrite history
If a migration failed halfway
- Investigate why
- Fix DB state explicitly
- Re-run or repair using the tool’s official commands
If history is corrupted
- Treat it as an incident
- Reconcile schema vs history carefully
- Document and prevent recurrence
The one acceptable exception (very rare)
Using official repair commands:
- Flyway:
repair - Liquibase: documented repair flows
Only when:
- you fully understand the impact
- you are restoring consistency, not hiding mistakes
Manual SQL edits are still the wrong move.
Final “senior” phrasing (memorize)
“Changelog history tables are the authoritative record of schema state. Manually editing them breaks checksums, destroys reproducibility, and makes deployments unpredictable. If something goes wrong, the fix is a new migration or an official repair—never direct edits.”