если тебе _на_самом_деле_ важно, с точностью до коробки в стойке, где именно какая таблица лежит (а что - дистрибьютится) и это часть твоего процесса работы с данными - да, норма (как еще-то?)
В качестве бонуса - вся эта информация непосредственно в схеме, поэтому она не может внезапно просраться/стать несовпадающей с реальностью. Минус - что вся эта мегаусложненная конструкция становится хрупкой, ненадежной и чреватой человеческими ошибками. "Зато меня никогда не уволят!"

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

Как мы все понимаем, в масштабах байды выбора на самом деле нет. А недостаток скорости (на чем, кстати, говорят, написано? Ась, не слышу? А? Да понял что г-но, а какое? php, небось?) компенсируется наращиванием числа тазиков. У байды их много, картонная фабрика работает где-то на параллельной улице.

жаль что товарищам из Яндекса видимо некогда отвлекаться на опеннеты, их менеджер больно лупит дубинкой, если они хотя бы пять секунд не пашут на благо конторы. А в байде не понимают по-русски.

Ты просто не пробовал в кокроач залить дамп в несколько десятков гигабайт в кластер из 4-х нод, да посложнее со структурой который, получается крайне хреново, тормозит конкретно, даже доходит до того что сервера подвисать начинают, потом он там пересчитывает постоянно эти реплики свои и снова сжираются ресурсы, ну да ладно допустим это через пару лет поправят. Погугли никто не смог собрать нормально кластер-то из 10-ти нод на нем.
Реальность по кокроачу такова, что чем больше там нод, тем тормознее он будет, это как раз проблемы мультимастера. Потом там по архитектуре минимум 3 реплики может быть а не 2 как в Citus, тоже кому-то накладно будет стока копий одинаковых данных хранить.

В реальности Citus это нифига не поделка, а очень даже стабильное решение которому и 100 нод не помеха. А по поводу простоты, куда уж проще, вы посмотрите как PostgreSQL-XL настраивается и поддерживается, вот там да - куда ж без админа.

Citus не сложен, абсолютно. Ну и раз уж на то пошло, то в нормальной компании, которой нужен многонодовый кластер БД наверное найдется денег на админа :) Ну по крайней мере там где сейчас делаю, там с деньгами на админа проблем нету.