Почему СУБД не поддерживает типы массивов для столбцов?

Давайте возьмем забитый до смерти пример движка блога.

У вас есть блог, в блоге есть сообщения, у сообщений есть теги для организационных целей. Решив, что проблема с тегами нетривиальна в среде РСУБД, мы идем в Google за рекомендациями и находим следующее краткое изложение решений в качестве первого удара: разрабатывает и соответствующие тесты . Однако, все они имеют цену либо производительности, либо сложности. Похоже, что подход, подобный NoSQL, позволяющий хранить список тегов в столбце (в NoSQL мы можем хранить документы в документах), отлично решит проблему. Почему бы не SQLServer / Qracle / MySQL / Postgres / и т. Д.

Сначала я подумал, что это может быть из-за разницы в размере. Но любая РСУБД, на которую стоит обратить внимание, допускает некоторую форму varchar и text (значительного размера). Таким образом, изменение размера столбца (и тот факт, что один и тот же столбец в разных строках будет иметь разный размер, не является проблемой). Поэтому вместо хранения большого количества текста давайте сохраним список элементов одного и того же типа (массив на большинстве языков) в столбце. Давайте проиндексируем его для эффективного точного поиска совпадений. И, по крайней мере, для всех случаев использования, в которых у меня есть потребность в БД NoSQL, исчезла бы необходимость (я знаю, что многие люди твердят о масштабируемости, но я недостаточно знаю / забочусь об этом, у меня нет масштабируемости вопрос, мне снятся кошмары обслуживания). Мы получаем упрощенный дизайн нашей схемы (все так же чисто и просто, как документ в документе NoSQL) и отличную производительность благодаря эффективной индексации. Еще более странно то, что БД с открытым исходным кодом (например, Postgres) не имеют какого-либо патча для этой функции. В наши дни разработчики с мотивацией в этой области, похоже, увлечены созданием новых БД с нуля.

Я упустил какое-то ошеломляющее техническое препятствие, или вышеупомянутые поставщики СУБД просто ленивы или уходят в прошлое?