Every major Java ORM has offered similar functionality for over 15 years now. At least in the Java community, I find that more and more shops are moving AWAY f

Every major Java ORM has offered similar functionality for over 15 years now. At least in the Java community, I find that more and more shops are moving AWAY from letting their ORM library manage their database schema migrations. The current best practice is using something like Flyway or Liquibase. In which you place your DDL migration scripts (i.e. raw SQL) into source control, either with your application or externally. If it's with your application, then the application checks for new migrations and applies them at startup. If externally, then you do this yourself with a CLI tool. Either way, the system creates a table in your schema to track which migration scripts have been applied, along with hashes for each script. So the system can detect whether there's a new migration to perform, or throw an alert warning if someone retroactively changes an already-applied script. Of course, you're still welcome to leverage an ORM library in dev-mode to help you create that initial schema-setup script. It's just not great to rely on that approach for ongoing migrations in production. Having a trail of migration scripts in source control makes SO MUCH difference in reliability, and making it easier to stand up a new environment (or a local dev environment) that truly reproduces the state of your production schema.