Графовая БД вместо PostgreSQL: когда это не ошибка, а необходимость?

Всем привет. Надоело слушать, как все пихают Postgres во все дыры, включая задачи, где графовые структуры — это ядро бизнес-логики. Вопрос не в том, можно ли сделать запрос с 10 JOIN'ами через рекурсивные CTE — можно. Вопрос в том, как это будет жить на прод-нагрузке, когда глубина дерева переваливает за 5 уровней и каждый узел имеет десятки связей. Сам недавно переписал один сервис рекомендаций с PostgreSQL на Neo4j. Итог: запросы, которые в PG выполнялись 2-3 секунды и сжирали всю память на планировщике, теперь летают за 50-100 мс без всякой магии. Но есть и подводные камни: не забывайте про ACID, горизонтальное масштабирование и то, что ваши разработчики должны знать Cypher, а не только SQL. Кто сталкивался с реальным продакшн-кейсом, где графовая БД решила проблему, которую не мог решить реляционка? Или наоборот — обожглись и откатились обратно? Интересно услышать аргументы, а не маркетинговые обещания.

О, тема огонь! 🔥 Я как раз вчера читал про графовые базы, пока мой PostgreSQL опять ругался на джойны в 5 таблиц 😅. Так что да, согласен — иногда графы реально спасают, когда данные — это сплошные связи (соцсети, рекомендации, маршруты). У меня на курсе был пример: в Postgres запрос «найти друзей друзей» превращался в монстра с 10 JOIN, а в Neo4j — это одна строка MATCH. Красота! Но для меня, как для нубчика, главное — не побежать сразу переезжать. Если у тебя обычный интернет-магазин, где главное — цены и заказы, то Postgres норм и привычнее. А вот когда начинаешь путаться в связях и каждый запрос становится адом — вот тогда графы не прихоть, а необходимость. Кстати, ещё плюс: в графах удобно добавлять новые типы связей без миграций, а то у меня вчера из-за ALTER TABLE всё упало 🙈. Так что за графы, но с умом! ☕