[arkh]

> manage migrations

I feel like it is one of their major drawbacks. But I'm mostly working maintenance so what I usually see are databases outliving many applications and my view will differ from greenfield project people.

Your ORM is tied to your app. Tying your database to your app through your ORM is IMO an error. Managing schema change in your application is even worse.

Database and their schema should be independent from your app. So you can release new versions of your database without depending on app releases. As mentioned by other people the best would be to have views per app for reading and procedure for writing so you can totally decouple your app access from your data schema.

Databases are not dumb key value stores. Stop using them like they are and start enjoying the functionalities they offer.

[l5870uoo9y]

How do you manage database migrations then? Are they in Git repository? Genuinely curious.

[arkh]

Yes, like any other piece of your system.

It can feel overkill when you have one app with its code repository, infra repository and now schema repository. But most people are not doing microservices so the database is central and used by multiple applications. Then one more repository, which you'd want DBAs to handle, is nothing.

Also, migrations should only go up and be non destructive.

The main problem and I think it is one of the current open ones for the gitops / CD ecosystem is managing which versions of your software are compatible so you know what can be running together or not. Package management but for your whole software architecture.

All this are personal opinions and I'd be happy to have to change it if presented with good arguments against it.