Datenbankmigrationen mit Flyway

Editing the database by hand is error-prone and hard to reproduce across dev, test, and production. Migrations turn schema changes into versioned, repeatable scripts.

Flyway is a migration tool that applies SQL scripts in order, tracking which have run in a history table so each runs exactly once.

Spring Boot auto-detects Flyway on the classpath and runs migrations at startup. Just add the dependency.

Versioned scripts follow the pattern V1__description.sql. The version number after V determines execution order.

• V1__create_users.sql
• V2__add_email_column.sql

By default Flyway looks in src/main/resources/db/migration. Place your SQL files there and they are picked up automatically.

Your first script typically creates a table. Once applied, Flyway records it and never runs it again.

Flyway maintains a flyway_schema_history table recording each applied version, its checksum, and timestamp. This is how it knows what is pending.

Once a migration has run anywhere, treat it as immutable. Editing it changes the checksum and Flyway will fail validation. Always add a new migration instead.

Scripts prefixed with R__ instead of a version run whenever their content changes. They are ideal for views and stored procedures.

Disable Hibernate's auto schema generation and let Flyway own the schema. This gives you a single, reliable source of truth for structure.

Because migrations run automatically and deterministically, every environment converges to the same schema, making deployments predictable and rollbacks easier to reason about.

Test your understanding of Flyway migrations.

You learned to version schema changes with Flyway: naming conventions, the history table, immutability of applied scripts, repeatable migrations, and pairing Flyway with JPA validation for reliable deployments.