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 that it is a migration version control tool. I prefer Redgate Flyway  because instead of manually running SQL scripts on different environments like dev, QA, and production, Redgate Flyway helps automate this process. It tracks which scripts have already been executed and only runs new migration scripts. It ensures every environment has the same database schema, which is very helpful for all the people on the team. It also keeps a history of database changes.

In my first company, I used Redgate Flyway for a project where we were integrating MakeMyTrip APIs. In that particular project, we had to create a lot of tables, and I generally used Redgate Flyway for that. The main purpose of using it was that we had to make a lot of schema changes. Instead of doing it manually in the PostgreSQL  database, we can use Redgate Flyway. What I did was version the file name, then provide the SQL language in that file, and run it. It keeps executing from there.

The best features Redgate Flyway offers include ease of use. The second is that it is simple with not a lot of dependency required. Third is the version controlling mechanism.

Regarding the link mechanism, when we execute Redgate Flyway, it generates a hash value. It keeps that hash value, and when the next migration comes into existence, it links that particular previous value and executes it, which shows how the ease of use has benefited me and my team.

Redgate Flyway has impacted us very positively because we don't have to manually cover all those things. The one main improvement that we have made is that previously we were not using Redgate Flyway, so we had to manually migrate the scripts from one command to another command with the same versioning. Now we don't need to configure all those things. We let Redgate Flyway handle all those things and we need to write the SQL command in those particular files with the correct versioning.

It definitely saves a lot of time because we don't need to write manual scripts in all those environments. You keep that in your local, and when you push that particular Redgate Flyway script or your code to the production environment, it is automatically executed because it keeps tracking the previous version. This was a great mechanism that Redgate Flyway follows. Also, it manually reduces a lot of errors because when we write the SQL command and if we want to alter any table or change the database schema in a specific order, Redgate Flyway always takes care of that.

I choose a rating of nine out of ten for Redgate Flyway because the only point is that sometimes it does not automatically handle the schema versioning. If we write something wrong, it just executes it. Regarding the error mechanism, when we see a Redgate Flyway error in my Spring Boot  application, it is very difficult to understand what went wrong. Whenever there is a script that fails to execute with a particular error, the error mechanism for handling that versioning is not that comfortable for me.

I have been using Redgate Flyway for almost two years, since I have been more focused on back-end development.

Redgate Flyway works fine for me.

Redgate Flyway works fine for me.

My advice to others looking into using Redgate Flyway is to keep track of the versioning because it is very important in Redgate Flyway. After that, you are all set. As a software engineer who is using Redgate Flyway, I can conclude that it is a really good tool. I gave this review a rating of nine out of ten.