CLI to manage your SQL database schemas and migrations

If it's a declarative tool, then "yes, thanks".

But if it's not, then "no thanks", I already have my native CLI tools bundled with my RDBMS.

If you are using SQL Server, then SQL Server Database Projects are an amazing tool to work with. I found them to generate high-quality migration scripts and it makes it easy to diff against an existing database.

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.

Good may be an alternative to Alembic, so we can get rid of the Python requirement =)

(Checks it out...)

Ahh, this is also Alembic.

Tangential, but anyone can suggest their favorite SQL client? Many years ago on Windows I enjoyed HeidiSQL, and while you can kind of use it with wine, it doesn't make a stable impression to me.

Recently I found mycli[1], which seems slightly better than the official mariadb cli client, but still a bit cumbersome.

[1] https://github.com/dbcli/mycli

If you happen to be using MSSQL or Postgres, the Redgate tools are a game changer for schema management. I was a big fan of using things like EF and custom code to handle schema migrations until I tried SQL Compare. These tools make normalizing a large number of instances significantly easier. If you've got a multi tenant setup where everything should have the same schema, you could fix the whole fleet in an afternoon.

For SQLite, I still vastly prefer using custom code to run migrations. Something about the ownership model makes manual external tooling feel inappropriate.

I like when projects like this mention other projects. "Phinx" (PHP) has been a breeze to work with for database migrations for years now, and handles more than my team needs. Meanwhile, some time ago a colleague in other job was raging they didn't have migrations but a chaos of DBs in their environments.

> This will create a config file for local and prod databases using sqlite for local and postgres for prod.

Hold on, people actually do that? I thought it's trivial to run your database in a container locally.

I mostly used ORM to manage db changes.

Yhhjkj