За счет отказа от промежуточных таблиц для связей. К примеру, Есть Топик, и у него есть свойство КемНаписан (Пользователь). В классической реляционной модели мы в таблице Топика просто добавляли колонку типа user_id, которая ссылалась на таблицу Пользователя через его id. Попутно могли настроить первичные/вторичные ключи, чтобы обеспечить целостность данных. В итоге у нас было по прежнему две таблицы (Топики и Пользователи). В свою очередь через эту связь мы могли получить Пользователя по Топику, и по Пользователю получить все его Топики. В ранних версиях призмы эта связь обеспечивалась не через колонку в Топике, а через промежуточную таблицу ПользовательТопик. Таким образом связь выглядела так: Пользователь - ПользовательТопик - Топик. Это обеспечивало все варианты связей (один-к-одному, один-ко-многим и многие-ко-многим). Но, это все-таки лишняя таблица, с кучей соответствующих минусов (включая усложнение написания SQL-запросов, в том числе и потому что колонки в таких таблицах имели "интуитивнопонятные" названия типа A и B). Вот так вот этот ад выглядел: http://joxi.ru/brReEnMhYJ1VkA А это только часть таких таблиц: http://joxi.ru/a2XWaY6ID1dZWm (имена таблиц связей начинаются с подчеркивания). Сейчас подобных таблиц осталось всего 13 штук. В принципе, на сами GraphQL-запросы это почти не повлияло (в плане их написания). То есть если мы раньше писали запрос то есть получали список пользователей и их публикации, то оно так и осталось. Просто под капотом на уровне самой призмы работа поменялась. Поэтому, если делать совсем не большой сервис, то это можно было и не брать во внимание. Но когда делаешь что-то побольше, да еще и начинаешь чистые SQL-запросы писать, то новая призма конечно же гораздо лучше себя показывает.