But if it's not, then "no thanks", I already have my native CLI tools bundled with my RDBMS.
ORMs are good up until the point you need to include SQL Views, Stored Procedures, Functions, User-defined Types… which is usually the point the ORM abstractions begin to crack (and every SQL Server database I use include them).
For PostgreSQL I usually hand-write the scripts, because it is easier, than fighting against an ORM.
I heard the Redgate tooling is also great to work with, but I’ve never used it personally.
From there, Atlas handles diffing, planning, and execution. This is similar to importing modules in TF, but for database schemas in Atlas. See this example: https://atlasgo.io/guides/orms/sqlalchemy
Disclaimer: I'm involved with Atlas.
(Checks it out...)
Ahh, this is also Alembic.
Love how you can write you migrations in go using goose and mix in raw sql migrations as well. Allows for great flexibility when doing complicated migrations and enables writing unit tests for migrations with regular go test
Recently I found mycli[1], which seems slightly better than the official mariadb cli client, but still a bit cumbersome.
For SQLite, I still vastly prefer using custom code to run migrations. Something about the ownership model makes manual external tooling feel inappropriate.
So we had hundreds of databases. And no migrations or way to keep them in sync.
One day I got fed up and ran some statistical analysis on all the databases to find inconsistencies and figure out what the most popular schemas were, because sometimes even when they had the same table and column names, the types were slightly different.
I don't recall if I managed to get them all in sync before I quit.
Hold on, people actually do that? I thought it's trivial to run your database in a container locally.