Automating schema migrations with Flyway means using Flyway’s version-controlled SQL or Java scripts and repeatable commands to apply database schema changes consistently across environments without manual intervention.
Flyway is an open-source database migration tool that manages schema changes through versioned scripts stored alongside application code. By integrating Flyway into your CI/CD pipeline you can apply, verify, and track schema alterations automatically every time you deploy—eliminating fragile manual steps, reducing production incidents, and guaranteeing that every developer, staging, and production database shares the same structure.
At its core Flyway follows a simple but powerful principle: migrations are just files. Each migration is a SQL (or Java/Kotlin) script named following the pattern V<version>>__<description>.sql
(e.g., V2__add_users_table.sql
). Flyway keeps a table called flyway_schema_history
in the target database to track which versions have already been executed. When invoked, Flyway scans the migration directory, calculates what’s new, and runs the pending scripts inside a single transaction (where supported) in incremental order.
${schema}
) for environment-specific values.Manual DDL scripts break easily: someone forgets to run a patch, ordering is wrong, or production hot-fixes diverge from development. Automating migrations with Flyway provides:
flyway_schema_history
becomes an authoritative log of who changed what, when, and why.Flyway ships as a standalone CLI, Docker image, Gradle/Maven plugin, or as part of Spring Boot. Pick the distribution that aligns with your build system. For example:
# macOS
brew install flyway
# Docker
docker pull flyway/flyway
Within your project repository add a db/migration
folder. Place each new script here with the versioned naming convention:
V1__create_products_table.sql
V2__add_price_column.sql
R__refresh_reporting_views.sql
Provide connection settings via flyway.conf
, environment variables, or the command line:
# flyway.conf
flyway.url=jdbc:postgresql://localhost:5432/shop
flyway.user=app_user
flyway.password=${DB_PASSWORD}
flyway.locations=filesystem:db/migration
If production already contains objects, prevent Flyway from replaying initial DDL by running:
flyway baseline -baselineVersion=1.0 -baselineDescription="Production init"
Developers should execute migrations on startup:
flyway migrate
This creates flyway_schema_history
and applies outstanding scripts.
Insert a migration stage in your pipeline after the application artefact is built but before deployment. Example GitHub Actions step:
- name: Flyway migrate
uses: red-gate/flyway-github-action@v2
with:
url: ${{ secrets.DB_URL }}
user: ${{ secrets.DB_USER }}
password: ${{ secrets.DB_PASS }}
locations: filesystem:db/migration
clean: false
Failures fail the build, blocking deployments that would leave the schema inconsistent.
flyway.validateOnMigrate=true
to guarantee previously applied scripts haven’t been edited retroactively.flyway -outputFile migrate.sql migrate
) for manual review in regulated environments.Suppose your e-commerce platform introduces an orders
table. You’d:
V3__create_orders_table.sql
with DDL.flyway validate
→ flyway migrate
.Galaxy’s lightning-fast SQL editor is an excellent place to draft and test Flyway migration scripts. Because Galaxy supports parameterization and version control comments, you can:
db/migration
folder for execution by Flyway.Remember, Galaxy runs ad-hoc SQL; the actual automation still occurs when Flyway executes those scripts in the pipeline.
BEGIN/COMMIT
for databases that allow transactional schema changes.flyway baseline
makes it trivial to adopt for legacy databases.down
command. You must write compensating scripts or restore from backups.flyway_schema_history
to confirm versions.-X
for verbose logging.flyway repair
) if a migration failed and was partially applied.Automating migrations is the first milestone. Advanced teams layer in Platform Engineering concepts such as database branching, ephemeral test databases, and automated data masking—each fully compatible with Flyway’s repeatable, predictable workflow.
Modern applications iterate rapidly, and the database schema must evolve in lock-step with code. Manual SQL patches are error-prone, environment-specific, and rarely audited. Automating schema migrations with Flyway bakes version control, testing, and deployment into your delivery pipeline, ensuring safe, reproducible database changes that scale with team size and release frequency.
Yes. The Community Edition covers the majority of use cases. Teams that need undo scripts, advanced authentication, or Oracle PL/SQL parsing can upgrade to Flyway Teams.
Flyway itself is forward-only. Create a new versioned script that reverses the change, or restore from a pre-migration backup. Flyway Teams offers undo
scripts as an additional feature.
Absolutely. Draft and validate your SQL in Galaxy, then save the final version as a V__
or R__
script in your repository. Galaxy’s AI Copilot can even suggest indexes and constraints before the script enters CI.
Flyway works with all major relational databases—including PostgreSQL, MySQL/MariaDB, SQL Server, Oracle, SQLite, Redshift, and Snowflake—ensuring cross-platform consistency.