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.
For SQLite, I still vastly prefer using custom code to run migrations. Something about the ownership model makes manual external tooling feel inappropriate.
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.
Recently I found mycli[1], which seems slightly better than the official mariadb cli client, but still a bit cumbersome.
But if it's not, then "no thanks", I already have my native CLI tools bundled with my RDBMS.
Shorel•11h ago
(Checks it out...)
Ahh, this is also Alembic.
Hasnep•11h ago
https://github.com/ariga/atlas
leosanchez•9h ago
[1]: https://github.com/pressly/goose
ghthor•4h ago
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