Хотелось бы более развернуто, с обоснованием точки зрения. Полагаться на инварианты приложения нельзя, т.к. в одну и ту же базу пишут многие версии приложения, с разным набором багов, написанные разыми программистами.

Для чего у вас многие приложения используют одну базу?

Одно приложение. Но много версий. Представь БД, у БД есть владелец-приложение, новая версия приложения деплоится каждые 2 недели. Что будет с данными через год?

Миграциями данные актуализируются

Совместимость должна быть всего лишь у двух версий: последней и предпоследней, чтобы в момент выкатки, когда кубер (или альтернатива) запустит миграции, старая версия приложения, которая ещё принмает трафик и не потушена, могла принимать трафик и не ломалась

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

Всё так, но это не решается версионированием, а решается фиксом багов

Есть такая точка зрения, что если у БД один владелец со стабильным API, то структура и тип базы значения не имеют.
Я к тому, что это неправда. Данные - это вещь в себе, со своим жизненным циклом и гарантировать целостность и непротиворечивость данных на уровне приложения невозможно.

Данные нужно чистить от мусора, актуализировать, исправлять ошибки. А для этого нужна качественная и документированная схема БД.

Фигня это всё.

Чистить данные от мусора? Что? Откуда возьмётся мусор?

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

Актуализировать структуру?
Ок  актуализировть под что? Наверное под требования приложения и моделей. Что собственно как раз и делатся миграциями приложения.

Исправлять ошибки чего? Ошибки данных? Откуда они возьмутся, как не из приложения?

Зачем лечить симптомы, если лечить нажо причину.

> гарантировать целостность и непротиворечивость данных на уровне приложения невозможно.

Как раз на уровне приложения инварианты и нужно, и можно гарантировать. Вы же не из тех, кто бизнес-логику пишет в БД? А иначе в БД можно гарантировать лишь частичную целостность всякими констреинтами, чеками и уникальными индексами. Но они далеко не покрывают все инварианты, если не начать писать логику в БД.

Оттуда, решил ты например поддерживтаь консистентность данных на уровне приложения, а не бд (для производительности).  Но приложение не может тебе гарантировать консистетность, вообще никак. Рано или поздно случится сбой, который приложуха не сможет обработать. И узнаешь о нем тока когда проведешь диагностику своими тулзами (если они написаны, конечно).

> Чистить данные от мусора? Что? Откуда возьмётся мусор?
Мусор это потерявшие актуальность данные. Как и мертвый код существуют в любом мало-мальски поддерживаемом длительное время проекте.

Так это ваше приложение не может.
Если вы не можете это не значит что это невозможно.

А почему вы решили что все данные должны быть консистеными?
На самои деле таких критических данных которые должны быть консистентными всегда и везде не так чтобы много.
Я даже не могу с ходу назвать пример где без этого не обойтись. Мы держим в голове что наш атомарный инсерт одной строки\документа всегда консистентен (благодоря транзакциям если поддерживаются или оптимистичному локу если нет).

Вы всегда если база то начинаете про SQL почемуто
А что вы будуте делать если у вас DynamoDb или BigTable нфпример?

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

Мне вот интересно, почему вы всегда говорите об идеальных вещах? Как по мне всегда стоит учитывать человеческий фактор. Какойнить условный Вася программист забыл написать транзакцию, и некоторое время все шло хорошо. Но в один прекрасный момент, когда процесс убился на той самой забытой транзакции,хоба, и у вас уже неконсистентные данные. Ладно бы инсерт, если это будет удаление - вот вам и оставшийся мусор.

Про реляционки. Потому что это самый частый кейс. Нет смысла рассматривать конкретные решения под общие случаи.

Про мертвые данные. Если они вам так нужны, то можно архивировать где-то отдельно. Держить их в основной бд нет смысла. Это затратно.

А в БД и при проектировании БД и настройке констрейнтов у тебя ошибок по определению не бывает что-ли?