My initial reaction was in agreement, but you’re almost certainly going to need a mechanism to manage schema changes. It makes sense to use the same system for both
Schema changes happen inside a database on the server but usually you need the DB and user provisioned first (generally using a superuser and the existing/default DB)
You can use the same tool, however it needs to connect to 1 DB, do the DB creation and role setup, then reconnect to a new DB.
If you have a single app or DB in a server, it can make sense to usually schema management but it's more complicated if multiple apps have their own DBs sharing the same server.
The last few places I worked had scripts that ran before schema management as a superuser then used the application framework schema management (migrations) thereafter.
Yeah I have the same awkward process for provisioning databases. Another difficulty is configuration of passwords/auth which varies by server typically. Generally speaking I don’t want my migration process to have the ability to assume the super user role.
The variance in the script prevents using the typical migration frameworks built into the app, and it’s the wrong responsibility - the app migrations have a contract with whatever database is being connected to about which users and schemas exist.
I’m still not sure a declarative mechanism is desirable though because the database “setup” is still subject to change after initial provisioning: new schemas/roles/etc will be required and we need an imperative API to execute those changes transactionally with precision.
