Agree, it's pretty simple writing them. The problem is deciding which ones to apply for a given version of your application, when, running them automatically on each of your developer's laptops, your testing environment, and automate and keep track of all the changes.

Or are we talking of just writing a "CREATE TABLE..." and hand it over the wall to the ops? I agree that's simpler. Not something I like to do these days.

1. create a "schema_version" table

2. have a unique, incremental migration ID in each migration filename

3. apply them one by one in order depending on the current schema_version from the target environment, and update the schema_version accordingly

4. rollback the transaction in case of error, otherwise commit and enjoy your updated schema

I used golang-migrate/migrate in production for the past 3 years to do exactly this but you can easily implement it yourself too. golang-migrate/migrate can be used either as a Go library or as a CLI tool.

https://github.com/golang-migrate/migrate

Or did I misunderstand the issues you're talking about?

So... do pretty much exactly what ORMs with migration support already do for you?

Yes, but write the DDL by hand rather than having it auto-generated.

Yes, the point is that you don’t need an ORM to manage migrations.

And I assume you mean all of this is easier to do, safer, takes less effort, has more documentation, is more tested and proven and will be easier to understand by a new joiner after the one that wrote it left than using an existing, popular solution?

Sorry, I disagree.

It’s definitely tested and proven, that’s a very common approach (not this specific migrate tool, but the general pattern). It’s simple to setup and only require standard SQL (or whatever your DB is using), has almost no moving parts, and is as stable as it can be.

I’m not saying it’s easier than other solutions, that’s not really a criteria I personally care about. But it is stable, simple, relatively easy to maintain, using standard tools, reliable.

Just use Dbup [1] if you're a .net shop, and flyway [2] otherwise.

They are both existing, popular solutions that helps you organize your plain SQL migration scripts.

1: https://dbup.readthedocs.io/en/latest/ 2: https://flywaydb.org/

Writing migrations by hand doesn't mean you don't have an automatic migration system. TypeORM for example can generate migrations automatically for you, but you can also generate an empty one and write the SQL yourself, and get the safety of automatic migrations

Same here, it's way more flexible. I find it quite important to know exactly what will be run as a migration given how critical changing the schema can be.