How to avoid inconsistent states when migrating a database and deploying lambdas?

We have a node serverless project, using sequelize as the orm, and postgresql and the engine, and we have a github action that first migrates the database, and then deploys some or all lambdas.

It works fine except there's a breaking migration, like deleting or altering something, in that case the old code stops working until the related lambdas are deployed again, which can take some minutes.

What's the best solution to handle this? Some options I'm considering:

\- Don't make breaking changes in migrations directly, and instead separate them into two parts, making breaking changes after the code is deployed. So it would be like: migrate non breaking changes (adding stuff); deploy code; migrate breaking changes (deleting stuff). Stuff like renaming a column would be divided in two changes: one creating a column with the new name, duplicating the data from the old column; and the other deleting the old column, which would be made after the code is deployed. This has some limitations, but the worst part is that it requires devs to change the way they do migrations, also we need some way of identifying which migrations would be made later, and "mark" them.

\- Database schema versioning: this looks promising, I'm just investigating how this would work though. Don't know how bad and hard would it be to keep and use an older version of the schema. But we can at least do something like make requests immediately fail if the version is not up to date.

Any other options or tips in general?