PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchSpring Boot 3 can run Flyway migrations automatically when the Flyway dependency and database connection are configured. Put versioned SQL scripts in src/main/resources/db/migration, use names such as V1__create_customer.sql, and let Flyway apply them during application startup. For an existing database, decide deliberately whether and how to baseline it before enabling migrations.
1. Add Flyway and the database module
Add org.springframework.boot:spring-boot-starter-flyway to your application. Some databases also require a Flyway database-specific module. For PostgreSQL, include org.flywaydb:flyway-database-postgresql alongside the starter; see the Spring Boot Flyway guidance.
Use dependency versions managed by your Spring Boot 3 release where available, and check the compatibility guidance for the specific Boot and Flyway versions in your build. The database-specific module supplies support that should not be assumed to come from the starter alone.
2. Create and locate migration files
By default, Spring Boot looks for migration scripts at classpath:db/migration. In a typical project, that corresponds to src/main/resources/db/migration. A versioned SQL migration uses the form V<VERSION>__<NAME>.sql, with two underscores between the version and description.
#1 Best Overall
src/main/resources/db/migration/
V1__create_customer.sql
V2__add_status.sqlExample contents:
-- V1__create_customer.sql
CREATE TABLE customer (
id BIGINT PRIMARY KEY,
name VARCHAR(200) NOT NULL
);-- V2__add_status.sql
ALTER TABLE customer ADD COLUMN status VARCHAR(30);Once a versioned migration has been applied in an environment, treat it as immutable. Make a later change in a new versioned migration rather than editing the old file: Flyway records applied migrations and validates them against the files it finds.
Change the migration location
Set spring.flyway.locations if you use a different classpath or filesystem location. For example, classpath:db/migration is the default location; a custom setting can point Flyway at another location or include multiple locations as supported by the property configuration. See the Spring Boot application properties reference for the property syntax and defaults.
Other migration types
Flyway also supports Java migrations, SQL callbacks, and Java callback beans. Use these when SQL versioned scripts alone do not fit the migration or lifecycle operation; keep schema changes reviewable and consistent with the team’s deployment process.
3. Configure the datasource and Flyway
Spring Boot normally uses the application’s primary DataSource for Flyway. Configure that datasource as you normally would, then set relevant spring.flyway properties as needed. A separate migration datasource can be supplied with @FlywayDataSource, which is useful when migration credentials or connectivity differ from those used by the application.
spring:
flyway:
locations: classpath:db/migration
validate-on-migrate: true
# Set only when intentionally adopting a pre-existing schema:
# baseline-on-migrate: true
# baseline-version: 1The configuration above explicitly keeps validation enabled and shows baseline options commented out because enabling baseline-on-migrate changes how Flyway handles a non-empty database without a history table. Common settings include baseline-on-migrate, baseline-version, table, target, validate-on-migrate, and Flyway-specific url, user, and password. The history table defaults to flyway_schema_history.
4. What happens when the Spring Boot application starts?
When Flyway is present and configured, Spring Boot auto-configures it and calls Flyway.migrate() during startup. Flyway applies pending migrations in order; its migrate operation advances the schema to the latest applicable version and creates the schema history table if it does not already exist. This is why adding a new migration can change the database when the application starts, rather than only when a developer runs a separate command.
Rank #4
For production systems, decide whether migrations should run as part of application startup or through a controlled build/CLI deployment step. Startup migration is convenient, but it means the application identity and startup lifecycle are involved in schema changes. Whichever approach you choose, coordinate migration execution so deployments do not unintentionally race or use unsuitable credentials.
5. Baseline an existing database safely
Baseline is for adopting a non-empty schema that has no Flyway history. It tells Flyway to treat a selected version as the starting point, excluding migrations at or below that baseline from execution on that database. It does not recreate the pre-existing schema from old migration files.
- Inventory the existing schema. Confirm which structures and changes are already present, and identify the version that accurately represents that state.
- Choose the baseline version deliberately. Set
spring.flyway.baseline-versionto the version represented by the existing schema. Ensure migrations intended only for new installations do not conflict with objects already present. - Choose how to establish the baseline. Flyway’s baseline operation can record the starting point explicitly. Alternatively,
baseline-on-migrateallows migration to baseline a non-empty schema automatically; enable it only when that behavior is intended. - Test both paths. Verify that a fresh database receives the complete migration sequence and that a representative existing database is recognized at the chosen baseline and receives only later migrations.
Baseline configuration is an operational safety decision, not a routine switch to enable indiscriminately: it changes Flyway’s protection against running migrations against an untracked, non-empty database.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.6. Test migrations and plan for database-specific failures
Run every migration against a fresh database and a representative existing database in the delivery pipeline. Review the target database’s DDL transaction behavior before assuming a failed migration will be rolled back cleanly. Flyway documents that some databases or DDL operations use implicit commits or have limited transactional DDL support; a failure can therefore leave partial changes that require manual cleanup before retrying or repairing migration history.
For PostgreSQL-specific behavior, including its database module and locking details, consult the Flyway PostgreSQL reference. Do not treat a generic rollback expectation as a substitute for understanding the exact statements and database involved.
Quick Recap
7. A practical setup sequence
- Add
spring-boot-starter-flywayand, when required, the module for the target database, such asflyway-database-postgresql. - Configure the application’s database connection and decide whether Flyway should use the primary datasource or a dedicated migration datasource.
- Create numbered migration scripts under
src/main/resources/db/migration, or configurespring.flyway.locations. - Keep applied versioned files unchanged; add a new version for each subsequent schema change.
- Test on fresh and representative existing databases. For an existing schema, establish and review its baseline before allowing normal migration.
- Choose startup or pipeline/CLI execution and ensure the credentials and deployment coordination match that choice.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
