Но не в глазах ищущего человека
Вполне логично что при поиске одного ему можно показать и другое
В конце концов у нас есть практика совмещённых санузлов
А ещё просто половые коврики можно ему подсунуть, но с меньшим весом в поиске

я об этом и говорю, настройки расчета релевантности очень гибкие, в моем контексте это не необходимость

Это нормально что у вас есть свое мнение на этот счёт, если хотите возразить - пожалуйста. Если при этом вы сошлетесь на что-то более предметное противоречащее моему утверждению получится более полезная беседа

Что за "настройки расчёта"? Как они выглядят? Как при предлагаемом тобой подходе коврики для ванной выдавать при запросе ковриков для туалета?

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

я отсеиваю наименее релевантные товары

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

у меня не амазон, что ты доколупался)

чтобы семантику слов и конструкцию запросов глубоко анализировать

Проблема в том, что горизонтальное масштабирование вообще не имеет отношения к типу СУБД. Тут нет зависимости. Почти у каждой реляционной СУБД есть в коробке возможность горизонтального масштабирования, например, куча слэйвов у postgresql. Есть greenplum, там распределение данных по типу shared nothing, тоже в коробке.

если под масштабирваонием мы имеем ввиду шардирование то именно реляционная база уступает "noSql" с архитектурной точки зрения

тут разница принципиальная, оракл это или нет разницы не играет

Я разве предлагал вариант? Я вроде только писал почему твой вариант на самом деле не вариант для серьёзного решения задачи

А что с архитектурной точки зрения не так с реляционными СУБД, что их сложнее масштабировать?

проблема с джойнами

Это скорее не про sql vs nosql, а про то как данные дробить в целом

Имхо нормализированная дата в большом масштабе проще поддерживаема

знал что вы будете донимать и как раз нашел вам на эту тему статейку. Правда там пишут что noSql тоже есть проблемы в виде потери данных при особых кейсах
https://habr.com/ru/post/440306/

TLDR

В итоге на сегодняшний день есть реляционные БД, которые хорошо масштабируются только вертикально, а это дорого. И есть NoSQL-решения без транзакций и без гарантий ACID (хочешь ACID — пиши костыли).

Все сильно зависит от задачи. Мой вариант работает прекрасно. Ввел человек 'Салат с огурцами и помидорами' - ему нашло и показало сначала салаты с тем и тем, потом салаты с одним, с другим. Поисковая система позволяет и просто любые салаты выдать пользователю, но я их отсеиваю. Даже касательно приведенного  вами примера с ковриками все найдет прекрасно, проблема лишь, что релевантность будет куда ниже у ковра для ванны и я считаю это логичным если пользователь ищет коврики для туалета. Это разные коврики. Коврик для ванны предполагает, что его будут заливать водой и площадь побольше, для туалета — нети поменьше.