Всё достаточно просто. Если за работоспособность СУБД отвечает дба (ну или архитектор, или владелец ресурса) - то он должен уметь в крайнем случае послать в лес или выдвинуть функциональные требования к реализации.
Это не значит, что так надо делать, просто это важный момент.
Договариваемся просто. Во-первых, нормальный солюшн обычно приходит с бизнес-требованиями и своим пониманием их функциональной реализации. Именно эту связь и может скорректировать «дба»/дата архитектор, который укажет на некорректный выбор технических решений. У нас это обычно проходит в рамках конструктивной дискуссии. Если ФТ нет - то их можно помочь сформировать.
Но есть девиации. Типа «а давайте мы будем документооборот вести в Vertica, там же есть long varbinary». Тут в лучшем случае удаётся просто сделать встречное предложение с более привлекательной реализацией, в худшем - доходит до оценки денег на решения и разговора уже на уровне что сколько стоит.