We're currently thinking of using Pulumi to create the database. However, at this point the database doesn't have any schema. Is it a good practice to subsequently, in the same program, invoke Flyway to perform the schema migrations?

However, at this point the database doesn't have any schema. Is it a good practice to subsequently, in the same program, invoke Flyway to perform the schema migrations?

You can do that. However, applying schema migrations is always going to be an ongoing concern for your app and not a one time thing, unless it is a one time thing in your case for some reason. As far as if it is considered a good practice, I am not sure. Here are my thoughts. Assuming that you are dealing with a web app/mobile app architecture with some API backend and also assuming that you are deploying your app/business logic separate from your infrastructure. The way I suggest looking at it is, the DB schema shouldn't be a concern for your infrastructure app (your Pulumi app) but rather the web application that uses it. So when you deploy the web app, either run the migration before you deploy the app through some CI/CD mechanism. If you are deploying your web app as a container image and your container orchestrator supports init containers, that's a another nice way to deal with schema migrations. I've also seen teams bake the invocation of the migration script as part of the app startup routine itself. Either way, the new version of the app doesn't come up if the schema migration fails. The other question to ask yourself is, do you want the infrastructure update to fail if your schema migration fails? That is, say, you are deploying not just your DB infrastructure but also other resources, is it ok for it to hold up potentially updating those other resources?

Thanks for the detailed response!