Grant Fritchey

19 July 2021

Why Would You Pay for Flyway?

Flyway is an open-source database deployment tool that also includes a paid tier called Teams. Since it’s open-source, you can just download Flyway and run it for free. You’ll get a robust DevOps tool to assist you in deploying your databases just like you deploy your code. It just works. So, why would you even bother to pay for Teams?

Actually, there are a number of reasons why people pay for advanced tiers of open-source software in general. Also, there is some great functionality in Flyway Teams that you can’t get in the community version. Let’s discuss both.

Why Pay For Open-source Software

The very definition of open-source software means that developers can change the code, which means that exclusive, paid, licensing is not a part of the deal. In short, open-source is free. Free of licensing anyway. So, why might you choose to pay for an open-source software like Flyway?

Support

If you’re working with an open-source tool like Flyway, there is a strong community out there using it. This means, you can easily get a lot of answers to your questions from the community. For example, a great place to get community help for Flyway is from StackOverflow. You can see examples of this by searching for Flyway there.

However, you are going to have to wait on that support until someone from the community with the answer comes along. That assumes of course, someone from the community has the answer. You can’t be assured of that. If you need to solve problems faster, one way is to pay for support for the open-source software. This is very common across the open-source community. It’s a way to get more answers, faster. Not only do you get access to a world-class Redgate Support team, we’re frequently publishing how-to articles and training videos, too.

Stability

Another reason people might pay for an open-source software like Flyway is to add some stability to the implementation. By paying for the software, you have people dedicated to providing bug fixes, which the community is not always going to be as responsive on. You’re also more likely to have assurances of the continuation of the project. As this report shows, the sheer volume of abandoned open-source projects has introduced serious security risks.

For these reasons, many organizations with large scale implementation of open-source software, will pay to ensure better stability, and reliability, of that software.

Additional Functionality

There are lots of organizations that supply multiple tiers for the open-source software. A completely free forever version, and a version that you pay for, but comes with additional functionality. When you’re happy with the behavior, you simply stick with the free version. As soon as you realize you’re going to need some very advanced, or different, functionality, there’s a pay version available. This has the added value that it’s also going to have more stability and support built in for the additional functionality.

Flyway Teams comes with a whole slew of functionality that takes Flyway to the next level for supporting your database deployments.

Flyway Teams

Flyway Teams adds a lot of functionality. You can see the entire list here. I’m not going to go through every single one. Instead, I’m going to call out the ones that I think make a fundamental difference in your ability to better control your database deployment automation.

Undo

While I firmly believe that it’s extremely unlikely for people to realistically and reliably rollback deployments, many people still want that ability. I prefer the concept of roll forward over rollback, but, Flyway Teams can meet your rollback needs. All you have to do is add Undo scripts to your code. It follows the standard naming standards, but uses the letter “U” by default as a prefix like this:

You match the version number to the scripts that this one is meant to undo. Then, you use the command “undo”. You can simply run it like this:

That will then run the Undo scripts that you built. You can read more about the process here. This is extremely handy if you are going to create rollback scripts for your deployments. You have full capacity to automate those rollbacks exactly the same way as your deployments.

Script Migrations

It’s extremely common as a part of deployments to need to run commands and processes that are not simple SQL commands for whatever database you’re deploying to. For example, what if you want to run psql to perform a large-scale data import as part of your deployment? Flyway Teams adds the capability to run various types of scripts from PowerShell, to Bash, to Python, and several others. Best of all, you really don’t have to do anything special to implement it. Just add the script to your code like this:

Then, when you run ‘flyway deploy’ the migrations script will get run in the correct order as a part of your automated deployment. You can add them to the Repeatable scripts or the Undo scripts in the same way. Migration scripts radically expands what you can automate for deployments with Flyway Teams.

SQL*Plus Commands

I am not any kind of Oracle expert. I can generally run standard commands to create an object or manipulate data. However, I do know that SQL*Plus is extremely important to people who have to administer & control Oracle databases. Flyway Teams has direct support for SQL*Plus commands, as well as standard PLSQL syntax. You do have to enable the behavior through a flag:

You can do this from the command line or as part of your configuration file. You can read about the full set of supported commands at this link.

Dry Runs

Some days, nothing beats the Mk I Eyeball for identifying when, or if, there’s a problem. Flyway provides you the ability to run a series of scripts in a very specific order as well as run scripts repeatedly for each deployment. In theory, since you wrote all the scripts, you should know exactly what’s in them. However, as a mechanism of troubleshooting, or, just to provide the DBA team with a script to review, it would be nice if you could tell, exactly, in a given circumstance, for a given deployment, what will be run against the database. Flyway Teams provides exactly this functionality through Dry Runs.

To put this to work, you just have to supply a location for where you’d like the output to go:

When you supply the dryrunoutput value, Flyway won’t actually run a migrate, and will instead generate the script that you want to review.

Cherry Pick

It happens to everyone. You’re working on changes to the database and you get everything ready to go. Yet, another team, also working on your database, has hit a snag. Their code isn’t ready. However, in source control, and more importantly, in Flyway, the versions look like this:

Now, if we deploy our code to get to version 4.6, we’re going to get version 4.5, the unfinished procedure, as well. That means deploying broken code, which is, let’s just say, a bad thing. Further, future deployments won’t match if you modify code that you’ve already deployed. This can lead to all sorts of problems. Enter the ability to Cherry Pick deployments.

It’s really straight forward. If you want to deploy only versions 4.4 and 4.6, you do the following:

This will deploy only the changes we want, and not the one we really don’t. Then, when the other team finally gets their code completed, just take advantage of the Out Of Order utility (part of the community version):

You’ll still get to deploy version 4.5.

The ability to Cherry Pick is good for these kinds of out of order deployments, running an Undo command only for specific versions, hot fixes, and a whole lot more.

Conclusion

For a lot of organizations, the support and stability they get by paying for an open-source software like Flyway is absolutely worth the cost. However, others just want to get their hands on the advanced functionality offered. While Redgate is dedicated to keeping Flyway open-source through the Apache V2 license, we’re also going to be right on top of it with world class support, and the additional functions provided by our top development teams.