Что именно?

Второй абзац

Не пойму, что вы этим хотите сказать? Ну да, жизнь нам не сахар, а смерть нам не чай...

Я имелл ввиду зачем войну и мир сочинять второй раз - сложно!

Опыт, новые знания. К тому же не всегда есть готовое решение или есть но не подходит. Вообще по разному бывает

Нечай?

Не чай (Ю. Шевчук, Это все)

Кстати, в Тимур в итоге объяснял, почему не надо использовать графовые базы данных? И приводил пример, как на реляционных базах реализовать типичные для графовых бд кейсы?

Я курс по базам сейчас смотрю, ещё на дошел до этого момента.

Или имелось в виду, что использовать исключительно графовую БД не нужно, но можно использовать, например, графовый движок для Postgres?

Я ни где не говорил, что не надо мспользовать графовых баз.

Вот здесь на 28:04 говорили "не берите их никогда"

https://youtu.be/8RjT2VYBWNQ

И уточнили, что на эту тему можно отдельную лекцию записать. Наверное, использовать можно, но есть какие-то нюансы.

Таки да

Там из контекста видно, что это я полушутливо. Я не исключаю, что можно сделать хорошую графовую базу, но пока мне попадались только плохие, самая ужасная neo4j. А вот реализации графов в гибридных и мультимодельных субд хороши тем, что не нужно в проект тянуть несколько субд, да и вот в pg все с этим хорошо.

Спасибо! Теперь понял. Я ещё рассматривал гибридную базу ArangoDB, но, наверное, Вы посоветуете использовать что-то более серьезное типа PG.

Могу по поводу графовых БД сказать пару вещей

Говори

Аранго я не использовал и даже не читал о нем

Ну 2020 год провёл за дизайном БД, в том числе и графовых, и работал с большими сетапами графовых БД… поверх кассандры.

1) Графовые БД под капотом чаще всего используют колоночные хранилища на LSM-tree с SSTable и наследуют всю ту же боль что и при работе с Cassandra и прочим
2) C любой современной как реляционной так и нереляционной БД можно сделать графовую - реализовав соответствующие интерфейсы под OpenJanus (https://janusgraph.org/) и удостоверищись в возможности вменяемого индексирования и решения проблемы DataLocality.
3) Обычно Janus оборачивают вокруг BigTable и в принципе это может работать… и даже может быть вполне актуально для некоторых, очень редких, случаев. А для всех остальных 98% - надо просто научиться в рекурсивный SQL SELECT. Но тут есть момент что даже монга становится SQL БД с помощью Apache Calcite… и да, это реляционная БД, о чём мало кто вообще догадывается (оффтопик короч - пригорело).
4) Не так страшна графовая БД как проблема Data Locality в больших масштабах - даже Intel’овским SSD’шкам не хватает IOPS’ов что бы правильно менеджить слияние и разделение страниц в журнале при Compaction’e. LSM-tree там для этого тоже специальный… т.к. надо учитывать adjacent vertices при дампе журнала для Data Locality.
5) По этому в дизайне хранилищ для графовых БД есть определённый, дополнительный Compaction Overhead, и стратегии очень сильно отличаются от того что есть в ScyllaDB и в Cassandra… ну и накладные расходы на любую запись растут экспоненциально с глубиной вашего графа \o/

tldr; графовые БД могут быть только AP и только с большим IO Amplification на запись, если основаны на колоночных БД иди соответствующих структурах данных (LSM-tree).
Если это графовые БД поверх реляционных БД - ведут себя точно так же как любой рекурсивный SELECT.

p.s. Arango построена на RocksDB (колоночный LSM-tree) и каких либо вменяемых стратегий для Compaction’a там нет, про repair не знаю - но вроде пока вообще не завезли.

Магии там нет - учитесь в рекурсивный SELECT и почитайте что-то вменяемое по теории
https://www.amazon.com/Database-Design-Relational-Theory-Normal/dp/1484255399/
https://www.amazon.com/Database-Design-Mere-Mortals-Hands/dp/0321884493/
https://www.amazon.com/Database-Internals-Deep-Distributed-Systems/dp/1492040347/