This message was deleted.

If I have an application (and related database) whose deployment is being controlled by code, I generally roll my migrations into the application's startup.

yeah, I might end up going that route. There are several different client applications that rely on this DB though so I was hesitant to do that, but I guess I could always pick one of them to control the schema updates.

Your business, your rules, but my experience is that IaC without manual intervention only really works well when applications own their own datastores.

I get that pattern. I’m trying to adapt IoC to a more traditional one, where there is a well-regulated central database that is a “source of truth” for an array of different services and jobs. The “main” instance of this, of course, only needs to be set up once. The need to auto-provision it’s schema comes mostly from the desire to quickly spin up full instances of the entire system for development or integration testing.

Yeah, I get where you're coming from. Hell is legacy stuff, etc. 😉 The best way I've dealt with what you describe is to not have one arbitrary app control database migrations, but have a separate database migration service that is the canonical database mutation source.

Interestingly, this is a (fairly) new project: I chose a central DB to get away from my last few microservice-based projects that quickly turned into a rats nest. Also we’re in the finance sector so having something that’s 100% transactional by default gives me peace of mind.