I really don't see an upside to having the application update the DB on startup. Let's consider the two main contexts of this: you have automated deployments or you have some sort of manual deployment. In the former, you can simply make the flyway update routine part of the deployment process preceding the application startup. In the second case, the manual process means there's a good possibility that something goes wrong like deploying the wrong version of the application and then you might have much bigger issues if a schema migration was bundled into that.

Database schema changes are (almost always) much more impactful, risky, and difficult to correct than application deployments. If you set up your application deployment right, when you deploy the wrong version of an application, it's simple to correct: you deploy the correct version. This is especially the case if you use containers for your solution. Changes to a database schema are not usually that simple. They are often accompanied by data transformations which may not always be reversible. The more risky a change is, the more deliberate you should be about it. Having schema changes occur as a side effect of something that is usually less risky is asking for trouble.

if deployement fails on one server, old code will mismatch with new DB schema but the application still runs => data corruption might silently occur.

I would recommend that your application check the schema on startup and verify that it matches the version the application expects. If the schema is not aligned with the application version, the application should fail to start.

If you keep the schema migration separate, it gives you much more freedom to manage the deployment process. If you have a clustered app with rolling deployments, you may need to stop everything to make a major schema change. Consider what happens if that schema change is part of a rolling deployment i.e. the old version is still up and running in some nodes. Having the application upgrade the schema might seem to simplify things but it actually complicates things, especially in the case you accidentally start the wrong version of the application that then attempts to 'fix' the database.

There's one really huge reason not to include migrations in your application that I neglected to mention: flyway needs high-level permissions that you should not be giving to an application. This violates an important security practice.

I really don't see an upside to having the application update the DB on startup. Let's consider the two main contexts of this: you have automated deployments or you have some sort of manual deployment. In the former, you can simply make the flyway update routine part of the deployment process preceding the application startup. In the second case, the manual process means there's a good possibility that something goes wrong like deploying the wrong version of the application and then you might have much bigger issues if a schema migration was bundled into that.

Database schema changes are (almost always) much more impactful, risky, and difficult to correct than application deployments. If you set up your application deployment right, when you deploy the wrong version of an application, it's simple to correct: you deploy the correct version. This is especially the case if you use containers for your solution. Changes to a database schema are not usually that simple. They are often accompanied by data transformations which may not always be reversible. The more risky a change is, the more deliberate you should be about it. Having schema changes occur as a side effect of something that is usually less risky is asking for trouble.

if deployement fails on one server, old code will mismatch with new DB schema but the application still runs => data corruption might silently occur.

I would recommend that your application check the schema on startup and verify that it matches the version the application expects. If the schema is not aligned with the application version, the application should fail to start.

If you keep the schema migration separate, it gives you much more freedom to manage the deployment process. If you have a clustered app with rolling deployments, you may need to stop everything to make a major schema change. Consider what happens if that schema change is part of a rolling deployment i.e. the old version is still up and running in some nodes. Having the application upgrade the schema might seem to simplify things but it actually complicates things, especially in the case you accidentally start the wrong version of the application that then attempts to 'fix' the database.