Redgate Flyway Enterprise

Redgate Flyway  is a migration tool that we use for our SQL migration. We have several customers' databases that must be migrated to the new schema, and we use Redgate Flyway  scripts to migrate from the older schema to the newer schema. This approach helps us keep different versions of the schema without losing data simultaneously.

Redgate Flyway provides versioning as a primary benefit, allowing us to have numbered versions and easily switch from one version to another. We write the script once, and it performs most of the manual tasks such as version control and rollback in case of any errors independently.

Redgate Flyway's version control of database changes has significantly helped in ensuring repeatable deployments. As we continuously develop and migrate schema changes while verifying that the migration is working correctly, we progressively create new versions and keep our front-end and API teams informed of changes.

Redgate Flyway streamlines the process of database migration and significantly reduces the time for data migration from twenty to twenty-five days down to five to seven days, thanks to the initial time we took for learning. Now we can complete migrations in two or three days, which is a substantial impact.

Redgate Flyway has played a critical role in accelerating our software development cycle by helping us implement continuous deployment through the creation of different schema versions and their sequential deployment, which would be very difficult with traditional methods.

I would like to see improvements in Redgate Flyway for compatibility with new agentic AI, which could provide support in writing scripts.

Apart from the AI aspect, I do not have anything in mind for improvement or missing features in Redgate Flyway at this time.

I have been using Redgate Flyway for one year.

I find Redgate Flyway mostly stable for our work, although conflicts are a different matter. Overall, it is a very stable and mature product with a simple execution model and predictable behavior.

Redgate Flyway works well for small teams but presents conflict issues with larger teams due to version control. While it generally scales well, there are some limitations with longer script run times, suggesting that some parallelization could improve scalability.

We generally use resources such as Stack Overflow for support and have not escalated any questions to technical support during our database migrations with Redgate Flyway.

Some teams were using different migration tools previously, but I do not know their names exactly. Since we migrated to a newer version of SQL, those tools were not working efficiently.

The initial setup of Redgate Flyway was challenging because we had to integrate a database without any history and establish the initial version. This was difficult due to multiple tables and the need for environment setup, alongside the team needing to learn it, and version conflicts arising when multiple people were working.

Before choosing Redgate Flyway, we evaluated options such as Liquibase  and Alembic, among others.

We decided to go with Redgate Flyway because it uses plain SQL scripts without complex XML or YAML, has version control for database changes, and works well with CI/CD. Although the cons include the absence of automatic rollback and potential merge conflicts, the versioning control was the major factor for our decision.

My advice for organizations considering Redgate Flyway is to look for agentic AI support for regular tasks, particularly in writing basic scripts, as such assistance could be very beneficial. I rate Redgate Flyway overall as an eight as a product and a solution.

My main use case for Redgate Flyway  is for migration and migration of scripts, primarily to maintain our databases. I do not have anything unique to add about my use case with Redgate Flyway ; it is almost the same as other standard use cases.

The best features that Redgate Flyway offers include support from the command prompt, which is the greatest advantage I have. Command prompt support in Redgate Flyway helps me because the integration with CI/CD happens seamlessly with the help of the command prompt, and for our local migration, we also use the command prompt. Because we use local Docker  instances to maintain our Postgres databases, the command prompt is helping significantly.

An additional feature of Redgate Flyway is the flyway_schema_history table that is created whenever migration happens. That table helps a great deal to understand in which part of the migration a particular migration has failed previously and serves useful debug purposes.

Regarding how Redgate Flyway can be improved, migration is almost an important feature whenever someone is using databases, and automating the migration is a great idea. Redgate has definitely solved the problem there, but I would feel better if there is some option for a force migration or a very hard migration whenever a migration fails. For example, if I write a script that asks to add a particular value to the database, and before running that script through Jenkins  or the migration command directly, if I run that script directly and the value is already added to the database, the migration script fails because the value was already added. The checksum which Redgate Flyway checks is modified, and the database is not in the previous condition which Redgate Flyway was looking for, so the migration fails. If there were any particular option so that I could force migrate or hard migrate, that would be great.

Additionally, whenever this kind of migration fails, Redgate Flyway command prompt indicates that there is an option to repair the migration script, but I was never quite able to figure out how it works because whenever I try to repair it, I usually run into multiple other problems, giving me multiple issues. Later, I had to go through the flyway_schema_history database and look at which particular migration failed based upon the success attribute mentioned there, and then manually do that or completely remove the database and run the migration together. This is quite tiresome since we have multiple scripts, so it would be great if I could just force or hard migrate. Or as soon as the migration fails, something could revert to a previous state and then migrate the current state, because if I have written the script, it means that I want that to be executed. For debug purposes, I might have run it, but I do not want it to cause problems in the CI/CD pipelines. Anything in the local environment, I can handle. However, handling it in the CI/CD pipeline where the pipeline already contains some fifty different stages becomes very hard to understand. It is quite easy to understand that migrate has failed, but there will be multiple steps running before and after that migration as well. Just because the migration has failed, we would have to roll back the entire previous steps, and that is very tiresome and not very easy.

Particularly, the error handling mechanism or the force update or forced migration are things I would like to see improved. It is very hard to understand or debug exactly where this migration has failed, and since I know the specific instances, I was able to do it more easily, but I would not feel confident doing this in a production environment. It feels very slim at the moment. It does not give me much confidence to go to the production environment with the current error handling mechanism of Redgate Flyway. The documentation can also be improved.

I have been using Redgate Flyway for the past two years.

I cannot guarantee the stability of Redgate Flyway; the only problem which I have faced is with the Flyway repair mechanism that never worked for me. Perhaps I did not understand the documentation, but stability-wise, if everything is fine, then the migration works. However, if there is something wrong, it will take a lot of time to figure out how to solve this.

I have seen a return on investment with Redgate Flyway in that time was saved significantly for local development. Even for local development, we had to maintain the different versions, so I would definitely say that time was saved. For example, a normal process would have taken one day, but the migration script made it possible within twenty to thirty minutes.

I would say I have never used Redgate Flyway in production; we only use it in our local test instances or some QA environments where we test it. I have never worried about the performance or much else, but it is definitely saving us a lot of time. To maintain the local database is not that easy, and to maintain the different instances of the same version of the database is quite hard where multiple teams handle different instances, so I think it helps a great deal.

Currently, I deploy Redgate Flyway only to maintain our local test instance using a Docker  setup; apart from that, we are not using it anywhere. I have only used Redgate Flyway with Oracle and Postgres, and for these two, it has worked pretty much fine until now.

My advice to others looking into using Redgate Flyway is to try to be as straightforward as possible. Do not try to do unnecessary changes on the databases when you are using Flyway Migrate because that would unnecessarily corrupt your database in the eyes of Flyway Migrate. The database is actually pretty much fine, and Flyway Migrate assumes that it is corrupted, which causes it to fail the migration and ask you to repair it, which in turn will create multiple problems.