Schema migration is the process of evolving a database's structure alongside the application's code in a controlled, versioned, and repeatable way. In Spring JPA projects this is handled with a dedicated migration tool like Flyway or Liquibase rather than relying on Hibernate's ddl-auto to change production schemas.
Key Points: • Migration tools track applied changes in a history table, so each migration script runs exactly once, in order, across every environment. • Flyway uses versioned SQL (or Java) migration files named with a strict convention, e.g. V1__create_users_table.sql. • Liquibase supports SQL, XML, YAML, or JSON changelogs and adds richer rollback and changeset-tracking features. • Migrations run automatically on application startup when the Spring Boot starter is on the classpath, keeping schema changes tied to deployments. • Hibernate's ddl-auto (update/create) is convenient for local development but is considered unsafe for production since it can make unreviewed, unpredictable structural changes.
Example: When a new "phone_number" column needs to be added to the users table, the team adds a new Flyway migration script, V5__add_phone_number_to_users.sql, which runs automatically the next time the application starts in any environment, keeping every environment's schema in lockstep with the code.
Code Example:
-- src/main/resources/db/migration/V5__add_phone_number_to_users.sql
ALTER TABLE users ADD COLUMN phone_number VARCHAR(20);# application.properties
spring.flyway.enabled=true
spring.jpa.hibernate.ddl-auto=validateInterview Tip: A concise interview answer is:
"I use a migration tool like Flyway or Liquibase, checked into version control alongside the code, instead of letting Hibernate's ddl-auto modify the production schema. Each schema change becomes a new versioned migration script that runs automatically and exactly once per environment on deployment, so the database stays in sync with the application and every change is reviewable and repeatable."