Then you probably need to unlock and update your version of ecto_sql

That table is per repository as I understand it, but OP wants a single repo and migrations in different apps of the same umbrella…

Personally I’m not convinced that this was a good design choice, the application that contains the repository should be the only one tampering with the database. Everything else will get you into trouble…

An external system can surely manage its own tables, but imho it should do so through migration files, which are added to the migrations path of the application it’s used in (e.g. oban does implement that quite nicely). Or if it’s part of a bigger system, where installing plugins is part of the core functionality have a truely custom handling of db migrations, but I don’t see that as feature ecto should support.

Perhaps, but imagine a plugin system, each plugin wants to run its own migrations to add its own tables to the database. Perhaps ecto needs a way to have ‘named’ version columns, I.E. have the schema_migrations table have another field that defaults to the application name or so, that way each different ‘priv’ directory has it’s own migrations and can be done and undone individually.