я предполагаю, что реляционные данные и ноды хранятся отдельно и обрабатываются по разному. (src лень изучать)

Может это случай синдрома "когда у тебя в руках молоток, всё вокруг кажется гвоздями". Но даже если это тот самый случай, то реляционные БД имеют под собой проработанную теорию, и эта теория обширно проверена на практике и допилена под эту практику. Всё что возможно запилить другого будет рядом с реляционной БД просто наколенной поделкой.

Но если даже не так, то ты прикинь, вот решил ты создать графовую базу данных -- как ты будешь хранить её на диске? Есть разные способы представления графов, какой ты используешь? Один из этих способов: два списка -- список вершин и список рёбер. Понятно что к этому прилагается какой-то способ адресации вершин и рёбер -- индекс в массиве, или какой-то ключ для поиска по хештабличке.
Но это же прям для реляционной БД способ, не так ли? Если использовать ключи (идентификаторы какие-то), то прям отлично ложится на реляционную бд. Другие способы, типа хранения структур вида:

struct Vertex {
    name: String,
    edge: Vec<Edge*>,
}

struct Edge {
   left: *Vertex,
   right: *Vertex,
}

не очень удачны: чтобы перенести бд из одного места в другое, тебе придётся либо пересчитывать все указатели, либо копировать as is, с сохранением всех смещений. А если у тебя часть элементов была удалена, и в хранилище теперь появились неиспользуемые дыры? Тут ты расчехляешь Кнута, и начинаешь освежать в голове алгоритмы управления памятью, и получаешь в результате непредсказуемое время выполнения запросов. Может эти проблемы и можно решить, почитав того же Кнута, просто порыскав алгоритмов, переговорив со многими людьми об алгоритмах, изобретя собственных алгоритмов. Может и можно решить, а может и нет -- я не знаю, не пробовал. Но даже если можно, то это займёт годы напряжённого труда, в процессе которого ты не только PhD получишь, возможно ещё и пожизненную должность профессора в каком-нибудь ВУЗе из top10 по миру.

Сейчас БД активно идут в универсальность.