It's the same thing, except instead of requiring two DB URL's to do the diffing, you give it a "schema.sql" file and a folder path that has your migrations in it, and the path to the current DB.
Then it introspects the DB, looks at "schema.sql" + the migration files, and figures out what you've changed in "schema.sql" that isn't in your migrations yet and generates the diff as a new migration. Really amazing workflow.
If you have trouble visualizing it, the workflow would be something like:
1. DB is empty, migrations empty, schema.sql has "CREATE TABLE todo (id int, description text);"
2. You run the diff, it generates a migration that contains the CREATE TABLE statement
3. You modify "schema.sql", maybe adding a new column like "boolean is_completed" to "todo"
4. You re-run the diff, it sees the DB has the table, the migration for the table is present, but a new column is added.
So it generates an "ALTER TABLE .. ADD COLUMN .." migration.
5. Rinse, repeat.
Tusker's flow is somewhat similar to sqldef https://github.com/k0kubun/sqldef , although the internal mechanics are quite different. Migra/Tusker executes the SQL in a temporary location, introspects it, and diffs the introspected in-memory representation -- in other words, using the database directly as the canonical parser. In contrast, sqldef parses the SQL itself, builds an in-memory representation based on that, and then does the diff that way.
I'm the author of Skeema https://www.skeema.io which provides a similar declarative workflow for MySQL and MariaDB schema changes. Skeema uses an execute-and-introspect approach similar to Migra/Tusker, although each object is split out into its own .sql file for easier management in version control, with a multi-level directory hierarchy if you have multiple database instances and multiple schemas.
Skeema was conceptually inspired by Facebook's internal database schema change flow, as FB has used declarative schema management submission/review/execution company-wide for over a decade now. Skeema actually predates both Migra and sqldef slightly, although it did not influence them, all were developed separately.
In turn, Prisma Migrate and Vitess/PlanetScale declarative migrations were directly inspired by Skeema's approach, paradigms, and/or even direct use of source code in Vitess's case. (Although they're finally moving to a parser-based approach instead, which I recommended they do over a year ago, as it makes more sense for their use-case -- their whole product inherently requires a thorough SQL parser anyway... and ironically, sqldef is based on the Vitess SQL parser!)
I'm a backend software engineer who often focuses on database automation and developer tools. Maybe niche in terms of expertise, but not niche in terms of market/userbase... a huge number of companies have databases and use developer tools :)
Just to be clear, among the tools I mentioned, I'm the author of Skeema but not any of the others. Skeema is MySQL/MariaDB specific, but I often get asked about similar tools for Postgres, so I try to stay familiar with the landscape.
Author here, as evanelias notes in another reply comment, tusker is built on top of migra. My intention with migra was always to keep it as a pure diff tool, as opposed to a tool that enforces a particular workflow. That means you can either use tools built on top like tusker if you want, or roll your own functionality with migra directly, as you prefer.
I would also like to share a very similar tool that is much less known:
https://github.com/bikeshedder/tusker
It's the same thing, except instead of requiring two DB URL's to do the diffing, you give it a "schema.sql" file and a folder path that has your migrations in it, and the path to the current DB.
Then it introspects the DB, looks at "schema.sql" + the migration files, and figures out what you've changed in "schema.sql" that isn't in your migrations yet and generates the diff as a new migration. Really amazing workflow.
If you have trouble visualizing it, the workflow would be something like: