Flyway will try to locate the schema history table in the database. Since it is empty, Flyway won't find it and will create it instead.

You now have a database with a single empty table called flyway_schema_history by default:

This table is used to track the changes to the database.

Flyway will scan the filesystem or the classpath of the application for migrations. They can be written in either SQL, Java, or other scripting languages.

The migrations are applied in order based on their version number:

As each migration gets applied, the schema history table is updated accordingly:

flyway_schema_history

With the metadata and the initial state in place, we can now talk about migrating to newer versions.

New migrations can be added to the filesystem or the classpath of the application. Flyway will check the migrations on disk against the schema history table. If their version number is lower than the table's current version, they are ignored by default.  The remaining migrations are the pending migrations: available, but not applied.

The pending migrations can be applied in order based on their version number:

The schema history table is updated accordingly:

flyway_schema_history

And that's it! 

Every time you need to update the database, whether structure (DDL) or data (DML), simply create a new migration. Flyway will find pending migrations and upgrade the database accordingly.

For MySQL, Oracle, PostgreSQL and SQL Server databases, Flyway can also capture the state of all the objects and reference data as a model on disk.  This is called the schema model, which can be committed to version control to provide a history of how each object has changed over time. 

Ready to get started? Then take one of our 5 minute tutorials:

• Quickstart - Flyway Desktop
• Quickstart - Command-line
• Quickstart - Docker
• Quickstart - API
• Quickstart - Maven
• Quickstart - Gradle
• Quickstart - Starting a Trial in Flyway Desktop
• Quickstart - Starting a Trial in the Flyway CLI