Deployment approaches with Flyway
Published 30 July 2022
Flyway supports State-based and Migrations-based deployments. Each method has its advantages. The choice depends on the context of the project and your working practices. The State-based approach has less to set up, but offers less control since you cannot edit the deployment script directly. The Migrations-based approach offers full control over the deployment script and has more built-in auditing of these scripts.
Differences at a glance:
State-based deployments | Migrations-based deployments | |
Approach | Changes are applied by comparing and updating a target database to the desired state. | Incremental. Changes are captured in migration scripts that are tracked and executed on target databases. |
Source of truth | The schema model - a set of files representing the latest state of each object and static data in your database. | The set of migration scripts - capture exactly how to modify a target database. |
Control | Flyway decides how changes are applied and the order. | Fine grained control. Changes are captured in migration scripts, which can be modified and re-ordered, if required. |
Working practices | Control over how changes are expressed largely sits with Flyway. | Users who make changes have fine grain control over how changes are expressed, allowing for full automation. |
Visibility | Flyway decides how the change is applied. | Changes are described in migration scripts which lend themselves to inspection. |
Audit trail and reporting | The object changes are captured in version control, but the actual script is not captured in Flyway. It can be saved as part of a release management process. | Migration scripts are tracked in version control and in the target databases and can be audited. |
Reversibility | Can revert to the previous state. | Each migration script can be individually undone. |
Ideal for | Teams just getting started and may not be looking for full automation. | Teams looking for full control over the deployment script and deployment can handle complex modifications like table/column renames and dealing with transactional data updates. |
Limitations | Manual intervention required for certain types of changes. | A little more set up than the state-based approach requires. |
Learn more |
You can configure the approach for your project when you create a new project. You can change this later in the project settings.
Not sure where to start?
If your not doing a lot of transactional data updates, then start with state-based deployments. You can get setup a bit quicker and you can move to a migrations-based approach later.