How to Manage Database Versioning in Spring Boot with Flyway – A Step‑by‑Step Guide

Flyway Overview

Flyway is an open‑source database migration tool that follows the convention‑over‑configuration principle. It provides commands such as migrate, clean, info, validate, baseline and repair, and supports SQL and Java migrations via Maven, Gradle, SBT, ANT and other plugins.

Hands‑On Example

Add the Flyway dependency to pom.xml:

<dependency>
  <groupId>org.flywaydb</groupId>
  <artifactId>flyway-core</artifactId>
  <version>5.0.3</version>
</dependency>

Create a versioned SQL script. In src/main/resources/db add V1__Base_version.sql containing the DDL for the user table, e.g.:

DROP TABLE IF EXISTS user;
CREATE TABLE `user` (
  `id`   bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `name` varchar(20) NOT NULL COMMENT '姓名',
  `age`  int(5) DEFAULT NULL COMMENT '年龄',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Configure Flyway to load scripts from the db folder by adding to application.properties: flyway.locations=classpath:/db Run the unit test ApplicationTests. Flyway logs show the migration version 1 being applied, the creation of the flyway_schema_history table, and successful validation of one migration.

Re‑run the test – Flyway detects that the migration has already been applied and skips execution, reporting the schema as up‑to‑date.

Modify the name column length in V1__Base_version.sql and run the test again. Flyway validation fails with a checksum mismatch and throws a FlywayException, preventing the altered script from being applied and protecting the database schema.

Conclusion

The article demonstrates how to integrate Flyway into a Spring Boot project to version‑control a MySQL schema, how Flyway tracks applied migrations, and how it safeguards against accidental script changes by validating checksums before execution.