Ведь данные для чего то нужны, а не просто для нагрузки.

И голоден гейт такого не делает ?

Вот нашел , оказывается и такое есть
https://cloud.yandex.ru/services/ydb

На счет GG не уверен, но на рынке видел два решения, которые подобное делают.  Информатика и ataccama.  
Правда покупатели такого из ИБ  чаще всего. Поэтому  рынок специфичный.

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

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

Одно дело обфусцировать данные в нереляционной структуре, допустим в таблице колоночной БД или таблице KV (wide row/wide column) БД, и совсем другое - в реляционной БД, где есть хотя бы несколько связанных между собой таблиц.

Да, каждый набор «источник->получатель» настраивается отдельно.  И начинает функционировать.  Разработчики получают данные для работы с псевдореальными и обновляемыми данными. С сэмплом или с полной выгрузкой, а ИБ сидят и охраняют таблицы инвертирующие данные. Потому что имея их «фарш проворачивается в обратную сторону»
Если правила в каждом проекте «источник->получатель» одинаковые, то получатели и между собой могут работать. Это может быть не только базы данных, но и сообщения в кафку или еще куда.
Но проблема этого рынка в том что все это нужно для тестов и для экономии места на дисках + для обеспечения безопасности данных.  
А на это бюджет выделяется в третью очередь.
Так что большинство решает локально процедурами руками.

Подскажите, а кто как решает проблему синхронизации моделей данных между солюшн архитектором и дба? Не секрет, что дба понимает, что и как работает на конкретной базе, как быть тогда архитектору в такой ситуации?

Dba не занимается моделью данных

Но он же понимает, что с одной моделью будет хуже, чем с другой...

Имхо, дба может дать рекомендации, но решать за модедь,,это не его зона ответственности

Очень интересные мнения... Архитектор, который не знает, как работает база, но занимается проектированием...

Откуда такой вывод?

Потому что если бы знал, то проблемы между дба и архитектором не было бы

+.

Архитектор может и должен руководствоваться рекомендациями dba, но не вступать с ним в дискуссии принятия решения.
Если архитектор отчитывается перед dba - то кто вообще управляет кошкой собакой?

А, имеется  ввиду не архитектор данных, а среднестатистический солюшн?

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

Мой совет - ищите и собирайте обоснование. Другого пути для Вас у меня нет

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