That works alright in development / non-prod, especially for a smaller team or small scale application. Not in prod though. In my opinion as a database speciali

That works alright in development / non-prod, especially for a smaller team or small scale application. Not in prod though. In my opinion as a database specialist, tying database schema changes to application deployments is an outright anti-pattern in production. (assuming you are using a networked database server like Postgres or MySQL, not an embedded database like SQLite) Generally you always want to ensure your application logic works properly with both the current schema and next schema. This way, you can roll out the schema change independently first, and then only if/when it succeeds, you roll out new application code (and/or enable new feature flags etc) which actually uses the new columns, tables, procs, etc. If you tie the schema change to the app deployment instead, you have to do the opposite: ensure that the new version of the application is backwards-compatible with the old schema. That's necessary because you probably have multiple copies of an application running (for HA), and some schema changes may take a long time to run. So upon deploying a new version of your application, even if your modern ORM correctly handles migration locking (to ensure only one app copy runs the migration), you would still have a window where other updated app servers are running updated code but the schema hasn't been changed yet. So if you tie schema changes to app deployments, the app must be backwards-compatible with the old schema: every single reference to a new database object must be gated with a feature flag, every time. In contrast, the decoupled deploy / forwards-compatible approach is much easier, because generally application code already won't interact with database objects that the code doesn't know about.