Flyway migrations

This entire skill applies to relational databases only (MySQL, PostgreSQL, etc. — see spring-boot-jpa). MongoDB (spring-boot-mongodb) has no schema to migrate in the same sense; a document collection's shape evolves by writing application code that tolerates both old and new document shapes during a transition, or via a dedicated tool like Mongock for scripted, versioned document transformations — Flyway itself has no role there.

Naming convention (use this exactly — don't offer alternatives)

V<version>__<description>.sql

Version always starts at 1; a double underscore separates version from description. Example: V1__create_widgets_table.sql, V2__add_widget_price_index.sql.

Repeatable migrations (idempotent scripts — views, seed data) use R__<name>.sql instead, with no version number, and re-run whenever their checksum changes.

The one rule that matters most

Never modify an existing versioned migration file once it has shipped. Flyway checksums every applied migration; editing a shipped file breaks validation for anyone who already ran it. If a change is needed, write a new migration file with the next version number that corrects it — never edit history.