а более контролируемо тем, что не обязательно давать прикладу в руки пользака с суперправами на базу

С ломающими изменениями? Эм, это нормально когда после следующей миграции предыдущая версия ПО не поднимается и наоборот.

Что значит не рекомендуется на проме? А как новую версию ставить? Как развивать ПО?

Миграция должна учитывать данные и накладывать патчи так, что бы не повредить данные. Вернее это должны учитывать патчи, они же должны быть сделаны так, что бы обеспечить заполнение, например, данными по умолчанию при добавлении обязательных колонок

Ну тут как бы одна база, один сервис. Он же под себя же гадить не будет

Ну и в любом случае даётся пользователь, у которого права только на создаваемую им схему

Вообще не понимаю параннои

я тоже не понимаю

Эта та же истерика, как у фанатов подман. Они хейтят докер просто потому, что из мнение на вопрос другое

но у нас такое требование от базовиков присутствует(((

на самом деле в микросервисах с небольшими базами - можно и из прикладов. но с большими монолитами и базами на десятки таблиц я б наверное не рискнул

А бывает, допустим, если ликибэйс, то два инстанса сервиса поднимаются, и могутзалочить бд, это как решается? В ci как то?

не, там databasechangeloglock таблица есть, там блок ставится

который кстати не снимается если вывалился эксепшн)) (по крайней мере в spring liquibase так)

Ну это типичная паранноя  dba ибо их замкнутый мир и ограничевается только базой

В какой момент? Когда один сервис начинает создавать таблицы он ставит блок?

еще до создания таблиц

Просто порядок старта делают

ага, они нам по началу вкатили repeatable read по умолчанию на базе, а у нас все рассыпалось. и очень очень неохотно откатили на read commited. сказали вдогонку "ниче ниче, скоро сериалайзбл будете юзать"

В flyway нет такого

А второй сервис уже не прокатывает эти измени, так как чендж логи с конкретным id уже выполненны получается?

не просто с конкретным айди, а еще и с конкретной чексуммой