Voice of the DBA

Tag: Flyway

Flyway Tips: AI Generating Migration Script Names

AI is a big deal in 2026, and at Redgate, we’re experimenting with how AI can help developers and DBAs become better at their jobs. One of the areas we’ve started to add some AI is in Flyway Desktop (FWD), with a few features designed to help reduce the cognitive load and context switches needed while developing code, and help users better understand what changes they’re making in their systems.

I wrote about summaries of migrations scripts last week, which are helpful when you or your colleagues don’t generate good script names, or commit messages. This post looks at another of those changes, which is the generation of the script name.

I’ve been working with Flyway and Flyway Desktop for work more and more as we transition from older SSMS plugins to the standalone tool. This series looks at some tips I’ve gotten along the way.

Generating Complex Scripts

In Flyway, we call the deployment scripts “migration scripts”, but they are the same thing. These are scripts that are changing, altering, or evolving our database schema in some way. New or altered objects, various schema items, and more.

Our guidance for a lot of customers is to keep the migration scripts simple and easy. That can work, but sometimes we want to put a few things into a script to ensure that we deploy all the changes at once. In the last article, I had this list of changes in one script.

I generated this in the last post with a poor name.

Let’s fix that.

Using the Power of AI

I’m going to delete that script and get my list of objects in the Generate tab. I’ll select a few, as shown below.

Now I’ll generate the script.When the script completes, I see my default “Steve” name for the description. However, look to the right. There’s a looping circle at the far right side of the Description box. I didn’t capture a good image, but it’s actually moving in a circle.

When it completes, I have a better description for my changes.

Let me save this and repeat it for the other changes to the customer tables.

That’s a way better description than I would typically write.

Enabling AI Features in Flyway

This is a preview feature as of Jan 5, 2026 as I write this. To get this in your FWD, your organization needs to have enabled AI features in your portal. I’m just a member, but whoever is an admin for your Redgate products would find it here.

In FWD, you need to look at the Preview Features item under the config menu.

In this area, you can enable or disable features as needed. I see these marked as Red-gate only, but I think they are supposed to be released to some customers by this time. It’s likely I need to upgrade my FWD, which I’ll do when I have time.

Once you do this, you should start seeing some AI stuff with the purple/pink shaded area and the sparkle icon that we’re all seeing everywhere.

Summary

Getting good migration script descriptions, or really any good descriptions, is hard. Developers get tired, they aren’t always creative, they forget things, and they sometimes just take the default.

Witness my repo.

This feature reduces the burden on developers and auto-generates a name for the file. It can be edited and changed, but the dev doesn’t have to.

This feature is documented, but we are likely to enhance and change it a bit, so all feedback is welcome. If your organization doesn’t want you using AI, and you could share some schema from a migration script, I’d be happy to test it for you and see what summary is produced and send it back to you. Ping me on X/LinkedIn/BlueSky if you want.

Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today. It works for SQL Server, Oracle, PostgreSQL and nearly 50 other platforms.

Video Walkthrough

See a video of me looking at this feature below.

January 16, 2026
Flyway Tips: AI Deployment Script Descriptions

With the AI push being everywhere, Redgate is no exception. We’ve been getting requests, demands, suggestions, and more about how to add AI into our products and help developers and DBAs be more productive.

One of the areas we’ve started to add some AI is in Flyway Desktop (FWD), with a few features designed to help reduce the cognitive load and context switches needed while developing code, and help users better understand what changes they’re making in their systems. This post looks at one of those changes, which is in preview (as of Jan, 2026).

I’ve been working with Flyway and Flyway Desktop for work more and more as we transition from older SSMS plugins to the standalone tool. This series looks at some tips I’ve gotten along the way.

Understanding Deployment Scripts

In Flyway, we call the deployment scripts “migration scripts”, but they are the same thing. These are scripts that are changing, altering, or evolving our database schema in some way. New or altered objects, various schema items, and more.

When a developer creates a migration script, they often do this close to the time they are making the changes in development. Not always, but I find a lot of customers change something, test it, and then make the migration script. Guidance for a lot of customers is to keep the migration scripts simple and easy. For example, here’s one I have that creates a simple table. If you look in the image on v23, which says “Create Product Table” in the description, that is what it does.

If I click on this line, I see the script shown below the name (V23__Create Product Table.sql). The new thing just below in this image is that an AI summary is being generated.

In a few seconds, this changes. I get the summary of the table. In this case, it says I have a new table with some columns.

If I expand this with the drop-down on the right, I see the full summary. This includes telling me a PK is being created, which is good info. I could look through the code, but the settings, the PRINT statements and more make this harder than it should be.

What about a more complex script? If I pick a different one, such as V24__Removed Territories and Region tables and related constraints and procedures, I get an OK description that lets me know a few things are being changed. I wish this had a little more detail in it, such as the tables on which FKs are being dropped, and maybe a list.

Let me create a whole new set of objects. In this case, I’ve added some discount features in a bunch of tables. Here is the list of objects I added to the migration script.

When I generate the migration script and then click on it in the Migration Scripts tab, I see this description.

That’s an interesting description, as I see that there are territory and customer tables, which I’d forgotten I added. I was working on them and added them, but hadn’t committed them. I added the discount stuff (3 tables and a view) in a dev session today, and then selected everything to save and include in a migration script.

This is one of those areas where the summary helps me remember what’s in here, and in this case, I’d want to delete this script and re-generate it with a different set of object changes. Then a second migration script with other changes.

Enabling AI Features in Flyway

This is a preview feature as of Jan 5, 2026 as I write this. To get this in your FWD, your organization needs to have enabled AI features in your portal. I’m just a member, but whoever is an admin for your Redgate products would find it here.

In FWD, you need to look at the Preview Features item under the config menu.

In this area, you can enable or disable features as needed. I see these marked as Red-gate only, but I think they are supposed to be released to some customers by this time. It’s likely I need to upgrade my FWD, which I’ll do when I have time.

Once you do this, you should start seeing some AI stuff with the purple/pink shaded area and the sparkle icon that we’re all seeing everywhere.

Summary

This post shows one of the Flyway AI features that we’re adding to help you deal with the chaos and complexity of database development in your environment. This features tries to summarize the details in your migration script and provide you a summary.

This isn’t perfect, but as you look at scripts, it fairly quickly gives you a look at what’s included without you having to read all the code. You should double check the code and be sure it’s what you expect, but if you’re looking through a few scripts for a particular change or impact, this might help save you time.

There is a limit to the amount of stuff we send to the LLM to summarize. I can’t remember (or find) the limit, but very large scripts aren’t summarized, and you’ll see a message to that effect.

This feature is documented, but we are likely to enhance and change it a bit, so all feedback is welcome. If your organization doesn’t want you using AI, and you could share some schema from a migration script, I’d be happy to test it for you and see what summary is produced and send it back to you. Ping me on X/LinkedIn/BlueSky if you want.

Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today. It works for SQL Server, Oracle, PostgreSQL and nearly 50 other platforms.

Video Walkthrough

See a video of me looking at this feature below.

January 9, 2026
Flyway Tips: Automation Assistance in Flyway Desktop

I was chatting with the product managers at Flyway and one asked me whether I’d seen the new tab for Automation in Flyway Desktop. I hadn’t and decided to take a quick look at how this works and what’s useful. This post looks at the new feature.

Tl;Dr this is a good way to start learning how to move to a more DevOps, automated way of deploying changes.

I’ve been working with Flyway and Flyway Desktop for work more and more as we transition from older SSMS plugins to the standalone tool. This series looks at some tips I’ve gotten along the way.

Working with Flyway Desktop

For a lot of customers, it’s not too hard to setup a project and start to capture code in a Git repo. However, adding in automation gets challenging for many, especially as the docs are hard to understand if you don’t already have some knowledge. I find that CI/CD is a bit of a chicken and egg challenge as we try to learn to get better, but knowing what to learn and do requires knowledge.

Which we don’t have.

In any case, I’ve taken an existing Flyway project where I am capturing some code. You can see the project below, with objects on the right. The database and the repo have the same object code and are in sync.

Let’s add a few new objects to this database in SSMS. You can see below I’m adding a new table and altering a proc. I’m also refactoring slightly to not keep the old style join convention in my proc as I add a new join.

Once I do this, in Flyway Desktop (FWD), I see my changes. I’ll save these to the repo and then generate a migration script. I won’t show that as it’s not important.

Once I’ve done this, I know I want to deploy code. If I go to Migrations, I can see I have these two scripts ready to go to QA, and I can deploy them with FWD manually. However, I don’t want to do that.

I want some automation. How does FWD make that easy? Let’s see.

The Automation Tab

There’s a new tab on the left, which is the Automation tab. I’ve expanded the left menu out and you can see it, but it’s a lightning bolt, which I might never have noticed (hence this post).

If I click this, I get a little explanation at the top, a few links, and then some CLI based code. This last part is the important part of what I need to move to CI/CD.

If you look at the code closely, you’ll see some placeholders in angle brackets for the environments I need. The code looks like this:

Above this, there are two drop downs where I can select my build and target environments. Build is the CI portion, and it’s a good idea to have a place to build code separate from QA. This lets me validate things, and more importantly, run some code analysis checks, summarize changes, and detect drift.

I’ve expanded the Build drop down below and you can see I have my environments listed, and I can also manage them from here. There is also an Environments tab on the left menu just above Automate Deployments that looks like a database icon.

Once I select an environment, the code changes to reflect this. That makes things easier to automate as I can take these commands and drop them into a task in my CI/CD tool.Note in the image below that I’ve selected NWInt and the code shows target2. The code needs the ID (or PK) of the environment, but the display name I entered is shown in the drop down. Trust me, these match.

I’ll also select a target and then open up a CLI to run the first item on line 5. I did have to auth, but this runs successfully. No doc checks, no experimenting, the command ran.

I’ve never saved any snapshots and so the drift doesn’t work right away, but I’ll get the dryrun script. When I run this, I get a summary from the CLI.

Then I can see the report (see above output for the path at the end. When this opens, on the Dry Run tab, I see my scripts.

Note, I did use the drop downs in FWD to select the environments I need for this.

Very cool.

Summary

One of the challenges with using Flyway is that there are a lot of settings, options, and more that one must learn to take advantage of the solution. Our docs continue to improve, but even for someone that has been using Flyway for a few years, I have to constantly check out things work. Plus, the teams are adding features on a regular basis, so it can get confusing to learn the new things.

This automation tab is really helpful to shortcut some of the things I need for the various environments in my project. I’m going to start using some of this in a new project, and so should you.

Flyway can do much more, and for smoother automation, check out Flyway Enterprise.

Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today. It works for SQL Server, Oracle, PostgreSQL and nearly 50 other platforms.

Video Walkthrough

December 8, 2025
Friday Flyway Tips: State-based deployment with Flyway

I was asked about state-based deployments in Flyway, so I decided to show how this can work with a quick demo. This post walks through the process.

I’ve been working with Flyway and Flyway Desktop for work more and more as we transition from older SSMS plugins to the standalone tool. This series looks at some tips I’ve gotten along the way.

A Steady State

I have a Flyway project setup already. I’ve refreshed the screen and as you can see here, there aren’t any differences between my database and my project in version control.

In SSMS, I’ll create a new table in my FWState_1_Dev database. This is where my project is pointed in Flyway Desktop (FWD).

I’ve created a new table and it exists. If I check my QA database, FWSTate_3_QA, I don’t see this object.

If I refresh my project in Flyway Desktop (FWD), I’ll see my change. I can pick it and see the code, and then I’ll click “Save to project” in the upper right.

Once the code is saved, I see the confirmation and I have the code ready for commit to a VCS. I won’t do that here, though you should.

What I want to do now is go to the left bar and select “deploy”, which is the rocket icon.

When I do this, I see a blank screen, as I don’t have a target. I can select that on the right if I’ve configured one.

If I pick the drop down, you will see my dev and QA environments. I made changes in the dev environment, and want these changes to go to QA. I can also click the “Manage environments” button. Let’s do that.

When I do that, I see a list of environments. I use this a lot to double check that I’m deploying to the right place for this project and where to look for changes. If you work across multiple projects as I do, this is handy.

You can see below I’ve selected QA with the green checkmack in the radio button. Once you pick your environment, you can click “Confirm”. If you need a new target, click Configure.

I return to the deploy screen, and this time I see the changes that have not been deployed. In this case, that’s one change, but if there were more, I would see them. I can click any object to see the changes, and once I’ve selected what to deploy, I can click deploy.

When I click Deploy the script is generated and I see a preview. I also can see that this is from my schema model on disk being deployed to the Qa database. That’s handy as this might take a few minutes and who knows what distractions might appear in my life.

I also can execute this as a transaction or not, and copy the script if I want to examine it in another tool (or format it like SQL Prompt).

When I click Deploy, I need to confirm my deployment. Always a good step, though I think if you do this often, your muscle memory will be ready to just click confirm.

Once the deployment runs, we see a message this was successful.

If I now check the QA database, I see the object.

Summary

This post has shown how you can perform manual deployments of changes in a state-based method using Flyway. This is a quick way to move your changes from one machine to another.

Flyway can do much more, and for smoother automation, check out Flyway Enterprise.

Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today. It works for SQL Server, Oracle, PostgreSQL and nearly 50 other platforms.

Video Walkthrough

Here is a video of the process below.

March 21, 2025