Database Migrations with Flyway in Spring Boot

Editing production schemas by hand does not scale and does not survive audits. Flyway treats every schema change as a versioned migration file that runs in order, exactly once, tracked in a metadata table.

Migrations are just SQL files

Flyway picks up files named V<version>__<description>.sql from src/main/resources/db/migration and applies them in version order on startup.

CREATE TABLE products (
    id          BIGSERIAL PRIMARY KEY,
    name        VARCHAR(200) NOT NULL,
    price       NUMERIC(10, 2) NOT NULL,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

Each change is a new file

Never edit an applied migration — Flyway verifies checksums and will refuse to start if a past migration changed. Add a new file instead.

ALTER TABLE products
    ADD COLUMN category VARCHAR(80) NOT NULL DEFAULT 'uncategorized';
 
CREATE INDEX idx_products_category ON products (category);

Boot runs it automatically

With the dependency on the classpath, Boot runs pending migrations before the application context finishes starting.

spring.flyway.enabled=true
spring.flyway.baseline-on-migrate=true
spring.jpa.hibernate.ddl-auto=validate

Setting ddl-auto=validate ensures Hibernate checks the schema matches your entities but never modifies it — Flyway owns the schema.

Takeaways

• Every schema change is an ordered, versioned, immutable migration file.
• Never edit an applied migration; add a new one instead.
• Let Flyway own the schema and set Hibernate to validate only.

Keep migrations backward compatible during rolling deploys — add columns before you require them, and remove them only after the old code is gone.