Redgate Flyway

Choosing the right approach with Flyway

Flyway gives teams the flexibility to adopt a migrations-based approach, a state-based approach and to blend elements of both, according to individual needs and process preferences. Developers can choose how they interact with the tooling and teams can decide how deployments are executed.

Within each approach there is additional flexibility in terms of which capabilities to enable, and whether these capabilities are used with Flyway Desktop or automated using the Flyway CLI. Which approach to adopt will depend on the specific value that is regarded as most important to a team or organization.

To begin understanding which approach will best fit your needs, categories of questions to examine include:

  • Manual deployments vs automated deployment pipeline. Will deployments be orchestrated by an automated CI/release tool, or will they be applied manually? Do you also want to include drift detection, code analysis, dry runs and change reporting for finer control over your database deployments?
  • Database object-level version control. Are development teams looking to treat database code like they do application code, which means the database inherits all the benefits of Version Control Systems? Do you also want a fully trackable version history of database changes right down to the object level for use in auditing?
  • Auto-generation of migration scripts. Are developers seeking productivity and quality gains by automating the generation of migration scripts? Do you have differing levels of experience in your team between major DBMS (SQL Server, PostgreSQL, Oracle and MySQL) that would benefit from standardization and speed of generating migration scripts?

For ease of onboarding, it may be shrewd to adopt an incremental approach to your database DevOps journey, focusing on solving the primary business need and over time evolving this to derive increasing value from the Flyway solution. We are also happy to help with questions about moving from one approach to another. Contact us and we will be in touch.

Foundational migrations approach

Community-proven and simple to run with a migrations-first development model 

  1. Developers author Flyway migration scripts manually.
  2. Pending migration scripts are deployed either through Flyway Desktop, by embedding Flyway into application startup code, or using an automated pipeline.

License: Flyway Community / Flyway Teams / Flyway Enterprise

This approach is built on foundational capabilities supported by 50+ DBMS (see Flyway Feature Summary for more information)

If required, a schema model step can be included into the process to maintain an object level history in version control.


  1. As above.
  2. Maintain a schema model to provide an object-level history
  3. Deployment as per (2) above

License: Flyway Teams / Flyway Enterprise

The schema model is available for SQL Server, Oracle, PostgreSQL and MySQL.

Please contact us for more detail on this workflow.


Migrations-based approach with auto-generation of migration scripts

If teams wish to benefit from productivity and efficiency gains, auto-generation of migration scripts can be enabled.

  1. Developers auto-generate migration scripts from the development database either using Flyway Desktop or as part of an automated process ( eg., as part of a pull request)
  2. Maintain a schema model to provide an object-level history (optional)
  3. Pending migration scripts are deployed either through Flyway Desktop, by embedding Flyway into application startup code, or using an automated pipeline.

License: Flyway Enterprise

Works with: SQL Server, Oracle, PostgreSQL and MySQL (see Flyway Feature Summary for more information)

For database development teams that seek to improve collaboration and have greater control over when changes should be reflected in migration scripts, a schema model can be configured to be the source for the generation of migration scripts. 

  1. Developers save database state changes to and from a version controlled schema model
  2. Auto-generate migration scripts from the schema model in Flyway Desktop or as part of a pull request
  3. Deployment as above.

License: Flyway Enterprise

Visit the Migrations-based approach with auto-generation of migration scripts page for more detail.

State-based approach

In a state-based deployment model the deployment script is generated at deployment time using comparison technology to compare the source state (eg. Development) with the target database (eg. Production). In this model developers do not have to author or test their own migration scripts, which provides for a very simple low-overhead process for development teams, but relies on the database comparison technology to generate the right deployment script. Therefore, it is well suited to database projects in which the changes can be easily inferred, like modifying code objects (programmable objects), changing data types, or adding new tables and columns, but is less well suited where human insight and intervention is necessary, for example adding a new NOT NULL column, or any changes that require data migration or manipulation.



  1. Developers save changes to and from the schema model
  2. Using Flyway Desktop, the deployment script is generated from the schema model before being applied to the target

License: Flyway Teams / Flyway Enterprise 

Teams employing DevOps processes such as continuous integration and continuous delivery can configure state-based deployments within their automated pipeline.

  1. Developers save changes to and from the schema model
  2. Using an automated pipeline, the deployment script is generated from the schema model for review / approval before being applied to the target

License: Flyway Enterprise




Didn't find what you were looking for?